> For the complete documentation index, see [llms.txt](https://worlddao.gitbook.io/worlddao-white-paper/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://worlddao.gitbook.io/worlddao-white-paper/advancing-decentralization/hardware.md).
# Hardware
In the context of the Worldcoin project, [specialized hardware devices](https://whitepaper.worldcoin.org/#the-orb) (Orbs) enable the verification of humanness and the issuance of World IDs. Several aspects can contribute to making Orbs more transparent and verifiable and increase their accessibility. One factor is to increase the reliability of Orb availability via multiple distributors and manufacturers. Additionally, increasing the transparency and verifiability of the Orb’s functionality can help align the incentives of manufacturers not to be malicious. Furthermore, letting anyone develop alternative Orbs democratizes the solution space.
The graph represents possible ways to increase transparency, verifiability and availability of Orbs across the world.
The following sections walk through different milestones that can contribute to the robustness of Orb infrastructure.
#### [Reduced Trust in Secure Provisioning](https://whitepaper.worldcoin.org/#reduced-trust-in-secure-provisioning)
Approved Orbs are able to issue new World IDs. To ensure the integrity of the network and reduce trust in provisioning, certain requirements should be fulfilled (see Secure Provisioning Standard). However, there is no provably secure hardware, and certain points of trust remain as described in Orb Provenance Verification via User Agent. Importantly, the Worldcoin protocol doesn’t rely on perfectly secure hardware, as described in the [limitations section](https://whitepaper.worldcoin.org/#orb-security), and audits like [In-Person Auditing of Orb Locations](https://whitepaper.worldcoin.org/#in-person-auditing-of-orb-locations) can help decrease incentives for malicious actors. The following requirements can help reduce trust assumptions.
[**Onchain Orb Registry**](https://whitepaper.worldcoin.org/#onchain-orb-registry)
The “Orb Registry” refers to the set of active Orbs endorsed by the Worldcoin Foundation and eventually the community. Only Orbs in this set can be used to generate new World IDs. If an entity’s process can be sufficiently trusted (e.g. by implementing a Secure Provisioning Standard and regular audits thereof), the insertion of public keys from that entity in the Orb Registry could be delegated to that entity. To limit the harm caused by a malicious Orb, World IDs registered with different Orb manufacturers (and ideally with different Orbs) should be distinguishable from each other. This makes it possible for the ecosystem to respond to (inevitable) attacks by removing individual Orb manufacturers, and perhaps even individual Orbs, from the whitelist on-demand. Optionally, World IDs associated with fraudulent Orbs could be revoked (see Revocation in the Operations section). This information can be private and only stored on the World ID holder's device as long as it is provable on demand. If anyone were mistakenly affected by such action, they could re-verify through an active Orb. As a last resort, disagreement in the set of trusted provisioning entities could be resolved by forking the protocol and adding or removing provisioning entities.
[**Secure Provisioning Standard**](https://whitepaper.worldcoin.org/#secure-provisioning-standard)
The ability to add malicious keys to the Orb Registry would allow for the creation of fake World IDs. A secure provisioning standard can make it very difficult to inject malicious keys. “Secure provisioning” refers to the process of setting up the cryptographic keys of an Orb. One part of such a standard could, for example, specify that only certain approved secure element models can be used, and require proofs of authenticity from each secure element (via die-unique certificates, signed by the secure element vendor) be reported alongside the public keys. Public keys generated by this process can then be considered for insertion in the Orb Registry.
Today, a secure provisioning process is in place that involves generating private keys on a secure element as well as burning secrets generated on an air-gapped machine connected to a Hardware Security Module (HSM) into private fuses (only accessible by TrustZone applets) on the NVIDIA Jetson. These secrets are destroyed immediately after being derived (using a NIST-SP-800-108 KDF algorithm) into two keys transmitted to the backend used for future device attestation. The original key material only exists in the restricted fuse banks on the NVIDIA Jetson. Continuous auditing of the process can help maintain a high security bar.
Eventually, provisioning entities could be required to stake a security deposit, which would get slashed if fraudulent Orb public keys from that entity are detected, for example through [In-Person Auditing of Orb Locations](https://whitepaper.worldcoin.org/#in-person-auditing-of-orb-locations). This could be proportional to the number of verifications the hardware of that particular vendor has performed or the number of Orbs that have been sold.
[**In-Person Auditing of Orb Locations**](https://whitepaper.worldcoin.org/#in-person-auditing-of-orb-locations)
Auditing in-person locations of operations can help detect malicious operator behavior as well as malicious Orbs, thereby disincentivizing malicious behavior. No entity in the Worldcoin ecosystem should have to be trusted. Therefore, all operations need to be audited in a distributed manner.
One primary concern is an entity submitting a fraudulent Orb public key to the Orb Registry. In this case, “fraudulent” means the entity has a way to spoof requests to the Uniqueness Service as if they came from a legitimate Orb. Any valid Secure Provisioning Standard should make such an attack very difficult. However, the risks associated with malicious individuals involved in provisioning and/or flaws in digital security can’t be entirely eliminated. If the Orb public key is inserted to the registry, generating fake World IDs becomes straightforward and can only be detected and prevented through Anomaly Detection methods and audits. Assuming the list of Orbs and their location is public, such an audit could look like the following:
1. Verify that the Orb actually exists and is in a given location i.e. not in a lab, disassembled and compromised and reporting a wrong location.
2. Attest that an Orb’s public key is in the Orb Registry via Orb Provenance Verification in User Agent. If no Orb can be found, the public key should be removed from the registry and corresponding World IDs could be revoked through governance. In case any user was mistakenly affected, they could re-verify through an Orb.
3. Optionally, a mechanism to verify that the number of in-person verifications matches the number of onchain verifications could be implemented. If there is a mismatch, this indicates the generation of fake identities in the process. Importantly, such a mechanism should be implemented in a privacy-preserving way.
The auditing of Orb locations by incentivized users and dedicated auditing organizations, when combined with software and hardware security measures, can make generating fake IDs very hard. Today, operations are already audited by third-party organizations. To increase the robustness of this process, a list of all Orbs, their locations, and verification counts could be made public. Further, appropriate incentives could be put in place. To disincentivize malicious behavior even further, Orb manufacturers and operators could be required to stake a security deposit that would get slashed in the case of malicious behavior.
[**Incentivized Re-Verification**](https://whitepaper.worldcoin.org/#incentivized-re-verification)
Similar to [In-Person Auditing of Orb Locations](https://whitepaper.worldcoin.org/#in-person-auditing-of-orb-locations), verified users can be randomly incentivized to re-verify at a different Orb. For any attacker who compromised an Orb or spoofed verifications, such a second verification at a different Orb would be very difficult to also spoof. Therefore, statistically, the fraction of incentivized users that end up verifying a second time with a different Orb would be lower for a compromised Orb.
#### [Distributed Orb Supply](https://whitepaper.worldcoin.org/#distributed-orb-supply)
Increasing the number of entities that distribute and produce Orbs can help improve the robustness of the availability of Orbs. Importantly, hardware and firmware of Orbs should be standardized. While variability could eventually be beneficial in increasing network resilience, allowing for variability in the firmware would make it harder for the community to audit all implementations and would increase the probability of a fraudulent entity to issue World IDs.
Further, companies developing Orbs would by default be incentivized to build the cheapest devices possible by compromising quality (e.g. camera quality, hardware security, software security, privacy) to maximize profits. This can undermine the set of verified World IDs in the long term. Aligning developer incentives would require defining precise standards. While this is likely possible, it is impractical; complex incentive mechanisms for manufacturers, audits and bug bounty programs would be required, especially for the firmware (e.g. spoof detection, platform security). Even when standardizing firmware and hardware, there are serious trust assumptions with manufacturers, which are discussed in more detail in [Verifiable Orb Provenance and Firmware](https://whitepaper.worldcoin.org/#research-verifiable-orb-provenance-and-firmware).
Therefore, at least initially, the hardware and firmware should be standardized. Focusing ecosystem efforts on distributing production, making components public, verifying Orbs and conducting in-person audits is likely the best path to increase transparency, verifiability and robustness of Orbs. These mechanisms can help detect malicious manufacturers and disincentivize the spoofing or compromising of Orbs. Below are possible improvements to distributing and manufacturing Orbs:
[**Orb Supply Incentive Design**](https://whitepaper.worldcoin.org/#orb-supply-incentive-design)
Financial incentives can encourage additional entities to distribute and produce Orbs.
[**Firmware Integrity Check**](https://whitepaper.worldcoin.org/#firmware-integrity-check)
Due to the risks associated with malicious firmware developers, only firmware endorsed via governance should be able to run on Orbs. This also decreases the trust requirements in manufacturers. Today, this is achieved through NVIDIA’s secure-boot mechanism and Linux integrity checking (dm-verity). While no hardware security measure is impossible to circumvent, the above mentioned measures make loading unapproved firmware onto Orbs very difficult.
[**Second Orb Distributor**](https://whitepaper.worldcoin.org/#second-orb-distributor)
Additional entities that buy Orbs from manufacturers and distribute them through global warehouses can increase the robustness of global stock levels.
[**Second Orb Manufacturer**](https://whitepaper.worldcoin.org/#second-orb-manufacturer)
Additional entities that buy parts and modules and manufacture them in physically different locations can help increase the robustness of the supply of Orbs.
[**\[Research\] Secure Device Recovery**](https://whitepaper.worldcoin.org/#research-secure-device-recovery)
Firmware bugs could lead to non-functional “bricked” devices, with no possible resolution via over-the-air updates. While some bugs can be prevented through canary releases, others take much longer to surface. In such cases, a secure device-recovery mechanism can help re-enable bricked devices. Common options like password logins, SSH, and secondary boot media are inappropriate given the Orb’s security requirements. Further, NVIDIAs built-in recovery mode is deemed insufficiently secure and therefore disabled.
Today, Tools for Humanity uses an open-source remote access solution (Teleport) for device recovery. A more transparent and secure recovery mechanism might configure the Orb such that it enters a custom “recovery mode” when an authenticated USB device is present. Such a device would contain a signed payload consisting of the Orb’s public identifier and command to be run. Both should be signed by the provisioning entities' recovery private key ensuring that only a particular Orb could run the payload. This mode could provide enough access to restore the firmware to a known-good version. However, such a recovery mechanism would require physical access to the Orb’s mainboard, which means the tamper detection mechanisms will be tripped. Therefore, the Orb needs to be reprovisioned after it is recovered. The corresponding updates to the Orb Registry would then be a public record of the recovery.
#### [Core Orb Engineering open source](https://whitepaper.worldcoin.org/#core-orb-engineering-open-source)
To allow functionality of the Orb to be verifiable and enable anyone to build their own Orb, the firmware and hardware should be made open source.
[**Hardware source-available**](https://whitepaper.worldcoin.org/#hardware-source-available)
Today, hardware components that aren’t security critical (e.g. tamper detection and security board) have been made source-available. Eventually, everything should be made source-available.
[**Core Firmware Components open source**](https://whitepaper.worldcoin.org/#core-firmware-components-open-source)
Publishing core firmware components makes the functionality of the Orb more transparent and is a requirement to achieve Verifiable Orb Provenance and Firmware. Publishing the following components could satisfy those requirements:
1. The main Rust application on the Orb, which handles (among other things) biometric capture, iris code generation and backend communication
2. Custom applets for the Trusted Execution Environment (TrustZone)
3. The secure element interface
4. The custom GNU/Linux-based Orb OS, including the over-the-air update system, the Linux kernel configuration, and the file system integrity configuration (dm-verity)
Making these core components open source enables others to understand the functionality of the Orb in more detail and build alternative Orb firmware implementations. Once parts of the firmware are open source, there should be incentives through a [public bounty program](https://whitepaper.worldcoin.org/#public-bounty-program) to submit potential vulnerabilities.
Given no hardware device can be perfectly secured, other sensitive components (like spoof prevention algorithms and fraud models) that may pose a direct integrity or security risk to the ecosystem if exposed should likely not be made open source. Importantly, the Worldcoin protocol doesn’t need to rely on perfect hardware security, when complemented with mechanisms like [In-Person Auditing of Orb Locations](https://whitepaper.worldcoin.org/#in-person-auditing-of-orb-locations). To reduce trust requirements, the open source code can define software “jails” for some closed-source components. For example, consider a closed-source fraud-detection module that ingests biometric data. The open source code that interfaces with this module can provide strong evidence that the closed-source code cannot save/upload the biometric data.
[**\[Research\] All Firmware open source**](https://whitepaper.worldcoin.org/#research-all-firmware-open-source)
It is unclear whether publishing all Orb components is desirable given security considerations described in the section [Core Firmware Components are open source](https://whitepaper.worldcoin.org/#core-firmware-components-open-source). There should be a continuous evaluation of which sensitive components can be made open source. The most difficult types of components are likely to be machine learning models and code related to spoof detection.
#### [Orb Security Transparent](https://whitepaper.worldcoin.org/#orb-security-transparent)
Conducting and publishing audits, an open source code base, and employing bounty programs can help make the Orb more secure and increase transparency around security. Below are possible steps towards making the security of the Orb more transparent.
[**Presentation Attacks Bounty Program**](https://whitepaper.worldcoin.org/#presentation-attacks-bounty-program)
One possible attack vector on the Worldcoin protocol is to create fake World IDs by spoofing the Orb (presentation attacks). Apart from other methods to detect and prevent such attacks, a bounty program can help raise the security bar. For example, the Worldcoin Foundation could award a certain amount of WLD for every novel presentation attack that is reported.
[**Publish Audits**](https://whitepaper.worldcoin.org/#publish-audits)
Requiring conducting and publishing of audits of hardware and firmware can help reduce trust requirements and increase incentives for developers to implement secure systems. Such audits could entail both security and privacy considerations.
[**Private Bounty Program**](https://whitepaper.worldcoin.org/#private-bounty-program)
A bounty program can raise the security bar by finding vulnerabilities early. A first version of a private bounty program has been launched on HackerOne. Gradually, more endpoints and source code should be added.
[**Public Bounty Program**](https://whitepaper.worldcoin.org/#public-bounty-program)
Making the bounty program public can help increase the reach of the program. This should happen gradually.
#### [\[Research\] Verifiable Orb Provenance and Firmware](https://whitepaper.worldcoin.org/#research-verifiable-orb-provenance-and-firmware)
While there is significant research involved, it would be ideal to allow the public to verify properties of active Orbs (don’t trust, verify), including:
1. An Orb is from an Orb vendor that meets the standards and is not a counterfeit
2. An Orb is configured to only boot signed firmware
3. An Orb is running a specific version of the firmware
These verifications can help mitigate important privacy concerns related to biometrics. The public should not need to blindly trust an Orb vendor to faithfully/correctly implement privacy-preserving firmware.
Eventually, there might be a path to also allow for non-Worldcoin Foundation-governance-approved firmware, though it is unclear whether this would be desirable given the potential downsides. Appropriate incentive and audit mechanisms to disincentivize malicious behavior would be required, which might not be viable in practice.
[**Orb Provenance Verification via User Agent**](https://whitepaper.worldcoin.org/#orb-provenance-verification-via-user-agent)
A first step towards verifying an Orb as non-counterfeit could be implemented through provenance verification via the User Agent. Such a mechanism could help verify that an Orb is from a vendor that has been approved by Worldcoin governance and therefore is running approved firmware. Such a feature can be integrated in other protocol-compatible apps.
One possible path for such a verification could be to ask the Orb to sign a challenge that has been generated by the App. Orbs contain two mechanisms for cryptographically attesting they are in the Orb Registry: private keys in the secure element and private keys derived from fuses on the NVIDIA Jetson. Verifying signatures from both sources provides strong evidence that an Orb was manufactured by a vendor that has been approved and was not subsequently tampered with. Verification of the NVIDIA Jetson fuse state can provide strong evidence that Orbs can only boot firmware that has been signed. The user agent could also request an Orb’s firmware version from the Trusted Execution Environment’s (TEE) secure storage. As part of a normal boot, the root hash for dm-verity can be delivered to the bootloader by the TEE, ensuring that only code authorized by the TEE is able to boot. Inside of secure storage, these hashes would be associated with version numbers, allowing an entity (e.g. the World App) to request attestation of the current hashes and version numbers existing in the secure storage.
This mechanism assumes that an Orb’s private key only exists in its secure element (i.e. there are no other copies), a constraint which should be specified by the Secure Provisioning Standard. Private keys are generated on the secure element directly and never leave, and a series of transparent certificate attestations during generation and export can prove that a particular key originated from a legitimate secure element. Therefore, physically attesting an Orb has a private key provides strong evidence that the same private key is not in the control of an attacker. Extracting private keys from the Orb’s secure element is assumed to be extremely difficult.
It is important to note that it is impossible to fully eliminate trust in the Orb hardware vendor/manufacturer or upstream vendors. The following attack vectors remain:
1. The Orb vendor could bypass parts of the secure provisioning process (due to malice or incompetence), invalidating the guarantees of the proposed verifications. Therefore, Orb manufacturers should be audited to ensure the Secure Provisioning Standard is maintained.
2. NVIDIA firmware could have security vulnerabilities or backdoors, which could threaten the Jetson fuse attestation.
3. The secure element vendor could be compromised/incompetent/malicious, which would threaten the integrity of the corresponding attestation.
4. While the combination between dm-verity and TrustZone version tracking based on the filesystem’s merkle-tree may allow for extremely trustworthy version information to prevent the use of signed but deprecated firmware, bugs in the TEE implementation could lead to a loss of integrity.
5. The Worldcoin Foundation could sign malicious firmware. Adding Hardware Support for Firmware Verification can help set up procedures to verify the actual firmware that is running on an Orb.
Therefore, there should be mechanisms to mitigate the risk of fraudulent manufacturers or compromised Orbs. [In-Person Auditing of Orb Locations](https://whitepaper.worldcoin.org/#in-person-auditing-of-orb-locations) and Incentivized Re-Verification can make exploiting backdoors significantly harder and help detect malicious verification of World IDs in retrospect.
[**Public Build Pipeline**](https://whitepaper.worldcoin.org/#public-build-pipeline)
The builds for each production Orb firmware release can be built in a publicly-visible way. This does not have the same guarantees associated with reproducible builds and the ability to dump the flash of the main computing unit of the Orb. However, it still improves transparency and verifiability as it provides a mechanism to trace changes in open source Orb firmware components to their inclusion in the deployed firmware. For each Orb firmware version, there should be a link to the corresponding sources and public build logs.
[**\[Research\] Reproducible Builds**](https://whitepaper.worldcoin.org/#research-reproducible-builds)
Without reproducible builds, the public is required to trust that compiled firmware wasn’t maliciously modified during/after the build. Reproducible builds provide a mechanism to verify that Orb firmware was compiled from a specific state of the public repositories. To verify the integrity of the firmware, third parties should be able to build it from source on their own infrastructure. Full reproducibility means the resulting artifacts should be identical to those deployed to Orbs, and the signature from the signed firmware should be valid for the self-built firmware. The initial priority should be to make privacy-sensitive components of the firmware open source and reproducibly built.
However, there are some limitations. The firmware should (at least initially) include closed-source components, which are opaque parts of the system. Some of these are from Tools for Humanity (e.g., spoof-detection models) and some are from vendors (e.g., NVIDIA firmware components). Additionally, some components may be hard to make reproducible. These can be built separately and pulled in as compiled components to the main build.
[**\[Research\] Hardware Support for Firmware Verification**](https://whitepaper.worldcoin.org/#research-hardware-support-for-firmware-verification)
The most transparent way to verify firmware would be by having read access to the persistent storage of the main computing unit. Future Orb versions could include external ports for directly reading the flash memory of the main processor. However, a hardware implementation that provides read-only access to the flash memory—without introducing new security risks—still needs to be validated. If a hardware implementation is possible in a secure way, public auditors could then be incentivized to use this mechanism for verifying the integrity of a particular Orb’s firmware. The integrity verification of the dumped memory could optionally reuse the Orb’s internal integrity verification mechanism (dm-verity). This can provide stronger guarantees than Orb Provenance Verification via User Agent as there are less attack surfaces for spoofing direct physical access relative to remote attestation schemes.
While this mechanism would provide very strong guarantees for the firmware state, it is still possible to spoof the auditor at the hardware level. For example, there could be a second hidden flash chip that the Orb is actually booting from. This risk could be mitigated by additional audits that inspect the hardware directly on a random subset of devices. Further, in-person audits of Orb locations can make attacks significantly easier to detect and can create disincentives for malicious behavior.
#### [Build Your Own Orb](https://whitepaper.worldcoin.org/#build-your-own-orb)
Enabling anyone to build their own version of the Orb is an important aspect to enable forkability of the Worldcoin project.
[**Non-provisioned Orbs for Sale**](https://whitepaper.worldcoin.org/#non-provisioned-orbs-for-sale)
Enabling anyone to buy non-provisioned / unlocked hardware allows them to flash their own firmware and do their own development.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://worlddao.gitbook.io/worlddao-white-paper/advancing-decentralization/hardware.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.