Silicon key exchange

Abstract

This invention discloses techniques related to cryptographic key exchange. In some embodiments, a computing device includes a cryptographic circuit coupled to a secure memory inaccessible to a processor of the computing device. Program instructions executing on the computing device may request a key exchange to establish a shared secret with another device. The cryptographic circuit is configured to perform the key exchange, which includes deriving the shared secret using private key data stored in the secure memory. In some embodiments, the key exchange includes verifying a key authorization data structure published by a key authorization authority, the key authorization data structure including a first public key of a first participant authorization authority and a second public key of a second participant authorization authority. In response to successful verification, the exchange uses a public key pair authenticated by the first participant authorization authority as a member of one of the first device groups.

Description

Silicon Key Exchange This disclosure is generally related to computer security and, more specifically, to cryptographic key exchange for establishing a shared secret. Devices such as smartphones, laptops, IoT devices, and servers often use network communication to transmit sensitive data over the Internet. For example, a password manager on a device may share sensitive information such as passwords, encryption keys, personal identification numbers (PINs), etc. Such sensitive data can be used by malicious parties for fraudulent purposes. For example, a malicious actor may eavesdrop on network communication and obtain credit card numbers being transmitted across the network. Malware may also attempt to access sensitive information stored on a device by, for example, cracking the operating system. To keep sensitive information private and secure from unauthorized parties, various cryptographic algorithms and protocols have been developed. None This application claims the benefit of priority of U.S. Provisional Patent Application No. 63 / 583,711, filed on September 19, 2023, entitled "Silicon Key Exchange" and U.S. Provisional Patent Application No. 63 / 583,716, filed on September 19, 2023, entitled "Secure Key Exchange"; the disclosures of each of the above-referenced applications are incorporated herein by reference in their entireties. The security of a cryptographic protocol generally depends on the security of the cryptographic material (e.g., cryptographic keys) used in the protocol. Thus, if the cryptographic material used in a particular cryptographic protocol is cracked, the security of the cryptographic protocol is lost. When a cryptographic protocol is implemented in software, the cryptographic material is generally stored in memory (e.g., RAM) accessible by a processor. In such cases, other (possibly malicious) software may obtain unauthorized access to the cryptographic material stored in the device's memory by executing on the processor. Although the operating system may attempt to restrict access to specific portions of memory, an attacker may use vulnerabilities to elevate privileges and read memory locations storing private key material, use side-channel attacks to obtain private key material, etc. In addition, software-implemented cryptographic protocols generally store their instructions in memory, thereby exposing them to potential unauthorized modification. The inventors have recognized that it is thus desirable to store the private key material for key exchange in a secure memory that is not accessible by the processor. As will be discussed in more detail in some embodiments below, an application program executing on the processor of a computing device may request that a key exchange be performed to establish a shared secret with another device. In response, the cryptographic circuitry of the computing device performs a key exchange for the shared secret, which is derived using private key material stored in a secure memory that is not accessible by the processor. In some embodiments, the instructions executed by the cryptographic circuitry may also be stored in a memory (e.g., ROM) that is not accessible by the processor to prevent the instructions from being modified in some unauthorized manner. In some embodiments, this use of secure hardware may improve communication security by making sensitive key material more difficult to crack. In some cases, a device user may want to distribute sensitive information using more than one device, but control the devices authorized to obtain the information. For example, the owner of a device may want to share their password with other devices they own, while ensuring that previously owned devices do not receive any passwords. As will be discussed in some embodiments below, an authorization hierarchy may be used to restrict which devices are authorized to participate in a key exchange for obtaining sensitive data. Instead of having a single entity for authorizing all devices, the hierarchy may include key authorization units that authorize two or more groups of devices to exchange keys, but delegate the identification of group membership to participant authorization units. When a device in one group later wants to participate in a key exchange with a device in another group, the device may determine whether this operation is permissible by verifying a credential issued by an authorization unit in the hierarchy. Turning now to FIG. 1, a block diagram depicting a key exchange system 10 is shown. In the illustrated embodiment, system 10 includes a computing device 100A that includes a processor 102, a memory 104, cryptographic circuitry 120, and a secure memory 130 coupled to the cryptographic circuitry 120. Memory 104 includes an application program 110, and secure memory 130 includes private key material 132 and a shared secret 134. System 10 further includes a device 100B. In some embodiments, system 10 may be implemented in a manner different from that shown, e.g., computing devices 100A and 100B may include one or more components discussed below with respect to FIGS. 5-6. In various embodiments, application 110 is a set of program instructions stored in memory 104 that can be executed by processor 102 to store sensitive information and share the sensitive information with device 100B, such as sensitive data object 112 shown in FIG. 1. For example, application 110 can be a password manager that stores passwords, an operating system that manages files, a digital car key application that stores a digital car key, etc. In some cases, application 110 can establish a shared secret with another device to securely exchange one of these sensitive data objects 112. For example, a parent may want to share a digital car key with their child using a key management application of an automobile manufacturer. However, in the illustrated embodiment, application 110 is stored in memory 104 that can be accessed by processor 102 and is thus potentially more vulnerable to having its data accessed in an unauthorized manner. If application 110 (or some other auxiliary application) is to perform a key exchange with device 100B to establish a shared secret and use memory 104 to store the key data for the exchange and the shared secret in memory 104, a malicious actor who hacks device 100A may be able to read the shared secret and / or the data and thus decrypt an encrypted version of sensitive data object 112. The malicious actor may also attempt to modify the program instructions that implement the key exchange to break the integrity of key exchange 122. As will be discussed, instead of using memory 104 to store the key data for performing a key exchange, in some embodiments, hardware circuitry (e.g., cryptographic circuit 120, secure memory 130) that cannot be accessed by processor 102 is used to protect the key data shown as private key data 132 and shared secret 134 in FIG. 1. In the illustrated embodiment, application 110 can send a request 114 to cryptographic circuit 120 for performing a key exchange 122 with device 100B to establish a shared secret 134 between the two devices. Cryptographic circuit 120 (which is coupled to secure memory 130 that cannot be accessed by processor 102) is then configured to perform key exchange 122, which includes using private key data 132 stored in secure memory 130 to derive shared secret 134. The cryptographic circuit 120 is a secure circuit configured to perform cryptographic operations (e.g., as part of a secure enclave processor (SEP) as shown in FIG. 5), the secure operations including key generation and encryption and decryption using keys, which keys may be stored in the secure memory 130 (or stored externally in a protected manner). As used herein, the term "secure circuit" refers to a circuit that protects internal resources in isolation from direct access by external circuits such as the processor 102. Such internal resources may be memory that stores sensitive data (such as personal information (e.g., biometric information, credit card information, etc.), encryption keys, random number generator seeds, etc.). Such internal resources may also be circuitry that performs services / operations associated with sensitive data (such as encryption, decryption, generation, and verification of digital signatures, etc.). The cryptographic circuit 120 may implement any suitable cryptographic algorithm, such as the Data Encryption Standard (DES), Advanced Encryption Standard (AES), Rivest Shamir Adleman (RSA), Digital Signature Algorithm (DSA), etc. In some embodiments, the circuit 120 may further implement elliptic curve cryptography (ECC). In various embodiments, the secure memory 130 is a circuit configured to store data in a manner not accessible by the processor 102. The secure memory 130 can be a local memory (e.g., internal memory) configured to store key data, which can include private key data 132, shared secrets 134, encrypted data objects 112, etc. In some embodiments, the secure memory 130 can be configured such that only the cryptographic circuit 120 can read data and write data to the secure memory 130. Accordingly, although an application running on the processor 102 may be able to request actions regarding the data in the secure memory 130 (e.g., key exchange 122), the processor 102 may not be able to read the data or write data to the secure memory 130. Thus, if the processor 102 is to execute compromised program instructions, the processor 102 will not be able to read and write the private key data 132 and shared secrets 134 because the memory 130 may, for example, lack physical read and write interfaces to facilitate such actions by the processor 102. In some embodiments, the cryptographic circuit 120 can access other forms of storage, which can include other non-volatile storage, as discussed below with respect to FIG. 6. In some embodiments, these other storage can also include a set of fuses burned during manufacturing to record a portion of the key data 132, such as a unique identifier (UID), which can be used to derive a key in the private key data 132 or other key data. In some embodiments, to expand its available storage, keys generated by the cryptographic circuit 120 can be stored outside the memory 130 but encrypted using one or more keys stored only in the secure memory 130. Exemplary components of the secure memory 130 will be discussed in more detail with reference to FIG. 6. In various embodiments, the cryptographic circuit 120 is configured to receive a request 114 from the application 110 to perform a key exchange 122 to establish a shared secret 134 between devices 100A and 100B. In some embodiments, the key exchange 122 includes an Elliptic-curve Diffie-Hellman (ECDH) exchange, in which the circuit 120 establishes the shared secret 134 and stores it in the secure memory 130. As part of this exchange, the device 100 may initially generate respective public key pairs (hereinafter referred to as participant exchange keys) including a private key and a corresponding public key. Then, each device 100 may share its own public key with other devices 100. Thereafter, each device 100 may use its private key and the public key of another device to perform Diffie-Hellman to derive the shared secret 134. In the illustrated embodiment, the private key material 132 of the device 100 includes data for establishing the shared secret 134, the private key of this device 100, the received public key, and / or additional key material for driving or authenticating these keys. For example, as will be discussed below with FIG. 3, the private key material 132 may also include an identity key for authenticating the DH key, which may further be a temporary key. After the key exchange 122, the circuit 120 may further use the shared secret 134 stored in the secure memory 130 to encrypt the sensitive data object 112. Then, the application 110 may send the encrypted data object 112 (without accessing the shared secret 134). Thereafter, the device 100B may use its derived shared secret 134 to decrypt the securely encrypted data object 112. In some embodiments, the device 100B uses another instance of the cryptographic circuit 120 and the secure memory 130 to implement its side of the key exchange 122; in other embodiments, the device 100B may implement the exchange 122 in a different manner than the device 100A. In some embodiments, a user may want to share the sensitive data object 112 with different devices, but control the devices authorized to participate in the key exchange 122 (and thus authorized to receive the object 112). For example, a user may want to share sensitive data among his or her devices, which may be different from each other (e.g., devices using different types of platforms, processor services, manufacturers). For example, a user of a credential manager may want to share a password from one or more of the devices associated with an Apple ® account to an Android ® device associated with a Google ®Devices, although each device is associated with a different platform. As will be discussed in some embodiments below, an authorization hierarchy can be used to authorize and authenticate participating devices 100, where, for example, Google ® can establish and verify the ownership of Android ® devices, while Apple ® can establish and verify the ownership of Apple ® devices. Thus, the group of devices authorized to participate in the key exchange 122 can be verifiable to prevent unauthorized devices from obtaining sensitive data objects 112. Now turning to FIG. 2, a block diagram depicting an example of an authorization hierarchy 200 for authorizing key exchange is shown. In the illustrated embodiment, the authorization hierarchy 200 includes a key authorization unit 210, participant authorization units 220A and 220B, and devices 100A and 100B belonging to device groups 230A and 230B, respectively. In some embodiments, the authorization hierarchy 200 can be implemented in different ways. For example, the hierarchy 200 may include additional device groups, participant authorization units, key authorization units, etc. In various embodiments, a device group 230 is a set of devices 100 that can share one or more common characteristics with each other. For example, the devices 100 in a given group 230 can be devices belonging to a single user, family members, employees working in the same office, devices sharing the same operating system, applications, underlying hardware, manufacturers, servers belonging to the same server cluster, etc. As described above, a user may desire to transfer sensitive data between devices in different groups without the participation of unauthorized devices. For example, family members with various devices may desire to share sensitive data objects 112, such as digital car keys, website passwords, etc. To ensure that unauthorized devices do not participate in the key exchange to obtain sensitive data objects 112, the authorization hierarchy 200 provides a way to verify the devices 100 authorized to participate in the key exchange 122. In various embodiments, a key authority (KA) 210 is configured to authorize a particular participant group 230 of a trusted computing system by identifying a participant authority (PA) 220, which in turn identifies members of the group 230. In the illustrated embodiment, the KA 210 grants permissions to the PA 220 by generating a key authorization 214. In some embodiments, the KA 210 may initially receive a request for a key exchange between devices of an authorized group 230A and devices of a group 230B, along with the public keys 222B1 and 222B2 of the respective PAs 220A and 220B responsible for identifying group membership. For example, the KA 210 may provide a network interface that allows a trusted person to provide these public participant authority keys (PAKs) 222B, or commission a computing system to act as the PA 220, which separately provides their PAKs 222B. As shown, the KA 210 may use a private key authority key (KAK) 212A to sign the key authorization 214, which includes the public PAK 222B1 of the PA 220A and the public PAK 222B2 of the PA 220B. Subsequently, the corresponding public key 212B of the private KAK 212A may be distributed to the PA 220 and the devices 100 to verify the signature of the key authorization 214. When signing multiple PAKs 222B with the same key authorization 214, the KA 210 grants the PA 220 the permission to determine group membership, but also binds their respective groups 230A and 230B together such that the PA 220 cannot grant permissions to some other group to participate in the key exchange 122 with groups 230A and 230B. In some embodiments, the key authorization 214 may include more than two public PAKs 222B to enable more than two groups to participate in the key exchange 122. For example, an IT administrator of a company with three offices may want to enable three site administrators to identify servers that are permitted to communicate with each other, and have the KA 210 issue a single key authorization 214 for the PAs 220 located at each site. However, in another embodiment, multiple key authorizations 214 may be issued to enable the key exchange 122 between the three sites. It should be noted that in other embodiments, the KA 210 directly authorizes individual devices (e.g., devices 110A and 110B), rather than using participant authorities to do so. In this case, the authorized individual devices would be their own participant authorities, and other devices would still be able to verify via the KA 210 whether the device is authorized to perform the key exchange 122. In some embodiments, the key authorization 214 may include additional information that describes the exchange between the participant authorization units 220. This information may restrict the operations that each device 100 can perform on the data object 112 being transmitted, thus implementing the usage policy of the device. For example, the key authorization 214 may include flags that specify that a device 100 registered by the participant authorization unit 220A is allowed to only send a specific data object 112 but not receive the data object 112 from a device 100 registered by the participant authorization unit 220B, while a device 100B registered by the participant authorization unit 220B can only receive the data object 112 from a device 100A registered by the authorization unit 220A. The integrity of these flags can be preserved through the signing of the key authorization 214. Thus, the cryptographic circuit 120 can protect the specified usage policy from tampering by verifying the key authorization 214 (e.g., using the public KAK 212B), and stop the execution of the key exchange 122 if the verification fails. In various embodiments, the PA 220 is a trusted computing system configured to establish and maintain the group membership of a specific group 230. In the illustrated embodiment, the PA 220 identifies the membership of the device 100 in a specific group by generating a participant authentication 224. To generate the authentication 224, the device 100 may initially generate (e.g., using the cryptographic circuit 120) a participant identity key (PIK) pair 232 to be associated with the identity of the device 100. Then, the device 100 may send a registration request to cause the participant authorization unit 220 to issue an authentication 224 that identifies the device 100 as a member of the device group 230. In some embodiments, the request includes account information of a user account, which is associated with each device of the group 230 and can be used by the PA 220 to determine that the device 100 should be a member of the device group 230. In some embodiments, the PIK pair 232 is derived using previously stored key data 132 (e.g., the unique identifier (UID) discussed in FIG. 6), which is trusted by the PA 220 and can be used by the PA 220 to authenticate the device 100. Continuing with the cryptographic sharing example mentioned above, the KA 210 may be a server associated with a cross-platform password manager, which can be used by users of devices having two separate platforms such as Android ® and Apple ® ). Then, the KA 210 may issue a key authorization 214 for the user's account to grant permissions to the PAs 220A and 220B associated with these platforms to identify the devices associated with the user's iCloud ®Group 230A of device 100A associated with the account and Google of the user ® Group 230B of device 100B associated with the account. After determining that device 100 should be a member of group 230, PA 220 can then provide participant authentication 224 that includes the public PIK 232B of device 100 and is signed by the private PAK 222A. Then, this authentication 224 can be verified by verifying its signature using the corresponding public PAK 222B included in key authorization 214. PA 220 can repeat this process for all devices registered in a given group 230. As will be discussed next in conjunction with FIGS. 3A-3B, two devices 100A and 100B in different groups 230A and 230B can then participate in key exchange 122, where they can use the previously obtained key authorization 214 and their respective participant authentications 224 to confirm that the members of group 230 are authorized to participate in key exchange 122. This exchange 122 can also include the exchange of a participant exchange key (PEK) 234 that is authenticated by their private PIK 232A. Now turning to FIG. 3A, a communication diagram of key exchange communication 300 for implementing key exchange 122 is depicted. In the illustrated embodiment, key exchange 300 includes steps for both key exchange 122 and sending data object 112. In some embodiments, key exchange 300 can be implemented in a manner different from that shown, e.g., the steps can be performed in a different order, simultaneously, or omitted; key exchange 300 can include more steps than those shown; etc. In various embodiments, security circuit 120 implements various steps of the steps discussed regarding communication 300. As shown, key exchange 300 begins at step 302, where device 100A verifies key authorization 214 and participant authentication 224 from participant authorization unit 220A to confirm that it has been authorized to participate in exchange 122. Thus, device 100A can initially use the stored copy of public KAK 212B to verify key authorization 214 (and thus verify public PAKs 222B1 and 222B2) to verify the signature in authorization 214. Then, device 100A can use the stored copy of public PAK 222B1 to verify its participant authentication 224 to confirm its membership in group 230A associated with PA 220A. At 304, security circuit 120 in device 100A loads sensitive data object 112 from application 110 to share the sensitive data object with device 100B. The key exchange 300 continues at step 306 (which may be performed in parallel with steps 302 to 304), where device 100B verifies the key authorization 214 and the participant authentication 224 from the participant authorization unit 220B. Similar to step 302, device 100B may verify its participant authentication 224 and key authorization 214 to confirm that device 100B is registered in group 230B and is authorized to perform the key exchange 122. At step 308, device 100B generates and verifies a temporary participant exchange key (PEK) pair 234. In various embodiments, device 100B authenticates the pair 234 by signing the public key of the pair 234 using its private PIK 232A, which is authenticated by its participant authentication 224. At step 310, device 100B sends its authenticated public PEK 234B and its participant authentication 224 including its public PIK 232B to device 100A. At step 312, device 100A verifies the key authorization 214 and the participant authentication 224 of device 100B. Accordingly, device 100A may use the key authorization 214 included in the public PAK 222B2 of PA 220B (which has been verified in step 302) to verify the participant authentication 224 of device 100B (and thus the public PIK 232B of device 100B) to confirm the membership of device 100B in group 230B. Then, device 100A may further use the public PIK 232B included in the participant authentication 224 of device 100B to verify the signature of the authenticated public PEK 234B of device 100B. At step 314, in response to successful verification, device 100A generates its own PEK pair 234 and authenticates the PEK pair by signing the public PEK 234B using its private PIK 232A authenticated by its participant authentication 224. At step 316, device 100A then performs Elliptic Curve Diffie-Hellman (ECDH) using its private PEK 234A and the public PEK 234B of device 100B (verified in step 312) to derive the shared secret 134. Then, at step 318, device 100A may use the shared secret 134 to encrypt the sensitive data object 112. The key exchange communication 300 continues in Figure 3B, which depicts the remainder of the communication 300, where, at step 320, device 100A sends its participant authentication 224, which includes the public PIK 232B, its public PEK 234B (authenticated using the private PIK 232A), and the encrypted data object 112. At step 322, similar to step 312, device 100B verifies key authorization 214 and participant authentication 224 of device 100A, including verifying participant authentication 224 of device 100A and the signed public PEK 234B. In response to successful verification, device 100B performs EDCH at step 324 to derive the same shared secret 134 using the private PEK 234A of device 100B and the public PEK 234B of device 100A. Finally, at step 326, device 100B decrypts the encrypted data object 112 using the derived shared secret 134. As discussed, key exchange 300 depends on multiple authentications 214 and 224. If there is any break in the authentication chain (e.g., signature verification fails for one of the authentications 214 or 224), then device 100 may suspend the execution of key exchange 300 (and thus suspend the exchange of sensitive data object 112). As will be discussed next with FIGS. 4A - 4C, there may be situations in which it is desired to revoke the ability of a given device 100, PA 220, or KA 210 to participate in the authorization hierarchy 200. Various revocation procedures will now be discussed. Now turning to FIG. 4A, a block diagram depicting participant revocation 400A is shown. In some cases, the owner of device 100 may control device 100 but wishes not to continue using the device, such as when the owner is selling or giving the device 100 to another person. While the owner still has device 100, the owner may initiate participant revocation 400A to prevent the next user of device 100 from using the device to obtain data objects 112 belonging to the original owner. As shown, participant revocation 400 may begin with device 100 receiving a request 401 to revoke its membership in group 230. In some embodiments, request 401 is received by a user interacting with the graphical user interface of device 100A; in other embodiments, request 401 is generated remotely by a user or administrator interacting with a server, which then sends request 401 to device 100A. In response to receiving request 401, device 100 then deletes its private PIK pair 232, thereby preventing it from being able to authenticate any PEK pairs 234 that may be generated in any subsequent key exchange 122. Device 100 may also send a revocation request 402 notifying PA 220 of the revocation, such that PA 220 does not issue any new participant authentications 224 for any subsequently generated PIK pairs 232. In other cases, the device may not be available to participate in revocation 400A, and thus an alternative revocation procedure may be used, as described below with reference to FIG. 4B. Now turn to FIG. 4B, which depicts a block diagram of participant revocation 400B. In some cases, if, for example, device 100A1 is offline, stolen, or lost, then device 100A1 may not be available to participate in the revocation process. As such, another device 100A2 (which may be a member of the same group 230) can be used to revoke the membership of device 100A1 by performing revocation 400B. As shown, revocation 400B can begin with device 100A2 receiving a request 411 to revoke the membership of device 100A1 (which may have been lost, for example). In response to request 411, device 100A2 sends a revocation request 412 to its participant authorization unit 220, notifying of the desire to revoke device 100A1. Since the lost device 100A1 may still possess a PIK pair 232 with a corresponding participant authentication 224, it may be reasonable to revoke all devices 100 in a given group and re-register the devices 100 that are still members. To accomplish this, PA 220 can replace its old PAK pair 222 (including old private PAK 222A1) with a new PAK pair 222 (including new private PAK 222A1), and request KA 210 to issue a new key authorization 214 that includes the new public PAK 222B1. In some embodiments, device 100A2 sends another registration request 413 to participant authorization unit 220A to authenticate the new PIK pair 232 of device 100A2. PA 220 can then send a new participant authentication 224 that includes the new public PIK 232B. PA 220 can then repeat this process for other valid devices 100 that are still members of group 230. After performing revocation 400B, the lost device 100A1 no longer has a PIK pair 232 that can be used to verify with the newly issued key authorization 214, thus preventing it from participating in key exchange 122 with any other member. Although not shown, a similar process to revocation 400B can be performed to revoke a given PA 220, where KA 210 can be contacted to replace a given key authorization 214 with a new key authorization 214 that has a new public PAK 222B1 associated with the new PA 220 (and public PAK 222B2 associated with the other remaining PAs 220B). Now turn to FIG. 4C, which depicts a block diagram of key authorization unit revocation 450. In some cases, it may be desirable to revoke a specific KA 210, although this may rarely occur. For example, the server implementing a given KA 210A may lose its private KAK212A, become compromised, or encounter some problem that prevents it from signing additional key authorizations 214. In the illustrated embodiment, revocation 450 provides a way to not only revoke the previous KA 210A but also register a new KA 210B. In some embodiments, revocation 450 may commence before revoking any judgment for a given KA 210, such as when the authorization hierarchy 200 is initially established. As shown, the key authorization unit 210A may initially sign the DR authentication 460 of the disaster recovery (DR) key pair 462 to achieve its future revocation should such an event become necessary. In some embodiments, the KA 210A may generate the DR key pair 462 and share the DR key pair with the device 100 ; If revocation of KA 210A becomes necessary, the device 100 may use the DR key pair 462 and DR authentication 460 to establish another key authorization unit 210B . As shown, device 100 may delete the old public KAK 212B 1 (and its authentication chain depends on any key information of the old KAK to 212A) and send a request 465 to the new key authorization unit 210B requesting its registration in the hierarchy 200 . In response, the new KA 210B generates a new KAK pair 212 and sends the new public KAK 212B2 back to device 100 , which may use the private DR key 462A to sign the new key authorization unit authentication 470 including the new public KAK 212B2 . In some embodiments, device 100 may also use private DR key 462A to sign the request (not illustrated) so that other members of group 230A and 230B do not continue to use the revoked key authorization 214 of the old KA 210A. Once the new KA 210B has received the key authorization unit certification 470 , it may continue to generate the key authorization 214 as part of the new hierarchy 200 that replaces the old hierarchy. Despite depicted as being executed by device 100 , another device having access to the private DR key 462A may authenticate 470 using the new key authorization unit. For example, the owner of device 100A may share a DR key 462A with another device (e.g., from device 100A via key exchange 122 ), which allows the owner to register both the device 100A and the other device in the new hierarchy 200 . Turning now to Figure 5 depicting a block diagram of the Secure Enclave Processor (SEP) 500 . In the illustrated embodiment, SEP 500 includes a filter 510, a security mailbox mechanism 520, a processor 530, a security ROM 540, a password circuit 120, a security memory 130, and a biosensor line 560 coupled together via an interconnector 570 . In some embodiments, the SEP 500 may include more (or fewer) components than shown in FIG. In various embodiments, the SEP 500 is a safety circuit with tamper resistance. In the illustrated embodiment, the SEP 500 implements tamper resistance by using a filter 510 and a security mailbox 520 . The filter 510 is a circuit system configured to strictly control access to the SEP 500 to increase the isolation of the SEP 500 from the rest of the device 100, and thus increase the overall security of the device 100. More specifically, in some embodiments, the filter 510 may allow read / write operations from the processor 102 (or in some embodiments other coupled peripheral devices coupled to the interconnect 502) to enter the SEP 500 only when the operation-addressing secure mailbox 520 is being operated. Other operations may not progress from the interconnect 502 into the SEP 500. Even more specifically, the filter 510 may allow write operations to the addresses assigned to the inbox portion of the secure mailbox 520, and read operations to the addresses assigned to the outbox portion of the secure mailbox 520. All other read / write operations may be blocked / filtered by the filter 510. In some embodiments, the filter 510 may use an error to respond to other read / write operations. In one embodiment, the filter 510 may absorb the write data associated with the filtered write operation without passing the write data onto the local interconnect 570. In one embodiment, the filter 510 may supply nonce data as the read data for the filtered read operation. The nonce data (e.g., "garbage data") may generally be data that is not associated with the addressed resources within the SEP 500. The filter 510 may supply any data as the nonce data (e.g., all zeros, all ones, random data from a random number generator, data programmed into the filter 510 to respond as read data, the address of a read transaction, etc.). Thus, the filter 510 may prevent direct access by external entities such as the processor 102 to the internal components 530 to 570. In various embodiments, the filter 510 may only filter incoming read / write operations. Thus, the components of the SEP 500 may have full access to the other components of the computing device 100. Thus, the filter 510 may not filter responses from the interconnect 502 provided in response to read / write operations issued by the SEP 500. In some embodiments, the secure mailbox 520 includes circuitry for an inbox and an outbox. Both the inbox and the outbox can be first-in, first-out buffers (FIFO) for data. The buffers can be of any size (e.g., any number of entries, where each entry is capable of storing data from read / write operations). Specifically, the inbox can be configured to store write data from write operations originating from the interconnect 502. The outbox can store write data from write operations originating from the processor 530. (As used herein, a "mailbox mechanism" refers to a memory circuit that temporarily stores 1) the input of a secure circuit until it can be retrieved by the circuit and / or 2) the output of a secure circuit until it can be retrieved by an external circuit.) In some embodiments, software executing on the processor 102 (such as application 110, (or other peripheral devices coupled to the interconnect 502)) can request services of the SEP 500 via an application programming interface (API) supported by the operating system of the device 100, i.e., the requester can make an API call to request services of the SEP 500. These calls can cause the corresponding requests to be written to the mailbox mechanism 520 and then retrieved from the mailbox 520 and analyzed by the processor 530 to determine whether it should service the requests. Thus, this API can be used to send, e.g., key exchange requests 114, key data 132 received from another device 100 participating in the key exchange 122, sensitive data objects 112 for encryption or decryption, biometric data, etc. via the mailbox 520. By isolating the SEP 500 in this manner, the integrity of the SEP 500 can be enhanced, including preventing, e.g., malicious programs running on the processor 102 from retrieving private key data 132, shared secrets 134, biometric data, etc. The SEP processor 530 is configured to process commands received from various sources in the computing device 100 and can use various security peripherals to complete the commands. Next, the processor 530 can execute instructions stored in the ROM 540 (or elsewhere, such as in the memory 104) (such as the manager 542), which can use the components of the SEP 500 to facilitate the execution of the various actions described above regarding the key exchange 122. For example, in response to receiving a request 114 for performing the key exchange 122, the SEP processor 530 can execute the manager 542 to provide appropriate commands to notify the cryptographic circuit 120 of the received request 114. The manager 542 can also interact with other components of the SEP 500, and if, for example, the key exchange 122 (or the use of the key material 132 or the shared secret 134) depends on the successful biometric authentication of the user of the device 100, it can facilitate the key exchange 122, such as the biometric sensor pipeline 560. The secure ROM 540 is a memory configured to store program instructions for booting the SEP 500. In some embodiments, the ROM 540 may only respond to a specific address range assigned to the secure ROM 540 on the local interconnect 570. The address range may be hardwired, and the processor 530 may be hardwired to extract from the address range at boot time to boot from the secure ROM 540. The filter 510 can filter the addresses within the address range assigned to the secure ROM 540 (as mentioned above), thereby preventing access to the secure ROM 540 from components external to the SEP 500. In some embodiments, the secure ROM 540 may include other software executed by the SEP processor 530 during use. This software may include program instructions of the manager 542 to perform the key exchange 122, process inbox messages, and generate outbox messages, etc. In some embodiments, the program instructions executed by the SEP processor 530 are signed by a trusted authority (e.g., the manufacturer of the device 100) to ensure their integrity. These program instructions may include program instructions stored in the secure ROM 540 and program instructions stored externally (such as in the memory 104); however, these externally stored program instructions can have their signatures verified by the program instructions in the ROM 540 before being allowed to be executed by the processor 530. In various embodiments, the biometric sensor pipeline 560 is configured to authenticate a user by comparing biometric data captured by the biometric sensor of device 100 from the user being authenticated with biometric data 562 of an authorized user that may be stored in memory 104 or elsewhere. As used herein, "biometric data" refers to data that uniquely identifies (at least with high accuracy) a user among other people based on the user's physical or behavioral characteristics. In some embodiments, the biometric sensor is configured as a camera that collects facial data (or eye data) of the user to perform facial recognition (or iris recognition). In other embodiments, the biometric sensor may be configured to collect other forms of biometric data, such as voice recognition data, fingerprint data, vein data, and the like. In some embodiments, the pipeline 560 may use a collection of neural networks included in the pipeline 560 to perform the comparison, each network being configured to compare biometric data captured in a single frame with biometric data of an authorized user captured in multiple frames. As shown in the figure, the pipeline 560 may be configured to read biometric data 562 from memory 104, which in some embodiments may be encrypted and / or stored in an associated portion of memory 104 that is accessible only to the SEP 500. (In another embodiment, the SEP 500 may store biometric data 562 internally.) Based on the comparison of the biometric data 562, the pipeline 560 may provide an authentication result / confirmation indicating whether the authentication was successful or failed, which in some embodiments may be used to determine whether to allow the use of private key data and / or shared secret 134. Various components of the SEP 500 may facilitate the cryptographic circuit 120 to implement the key exchange 122 and help improve the security of the circuit 120. Now turning to FIG. 6, a block diagram depicting components within the cryptographic circuit 120 is shown. As shown, the cryptographic circuit 120 may include a sequencer 610, a public key accelerator (PKA) intellectual property (IP) 620, a PKA ROM 630, a RAM 640, fuses 650, a random number generator (RNG) IP 660, and a hash IP 670 connected using interconnects 680. In the illustrated embodiment, the secure memory 130 includes the ROM 630, the RAM 640, and the fuses 650. In other embodiments, the circuit 120 may be implemented in a different manner and include more (or fewer) components. For example, the RNG IP 660 and the hash IP 670 may be external to the circuit 120 but included in the SEP 500, and the secure memory 130 may not include the fuse 550, etc. The sequencer 610 is configured to decode commands received from the SEP processor 530 and generate a series of sub-commands / program instructions for the PKA IP 620 (or other components in the cryptographic circuit 120) to implement the commands. For example, such commands may include commands for generating key pairs for private key data 132, encrypting or decrypting data using the key pair, signing data, verifying data, implementing ECDH, etc. They may also include commands for generating random numbers and hash values for the RNG IP 660 and the hash IP 670. In the illustrated embodiment, the sequencer 610 accesses the PKA ROM 630 to extract sub-commands to provide to the components in the cryptographic circuit 120. In some embodiments, the sequencer 610 may employ the logic and / or program instructions stored in the ROM 630 to decode the received commands and issue corresponding sub-commands. The PKA IP 620 is a circuit system configured to perform various public key cryptographic operations (such as those described above) on the private key data 132 to implement the key exchange 122. Accordingly, the PKA IP 620 may include logic for implementing Rivest Shamir Adleman (RSA), Digital Signature Algorithm (DSA), Elliptic Curve Cryptography (ECC), etc. Although described as a public key accelerator, the IP 620 may support other cryptographic algorithms, such as those described above. In some embodiments, the PKA IP 620 may be the only circuit system capable of accessing the private key data 132 in the secure memory 130. The PKA IP 620 may also interact with other components in the cryptographic circuit 120 (such as the RNG IP 660 and the hash IP 670) to perform various operations, such as key and signature generation, signature verification, etc. The PKA ROM 630 is a ROM configured to store immutable program instructions 632 that can be executed by the components of the cryptographic circuit 120 to perform various operations described herein regarding the circuit 120, including the execution of the key exchange 122. In various embodiments, such instructions are stored in the ROM 630 during manufacturing and are thus known to be trustworthy. During manufacturing, the ROM 630 may also be provided with static data used by the circuit 120. As described above, by storing the program instructions 632 and data in the ROM 630 such that they are immutable, the security of the cryptographic circuit 120 (and thus the key exchange 122) is improved. The RAM 640 is configured to store various intermediate results generated by the PKA IP 620 during operation. In the illustrated embodiment, these results include the private PIK 232A and the private PEK 234A, or other components of the private key material 132. The RAM 640 may also include the shared secret 134, key material received from the device 100B, key authorization 214, participant authentication 224, etc. To further increase security, the cryptographic circuit 120 can execute a sequence of program instructions in a specific order to perform the key exchange, and prevent out-of-order execution of the sequence by clearing portions of the secure memory between the execution of instructions, so as to prevent out-of-order executed instructions from affecting the instructions executed subsequently. For example, in response to receiving a given program instruction in the sequence, zero (or some other preset value) can be written to a portion of the secure memory used by the next program instruction in the specific order. The fuse 650 is configured to store a fuse bank of key material that can be used by the cryptographic circuit 120 to derive a portion of the private key material 132 used in the key exchange 122. In the illustrated embodiment, this key material includes a unique identifier (UID) 652 that uniquely identifies the device 100A from other devices. This key material may also include a generation identifier (GID) that is unique for a particular generation of devices, etc. These values can be recorded by burning various fuses 650 during the manufacture of the device 100A. In various embodiments, components external to the cryptographic circuit 120 (or external to the SEP 500), such as the processor 102, cannot access the fuses 650. The RNG IP 660 is configured to generate a circuit system of random numbers used by various components in the cryptographic circuit 120. Accordingly, the RNG IP 660 can provide a random value to the PKA IP 620 to be stored as part of the private key material 132 in the RAM 640. Although the RNG IP 660 can implement a pseudo-random number generator in some embodiments, the RNG IP 660 implements a true random number generator using an external random source (such as the measured temperature, etc.) in other embodiments. In various embodiments, components external to the SEP 500, such as the processor 102, cannot access the RNG IP 660. The hash IP 670 is a circuit system configured to implement any suitable hash algorithm, such as the secure hash algorithm (SHA), the hash-based message authentication code (HMAC), etc., which can be used by the components in the SEP 500. Therefore, the hash IP 670 can generate hash values, which are encrypted / signed by the PKA IP 620 or compared by the PKA IP 620 in signature verification. Now turning to FIG. 7, a flowchart depicting a method 700 for establishing a shared secret between two devices is shown. Method 700 is an example of a method executed by a computing device (such as device 100A), which may include a cryptographic circuit 120. In some cases, the execution of method 700 may allow a device (e.g., device 100A) to establish a shared secret (e.g., shared secret 134) without revealing key data (e.g., private key data 132) and compromising the components of the device. In step 705, a request (e.g., via request 114) is made to perform a key exchange (e.g., key exchange 122) to establish a shared secret with another device (e.g., device 100B). In step 710, the cryptographic circuit (e.g., cryptographic circuit 120) performs a key exchange, which includes using private key data stored in a secure memory (e.g., secure memory 130) to derive a shared secret. In some embodiments, deriving the shared secret includes using the private key data to perform Elliptic Curve Diffie-Hellman (ECDH). In some embodiments, the processor exchanges sensitive data (e.g., symmetric keys, asymmetric private keys, authentication credentials, transaction credentials, etc.) encrypted with the derived shared secret with another device. In some embodiments, the cryptographic circuit is a public key accelerator (e.g., PKA 620). In some embodiments, the device further includes a read-only memory (ROM) (e.g., PKA ROM 630), which stores immutable program instructions that can be executed by the cryptographic circuit to perform the key exchange. In some embodiments, the cryptographic circuit is also configured to execute a sequence of program instructions in a specific order to perform the key exchange and prevent out-of-order execution of the sequence by clearing a portion of the secure memory used by the next program instruction in that specific order in response to receiving a given program instruction in the sequence. In some embodiments, method 700 further includes a cryptographic circuit that verifies a key authorization data structure (e.g., key authorization 214) from a key authorization entity (e.g., key authorization entity 210) to indicate that the computing device is authorized to participate in a key exchange with another device, wherein the key authorization data structure includes a public key associated with the computing device (e.g., public PAK 222B1), and a public key associated with the other device (e.g., public PAK 222B2). In some embodiments, the key authorization data structure indicates authorization for a key exchange between a first device group (e.g., device group 230A) and a second device group (e.g., device group 230B), wherein the public key associated with the computing device belongs to a first participant authorization entity (e.g., participant authorization entity 220A) authorized to identify the computing device as a member of the first device group, and the public key associated with the other device belongs to a second participant authorization entity (e.g., participant authorization entity 220B) authorized to identify the other device as a member of the second device group. In some embodiments, method 700 further includes a random number generator circuit (e.g., RNG IP 660) coupled to the cryptographic circuit and not accessible by the processor, and the processor provides a random value to the cryptographic circuit for storage as part of the private key data in a secure memory. In some embodiments, a fuse bank (e.g., fuse 650) coupled to the cryptographic circuit and not accessible by the processor is configured during manufacture of the cryptographic circuit to store key data (e.g., UID 652) that can be used by the cryptographic circuit to derive a portion of the private key data stored in the secure memory. In some embodiments, method 700 further includes determining whether the key exchange is authorized by verifying a plurality of authentications (e.g., participant authentication 224) associated with the public key pair exchanged during the key exchange. The plurality of authentications can include a first key authentication (participant authentication 224) that identifies the public key of the computing device (e.g., public PIK 232B) as corresponding to a member of a first device group (e.g., device group 230A), and a second key authentication that identifies the public key of the other device as corresponding to a member of a second device group (e.g., device group 230B). The plurality of authentications can further include a key exchange authorization (e.g., key authorization 214) that identifies a first public key (e.g., public PAK 222B1) of a first participant authorization entity (e.g., participant authorization entity 220A) that identifies the public key of the computing device as corresponding to a member of the first device group; and the key exchange authorization identifies a second public key (e.g., public PAK 222B2) of a second participant authorization entity (e.g., participant authorization entity 220B) that identifies the public key of the other device as corresponding to a member of the second device group. In some embodiments, in response to the issuance of a key authorization data structure, a disaster recovery (DR) key pair (e.g., keys 462A to 462B) generated by a key authorization entity (e.g., the revoked key authorization entity 210A) is received. In this embodiment, in response to the subsequent revocation of the key authorization entity (e.g., via key authorization entity revocation 450), the DR key pair is used to establish another key authorization entity (e.g., the new key authorization entity 210B). Turning now to FIG. 8A, a flowchart of a method 800 for establishing a shared secret between two devices is depicted. Method 800 is another embodiment of a method executed by a first computing device (such as device 100A) belonging to a first device group (such as device group 230A). In some cases, the execution of method 800 may allow for a more secure execution of key exchange as an authorization hierarchy can be used to authenticate the participants. In step 805, the computing system receives a request (e.g., request 114) to perform a key exchange (e.g., key exchange 122) to establish a shared secret (e.g., shared secret 134) with a second device (e.g., device 100B) belonging to a second device group (e.g., device group 230B). In step 810, the computing system verifies a key authorization data structure (e.g., key authorization 214) issued by a key authorization entity (e.g., key authorization entity 210), where the key authorization data structure includes a first public key (e.g., public key PAK 222B1) of a first participant authorization entity (e.g., participant authorization entity 220A) authorized to identify members of the first device group, and a second public key (e.g., public PAK 222B2) of a second participant authorization entity (e.g., participant authorization entity 220B) authorized to identify members of the second device group. In step 815, in response to successful verification, the computing device performs the requested exchange using a public key pair (e.g., PEK pair 234) authenticated by the first participant authorization entity as belonging to a member of the first device group. In some embodiments, method 800 further includes exchanging sensitive data (e.g., symmetric keys, user authentication credentials, asymmetric (private) keys) encrypted using the established shared secret with the second device. In some embodiments, method 800 further includes generating a Participant Identity Key (PIK) pair (e.g., PIKs 232A to 232B) associated with the identity of the first device, and sending a request to cause the first participant authorization unit to issue an authentication that identifies the PIK pair as being associated with a member of the first device group. In this embodiment, the generating may include using previously stored key material (e.g., UID 652) trusted by and usable by the first participant authorization unit to derive the PIK pair to establish that the first device is a member of the first device group. In some embodiments, the request includes account information of user accounts associated with each of the first device groups, and the account information can be used by the first participant authorization unit to determine that the first device is a member of the first device group. In some embodiments, performing the requested exchange may include: generating a temporary first participant exchange key (PEK) pair (e.g., PEK pair 234) authenticated by the PIK pair; exchanging the public key of the first PEK pair and the public key of a second PEK pair generated by the second device with the second device; and deriving a shared secret by performing Elliptic Curve Diffie-Hellman (ECDH) using the private key of the first PEK pair and the exchanged public key of the second PEK pair. In some embodiments, method 800 further includes receiving a revocation request (e.g., revocation request 402) to revoke the membership of the first device in the first device group, and in response to the revocation request, deleting the public key pair authenticated by the first participant authorization unit, and sending a request to the first participant authorization unit to remove the first device from the first device group. In some embodiments, method 800 further includes receiving a revocation request (e.g., revocation request 412) to revoke the membership of another device (e.g., lost device 100A1) in the first device group, and in response to the revocation request, sending a request to the first participant authorization unit to replace the first public key of the first participant authorization unit with another public key (new public PAK 222B1), and sending a request to the first participant authorization unit to authenticate another public key pair (e.g., via new participant authentication 224) using the private key corresponding to the other public key (e.g., new private key PAK 222A1). In some embodiments, method 800 further includes receiving a disaster recovery (DR) key pair certified by a key authorization entity (e.g., DR keys 462A to 462B associated with DR certification 460), and in response to determining that it is necessary to revoke the key authorization entity, signing a request using the private key of the DR key pair (e.g., private DR key 462A) so that members of the first and second device groups do not continue to use the key authorization data structure, and signing an authentication for establishing another key authorization entity (e.g., new key authorization entity 210B) for authorizing a key exchange between the first device group and the second device group (e.g., key authorization entity authentication 470) using the private key of the DR key pair. Turning now to FIG. 8B, a flowchart of a method 830 for providing authentication is depicted. Method 830 is an embodiment of a method performed by a participant authorization entity such as participant authorization entity 220A. In some cases, the execution of method 830 can provide benefits similar to those described above using method 800. In step 835, the participant authorization entity receives a request from a first device (e.g., device 100A) for the first participant authorization entity to issue a signed authentication (e.g., participant authentication 224) that indicates that the public key of the first device (e.g., public PIK 232B) belongs to a member of a first device group (e.g., device group 230A) that is authorized to participate in a key exchange (e.g., key exchange 122) with members of a second device group (e.g., device group 230B). In step 840, the participant authorization entity determines whether the first device is a member of the first device group by verifying a key authorization data structure (e.g., key authorization 214) issued by a key authorization entity (e.g., key authorization entity 210), where the key authorization data structure includes a first public key (e.g., public key PAK 222B1) of a first participant authorization entity authorized to identify members of the first device group, and a second public key (e.g., public PAK 222B2) of a second participant authorization entity (e.g., participant authorization entity 220B) authorized to identify members of the second device group. In step 845, the participant authorization entity provides the first device with an authentication signed by a first private key (e.g., private key PAK 222A1) corresponding to the first public key based on the determination. Turning now to FIG. 8C, a flowchart of a method 860 for providing key authorization is depicted. Method 860 is an embodiment of a method performed by a key authorization entity such as key authorization entity 210. In some cases, the execution of method 860 can provide benefits similar to those described above using method 800. In step 865, the key authorization unit receives a request to authorize a key exchange (e.g., key exchange 122) between a first device group (e.g., device group 230A) and a second device group (e.g., device group 230B). In step 870, the key authorization unit signs a key authorization data structure (e.g., key authorization 214), which includes a first public key (e.g., public key PAK 222B1) of a first participant authorization unit (e.g., participant authorization unit 220A) authorized to identify members of the first device group (e.g., device group 230A), and a second public key (e.g., public key PAK 222B2) of a second participant authorization unit (e.g., participant authorization unit 220B) authorized to identify members of the second device group (e.g., device group 230B). In step 875, the key authorization unit provides the signed key authorization data structure to the first and second participant authorization units to authorize the key exchange between members of the first and second device groups. Exemplary computer system Referring now to FIG. 9, a block diagram illustrating an example embodiment of a device 900 is shown. In some embodiments, device 900 may implement the functions of one or both of devices 100A and 100B. In some embodiments, the components of device 900 may be included within a system-on-chip. In some embodiments, device 900 may be included in a mobile device that may be battery-powered. Thus, power consumption of device 900 may be an important design consideration. In the illustrated embodiment, device 900 includes a fabric 910, a compute complex 920, an input / output (I / O) bridge 950, a cache / memory controller 945, a graphics unit 975, a display unit 965, and a SEP 500. In some embodiments, device 900 may include other components (not shown) in addition to or instead of the illustrated components, such as video processor encoders and decoders, image processing or recognition elements, computer vision elements, etc. Fabric 910 may include various interconnects, buses, MUXes, controllers, etc., and may be configured to facilitate communication between the various components of device 900. In some embodiments, portions of fabric 910 may be configured to implement various different communication protocols. In other embodiments, fabric 910 may implement a single communication protocol, and components coupled to fabric 910 may internally translate from the single communication protocol to other communication protocols. In the illustrated embodiment, computing complex 920 includes a bus interface unit (BIU) 925, cache memory 930, and cores 935 and 940. In various embodiments, computing complex 920 may include various numbers of processors, processor cores, and cache memories. For example, computing complex 920 may include 1, 2, or 4 processor cores or any other suitable number. In one embodiment, cache memory 930 is a set associative L2 cache memory. In some embodiments, cores 935 and 940 may include internal instruction and data cache memories. In some embodiments, a coherency unit (not shown) in mesh architecture 910, cache memory 930, or elsewhere in device 900 may be configured to maintain coherency among the various cache memories of device 900. BIU 925 may be configured to manage communication between computing complex 920 and other components of device 900. Processor cores, such as cores 935 and 940, may be configured to execute instructions of a particular instruction set architecture (ISA), which may include operating system instructions and user application instructions. These instructions may be stored in a computer-readable medium, such as a memory coupled to memory controller 945 discussed below. In some embodiments, computing complex may implement processor 102 discussed above. As used herein, the term "coupled to" may indicate one or more connections between elements, and coupling may include intermediate elements. For example, in FIG. 9, graphics unit 975 may be described as "coupled to" memory through mesh architecture 910 and cache / memory controller 945. In contrast, in the illustrated embodiment of FIG. 9, graphics unit 975 is "directly coupled" to mesh architecture 910 since there are no intermediate elements. The cache memory / memory controller 945 can be configured to manage the transfer of data between the mesh architecture 910 and one or more cache memories and memories. For example, the cache memory / memory controller 945 can be coupled to an L3 cache memory, which can in turn be coupled to the system memory. In other embodiments, the cache memory / memory controller 945 can be directly coupled to the memory. In some embodiments, the cache memory / memory controller 945 can include one or more internal cache memories. The memory coupled to the controller 945 can be any type of volatile memory, such as dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate (DDR, DDR2, DDR3, etc.) SDRAM (including mobile versions of SDRAM such as mDDR3, and / or low-power versions of SDRAM such as LPDDR4), RAMBUS DRAM (RDRAM), static RAM (SRAM), etc. One or more memory devices can be coupled to a circuit board to form a memory module, such as a single in-line memory module (SIMM), dual in-line memory module (DIMM), etc. Alternatively, the device can use integrated circuit mounting in a die-on-chip configuration, package-on-package configuration, or multi-chip module configuration. The memory coupled to the controller 945 can be any type of non-volatile memory, such as NAND flash memory, NOR flash memory, nano RAM (NRAM), magnetoresistive RAM (MRAM), phase change RAM (PRAM), racetrack memory, memristor memory, etc. As described above, this memory can store program instructions that can be executed by the computing complex 920 to cause the computing device to perform the functions described herein, such as the program instructions of the application 110. The graphics unit 975 can include one or more processors, for example, one or more graphics processing units (GPUs). For example, the graphics unit 975 can receive graphics-oriented instructions, such as OPENGL ® , Metal ® , or DIRECT3D ®Instructions. The graphics unit 975 can execute specialized GPU instructions or perform other operations based on the received graphics-oriented instructions. The graphics unit 975 can generally be configured to parallel process large data blocks and can create images in a frame buffer for output to a display that can be included in the device or can be a separate device. The graphics unit 975 can include transform, lighting, triangle, and rendering engines in one or more graphics processing pipelines. The graphics unit 975 can output pixel information for displaying images. In various embodiments, the graphics unit 975 can include programmable shader circuitry that can include highly parallel execution cores configured to execute graphics programs that can include pixel tasks, vertex tasks, and compute tasks (which can be or can be non-graphics related). The display unit 965 can be configured to read data from the frame buffer and provide a stream of pixel values for display. In some embodiments, the display unit 965 can be configured as a display pipeline. Additionally, the display unit 965 can be configured to blend multiple frames to produce an output frame. Further, the display unit 965 can include one or more interfaces (e.g., MIPI ® or an embedded display port (eDP)) for coupling to a user display (e.g., a touch screen or an external display). The I / O bridge 950 can include various components configured to implement, for example, Universal Serial Bus (USB) communication, security, audio, and low-power always-on functionality. For example, the I / O bridge 950 can also include interfaces such as pulse-width modulation (PWM), general-purpose input / output (GPIO), serial peripheral interface (SPI), and inter-integrated circuit (I2C). Various types of peripheral devices and apparatuses can be coupled to the device 900 via the I / O bridge 950. In some embodiments, the device 900 includes network interface circuitry (not explicitly shown) that can be connected to the mesh fabric 910 or the I / O bridge 950. The network interface circuitry can be configured to communicate via various networks, which can be wired, wireless, or both. For example, the network interface circuitry can be configured to communicate via a wired local area network, a wireless local area network (e.g., via Wi-Fi ™), or communicate over a wide area network (e.g., the Internet or a virtual private network). In some embodiments, the network interface circuitry is configured to communicate via one or more cellular networks using one or more radio access technologies. In some embodiments, the network interface circuitry is configured to use device-to-device communication (e.g., Bluetooth ® or Wi-Fi ™ Direct), etc. In various embodiments, the network interface circuitry can provide connectivity to various types of other devices and networks to device 900. Example Applications Turning now to FIG. 10, various types of systems can include any of the circuits, devices, or systems discussed above. Systems or devices 1000 that can incorporate or otherwise utilize one or more of the techniques described herein can be used in a wide range of fields. For example, systems or devices 1000 can be used as part of the hardware of a system, such as a desktop computer 1010, a laptop computer 1020, a tablet computer 1030, a cellular or mobile phone 1040, or a television 1050 (or a set-top box coupled to the television). Similarly, the disclosed components can be used in wearable devices 1060, such as smartwatches or health monitoring devices. In many embodiments, a smartwatch can implement various different functions, e.g., accessing email, cellular services, calendars, health monitoring, etc. Wearable devices can also be designed separately to perform health monitoring functions, such as monitoring a user's vital signs, performing epidemiological functions (such as contact tracing), providing communication to emergency medical services, etc. Other types of devices are also envisioned, including devices worn around the neck, devices implantable in the human body, glasses or helmets that are designed to provide a computer-generated reality experience, such as based on augmented and / or virtual reality, etc. Systems or devices 1000 can also be used in a variety of other contexts. For example, systems or devices 1000 can be used in the context of server computer systems, such as dedicated servers or on shared hardware implementing cloud-based services 1070. Further, systems or devices 1000 can be implemented in a wide range of specialized everyday devices, including devices 1080 commonly found in the home, such as refrigerators, thermostats, security cameras, etc. The interconnection of such devices is often referred to as the "Internet of Things" (IoT). The components can also be implemented in various modes of transportation. For example, systems or devices 1000 can be used in the control systems, guidance systems, entertainment systems, etc. of various types of vehicles 1090. The application illustrated in FIG. 10 is merely exemplary and is not intended to limit the potential future applications of the disclosed system or device. Other example applications include, but are not limited to: portable game devices, music players, data storage devices, unmanned aerial vehicles, etc. Example computer-readable media The present disclosure has described various example circuits in detail above. The present disclosure not only intends to cover embodiments including such circuitry, but also intends to cover a computer-readable storage medium including design information specifying such circuitry. Thus, the present disclosure intends to support claims covering not only devices including the disclosed circuitry, but also storage media that specify the circuitry in a format for a programmed computing system to produce a simulation model of the hardware circuitry, a manufacturing system programmed to produce hardware (e.g., an integrated circuit) including the disclosed circuitry, etc. Claims to such storage media are intended to cover, for example, entities that generate circuit designs but do not themselves perform complete operations (such as: design simulation, design synthesis, circuit manufacturing, etc.). FIG. 11 is a block diagram illustrating an example non-transitory computer-readable storage medium storing circuit design information according to some embodiments. In the illustrated embodiment, computing system 1140 is configured to process the design information. This can include executing instructions included in the design information, interpreting instructions included in the design information, compiling, transforming, or otherwise updating the design information, etc. Thus, in some embodiments, the design information controls the computing system 1140 (e.g., by programming the computing system 1140) to perform various operations discussed below. In the illustrated example, the computing system 1140 processes the design information to produce both a computer simulation model of the hardware circuit 1160 and lower-level design information 1150. In other embodiments, the computing system 1140 may produce only one of these outputs, may produce other outputs based on the design information, or both. Regarding the computer simulation, the computing system 1140 may execute instructions of a hardware description language including register transfer level (RTL) code, behavioral code, structural code, or some combination thereof. The simulation model may execute the functionality specified by the design information, facilitate verification of the functional correctness of the hardware design, generate power consumption assessments, generate timing assessments, etc. In the illustrated example, computing system 1140 also processes design information to generate lower-level design information 1150 (e.g., logic gate-level design information, wiring对照表, etc.). This can include synthesis operations as shown, such as constructing a multi-level network, using technology-independent techniques, technology-dependent techniques, or optimizing the network with the best of both, and outputting a network of logic gates (with possible limitations based on available logic gates, sizes, delays, power, etc. in the technology library). Based on the lower-level design information 1150 (possibly in other inputs), semiconductor manufacturing system 1120 is configured to manufacture integrated circuit 1130 (which can correspond to the functionality of simulation model 1160). Note that computing system 1140 can generate different simulation models based on design information at various description levels (including information 1150, 1115, etc.). The data representing design information 1150 and model 1160 can be stored on media 1110 or one or more other media. In some embodiments, the lower-level design information 1150 controls (e.g., programs) semiconductor manufacturing system 1120 to manufacture integrated circuit 1130. Thus, when processed by the manufacturing system, the design information can program the manufacturing system to manufacture circuits including the various circuit systems disclosed herein. The non-transitory computer-readable storage medium 1110 can include any of various suitable types of memory devices or storage devices. The non-transitory computer-readable storage medium 1110 can be an installation medium (e.g., CD-ROM, floppy disk, or tape device); a computer system memory or random access memory (such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.); a non-volatile memory (such as flash, magnetic media (e.g., hard disk), or optical storage); registers or other similar types of memory elements, etc. The non-transitory computer-readable storage medium 1110 can also include other types of non-transitory memory or combinations thereof. Thus, the non-transitory computer-readable storage medium 1110 can include two or more memory media; such media can reside in different locations - for example, in different computer systems connected via a network. Design information 1115 can be specified using any one of a variety of suitable computer languages (including hardware description languages), such as, but not limited to: VHDL, Verilog, SystemC, SystemVerilog, RHDL, M, MyHDL, etc. The formats of the various design information can be recognized by one or more application programs executed by the computing system 1140, the semiconductor manufacturing system 1120, or both. In some embodiments, the design information may also include one or more component libraries that specify the synthesis, layout, or both of the integrated circuit 1130. In some embodiments, the design information is specified, in whole or in part, in the form of a wiring对照表, which specifies component library components and their connections. The design information discussed herein, taken alone, may or may not include sufficient information for manufacturing the corresponding integrated circuit. For example, the design information may specify the circuit components to be manufactured but not their physical layout. In this case, the design information can be combined with layout information to actually manufacture the specified circuit system. In various embodiments, the integrated circuit 1130 may include one or more custom macro cells (such as memories, analog or mixed-signal circuits, and the like). In such a case, the design information may include information related to the included macro cells. Such information can include, without limitation, a circuit diagram extraction database, mask design data, behavioral models, and a device or transistor-level wiring对照表. The mask design data can be formatted according to the Graphics Data System (GDSII) or any other suitable format. The semiconductor manufacturing system 1120 can include any one of a variety of suitable components configured to manufacture an integrated circuit. For example, this can include components for depositing semiconductor materials (e.g., on a wafer that may include a mask), removing materials, changing the shape of the deposited materials, modifying materials (e.g., by doping materials or using ultraviolet treatment to modify the dielectric constant), etc. The semiconductor manufacturing system 1120 can also be configured to perform various tests on the manufactured circuit for proper operation. In various embodiments, the integrated circuit 1130 and the model 1160 are configured to operate according to the circuit design specified by the design information 1115, which can include performing any one of the functions described herein. For example, the integrated circuit 1130 can include any one of the various components shown in FIG. 1 (such as the cryptographic circuit 120 and the secure memory 130). Further, the integrated circuit 1130 can be configured to perform the various functions described herein in combination with other components. Further, the functions described herein can be performed by multiple connected integrated circuits. As used herein, a phrase of the form "design information of a design specifying that a circuit is configured to..." does not mean that the circuit in question must be manufactured to meet that element. Instead, this phrase indicates that a circuit described by the design information, once fabricated, will be configured to perform the indicated actions or will include the specified components. Similarly, the statement "instructions of a hardware description programming language that are "executable" to program a computing system to generate a computer simulation model" does not imply that the instructions must be executed to meet that element, but rather specifies the characteristics of the instructions. In this context, additional features related to the model (or the circuit represented by the model) may similarly be related to the characteristics of the instructions. Thus, even if another entity actually executes the instructions on a computer-readable medium having instructions that meet the described characteristics, the entity selling the medium may offer an infringing product. Note that, at least in the digital logic context, a given design can be implemented using a multitude of different gate configurations, circuit technologies, etc. As an example, different designs may select or connect gates based on design trade-offs (e.g., emphasizing power consumption, performance, circuit area, etc.). Additionally, different manufacturers may have proprietary libraries, gate designs, physical gate implementations, etc. Different entities may also use different tools to process design information at various levels (e.g., from behavioral specifications to physical gate placement). However, once a digital logic design is specified, one of ordinary skill in the art does not need to perform a large amount of experimentation or research to determine such implementations. Instead, one of ordinary skill in the art understands the procedures to reliably and predictably produce one or more circuit implementations that provide the functionality described by the design information. Different circuit implementations may affect the performance, area, power consumption, etc. of a given design (which may involve trade-offs between different design goals), but the logical function does not vary among different circuit implementations of the same circuit design. In some embodiments, the instructions included in the design information instructions provide RTL information (or other higher-level design information) and can be executed by a computing system to synthesize a gate-level wiring list representing a hardware circuit based on the RTL information as input. Similarly, the instructions can provide behavioral information and can be executed by a computing system to synthesize a wiring list or other lower-level design information. The lower-level design information can program a manufacturing system 1120 to manufacture an integrated circuit 1130. *** This disclosure includes references to "an embodiment" or groups of "embodiments" (e.g., "some embodiments" or "various embodiments"). Embodiments are different implementations or examples of the disclosed concepts. References to "an embodiment", "one embodiment", "a particular embodiment", and the like do not necessarily refer to the same embodiment. A large number of feasible embodiments are contemplated, including those specifically disclosed, as well as modifications or alternatives that fall within the spirit or scope of this disclosure. This disclosure may discuss potential advantages that may result from the disclosed embodiments. Not all implementations of these embodiments will necessarily exhibit any or all of the potential advantages. Whether the advantages achieved for a particular implementation depend on many factors, some of which are outside the scope of this disclosure. In fact, there may be many reasons why implementations within the scope of the claims may not exhibit some or all of the disclosed advantages. For example, a particular implementation may include other circuitry outside the scope of this disclosure that, when combined with one of the disclosed embodiments, invalidates or diminishes one or more of the disclosed advantages. Additionally, suboptimal design implementation of a particular implementation (e.g., the implementation technology or tool) may also invalidate or diminish the disclosed advantages. Even assuming a skilled implementation, the realization of the advantages may still depend on other factors, such as the environmental circumstances in which the implementation is deployed. For example, the input supplied to a particular implementation may prevent one or more of the problems addressed in this disclosure from occurring in a particular instance, with the result that the benefits of its solution may not be realized. Given the existence of possible factors outside the scope of this disclosure, it is expressly intended that any potential advantages described herein not be construed as necessary to meet claim limitations to prove infringement. Rather, the identification of such potential advantages is intended to illustrate the types of (multiple) improvements available to designers who have the benefit of this disclosure. The description of such advantages as permissibly described (e.g., stating that a particular advantage "may result in") is not intended to convey doubt as to whether such advantages can actually be achieved, but rather to recognize that the technical reality of achieving such advantages often depends on additional factors. Unless otherwise stated, the embodiments are non-limiting. That is, the disclosed embodiments are not intended to limit the scope of the patent application claims drafted based on this disclosure, even if only a single example regarding a specific feature is described. The disclosed embodiments are intended to be illustrative rather than restrictive, and there is no statement to the contrary in this disclosure. Accordingly, this application is intended to allow the patent application claims to cover the disclosed embodiments as well as such alternatives, modifications, and equivalents that would be obvious to one of ordinary skill in the art benefiting from this disclosure. For example, the features in this application can be combined in any suitable manner. Accordingly, new claims can be formulated for any such combination of features during the examination of this application (or an application claiming its priority). Specifically, referring to the appended patent application claims, the features from an independent claim can be combined with the features of other independent claims, if appropriate, including claims dependent on other dependent claims. Similarly, if appropriate, the features from individual dependent claims can be combined. Accordingly, although the appended dependent claims may be drafted such that each depends on a single other claim, additional dependencies are also contemplated. Any combination of the features of the dependent items consistent with this disclosure is contemplated and can be claimed in this application or another application. In short, the combinations are not limited to those specifically listed in the appended patent application claims. If appropriate, it is also contemplated that claims drafted in one format or statutory type (e.g., apparatus) are intended to support corresponding claims in another format or statutory type (e.g., method). *** Since this disclosure is a legal document, various terms and phrases may be subject to administrative and judicial interpretations. The following paragraphs are hereby announced and the definitions provided throughout the disclosure will be used to determine how to interpret the patent application claims drafted based on this disclosure. Unless the context clearly dictates otherwise, a reference to the singular form of an item (i.e., a noun or noun phrase preceded by "a / an" or "the") is intended to mean "one or more". Thus, a reference to "an item" in a claim does not exclude additional instances of that item in the absence of an accompanying context. A "plurality" of items refers to a collection of two or more items. In this document, the word "may" is used herein with a permissive connotation (i.e., having the possibility to, being able to), and not with a mandatory connotation (i.e., must). The terms "comprising" and "including" and their forms are open-ended, meaning "including, but not limited to". When the term "or" is used in connection with a list of alternatives in this disclosure, it will generally be understood to be used in an inclusive sense, unless the context dictates otherwise. Thus, the statement "x or y" is equivalent to "x or y, or both", and thus: 1) covers x but not y; 2) covers y but not x; and 3) covers both x and y. On the other hand, a phrase such as "either x or y, but not both" clearly indicates that "or" is used in an exclusive sense. The statements "w, x, y, or z, or any combination thereof" or "at least one of... w, x, y, and z" are intended to cover all possibilities involving any number of elements, from a single element up to the total number of elements in the set. For example, given the set [w, x, y, z], these statements cover any single element of the set (e.g., w but not x, y, or z), any two elements (e.g., w and x but not y or z), any three elements (e.g., w, x, and y but not z), and all four elements. Thus, the phrase "at least one of... w, x, y, and z" refers to at least one element of the set [w, x, y, z], thereby covering all possible combinations in this list of elements. This phrase is not to be construed as requiring at least one instance of w, at least one instance of x, at least one instance of y, and at least one instance of z. In this disclosure, various "designations" may be placed before a noun or noun phrase. Unless the context dictates otherwise, different designations for a feature (e.g., "first circuit", "second circuit", "specific circuit", "given circuit", etc.) refer to different instances of the feature. Additionally, unless otherwise stated, the designations "first", "second", and "third", when applied to a feature, do not imply any type of order (e.g., spatial, temporal, logical, etc.). The phrase "based on" is used to describe one or more factors that affect a determination. This term does not exclude the possibility that additional factors may affect the determination. That is, a determination can be based solely on a particular factor, or based on that particular factor and other unspecified factors. Consider the phrase "determine A based on B". This phrase indicates that B is a factor used to determine A, or that B affects the determination of A. This phrase does not exclude the possibility that A can also be determined based on some other factor such as C. This phrase is also intended to encompass an embodiment in which A is determined solely based on B. As used herein, the phrase "based on" is synonymous with the phrase "based at least in part on". The phrase "in response to / response to" describes one or more factors that trigger an effect. This phrase does not exclude the possibility that additional factors may affect or otherwise trigger the effect, either in combination with the specified factors or independently of the specified factors. That is, an effect can be solely in response to those factors, or can be in response to the specified factors and other unspecified factors. Consider the phrase "perform A in response to B". This phrase specifies that B is the factor that triggers the performance of A or triggers a particular result of A. This phrase does not exclude the possibility that A can also be performed in response to some other factor such as C. This phrase also does not exclude the possibility that A can be performed in response to B and C in combination. This phrase is also intended to encompass an embodiment in which A is performed solely in response to B. As used herein, the phrase "responsive to" is synonymous with the phrase "responsive at least in part to". Similarly, the phrase "in response to" is synonymous with the phrase "at least in part in response to". *** In this disclosure, different entities (which may be variously referred to as "units", "circuits", other components, etc.) may be described or claimed as "configured" to perform one or more tasks or operations. This notation (an "entity" is configured to "perform one or more tasks") is used herein to refer to a structure (i.e., the physical thing of the entity). Specifically, this notation is used to indicate that the structure is arranged to perform the one or more tasks during operation. Even if a structure is not currently being operated, the structure can still be said to be "configured to" perform a certain task. Thus, an entity that is described or recited as "configured to" perform a certain task refers to a physical thing, such as a device, a circuit, a system having a processing unit, a memory storing program instructions executable to implement the task, etc. This phraseology is not used herein to refer to an intangible thing. In some cases, various units / circuits / components may be described herein as performing a set of tasks or operations. It should be understood that these entities are "configured to" perform those tasks / operations even if not specifically recited. The phrase "configured to" is not intended to mean "configurable to". For example, an unprogrammed FPGA will not be considered "configured to" perform a particular function. However, this unprogrammed FPGA may be "configurable to" perform the function. After appropriate programming, then, the FPGA can be claimed to be "configured to" perform the specific function. For the purposes of a U.S. patent application based on this disclosure, describing a structure in a claim as "configured to" perform one or more tasks is specifically intended not to invoke 35 U.S.C. § 112(f) to construe the claim element. If the applicant intends to invoke section 112(f) during the examination of a U.S. patent application based on this disclosure, the claim element will be stated using the phraseology "means for 'performing a function'". In this disclosure, different "circuits" may be described. These circuits or "circuitries" constitute hardware including various types of circuit elements, such as combinational logic, time-controlled storage devices (e.g., flip-flops, registers, latches, etc.), finite state machines, memories (e.g., random access memories, embedded dynamic random access memories), programmable logic arrays, etc. The circuitry may be custom-designed or taken from a standard library. In various embodiments, the circuitry may include digital components, analog components, or a combination of both as needed. Certain types of circuits are commonly referred to as "units" (e.g., decode units, arithmetic logic units (ALUs), functional units, memory management units (MMUs), etc.). Such units also refer to circuits or circuitries. Accordingly, the circuits / units / components disclosed and other elements depicted in the figures and disclosed herein include hardware elements such as those described in the foregoing paragraphs. In many instances, the internal configuration of the hardware elements within a particular circuit may be specified by describing the function of that circuit. For example, a particular "decode unit" may be described as performing the function of "processing an opcode of an instruction and routing that instruction to one or more of a plurality of functional units", which means that the decode unit is "configured to" perform this function. The description of this function is sufficient for those of ordinary skill in the art of computer technology to imply a set of feasible structures for the circuit. In various embodiments, as discussed in the foregoing paragraphs, circuits, units, and other components may be defined by the functions or operations for which they are configured to implement. This configuration and the ways in which such circuits / units / components relate to each other and interact form the microarchitecture definition of the hardware, which is ultimately fabricated in an integrated circuit or programmed into an FPGA to form a physical implementation of the microarchitecture definition. Thus, this microhierarchical definition is recognized by those of ordinary skill in the art as a structure from which many physical implementations may be derived, all of which fall within the broad structure described by this microhierarchical definition. That is, those of ordinary skill in the art provided with the microhierarchical definition according to the present disclosure may implement this structure by encoding a description of the circuits / units / components in a hardware description language (HDL), such as Verilog or VHDL, without undue experimentation and in the application of ordinary techniques. HDL descriptions are often expressed in a functionally presentable manner. However, for those of ordinary skill in the art, this HDL description is a way of transforming the structure of a circuit, unit, or component into the details of the next level of implementation. Such an HDL description may take the form of behavioral code (which generally is not synthesizable), register transfer language (RTL) code (which generally is synthesizable, as opposed to behavioral code), or structural code (e.g., a wiring对照表 specifying logic gates and their connectivity). Subsequently, the HDL description may be synthesized according to a library of components designed for a given integrated circuit manufacturing technology and may be modified for timing, power, and other reasons to produce a final design database, which is transferred to a fabrication plant to manufacture masks and ultimately produce the integrated circuit. Some hardware circuits or portions thereof may also be custom designed in a schematic editor and transferred to the integrated circuit design along with the synthesized circuit system. The integrated circuit may include transistors and other circuit components (e.g., passive components such as capacitors, resistors, inductors, etc.) and interconnects between the transistors and circuit components. Some embodiments may implement multiple integrated circuits, which are coupled together to implement the hardware circuit, and / or in some embodiments discrete components may be used. Alternatively, the HDL design may be synthesized into a programmable logic array, such as a field programmable gate array (FPGA), and implemented in the FPGA. This decoupling between the design of this group of circuits and the subsequent lower-level implementation of these circuits typically results in a situation where the circuit or logic designer never specifies a particular set of structures beyond the description of what the circuit is configured to do for the lower-level implementation when this process is performed at a different stage of the circuit implementation process. In fact, many different underlying combinations of circuit components can be used to implement a circuit of the same specification, resulting in a large number of equivalent structures for that circuit. As mentioned, these underlying circuit implementations can vary according to changes in manufacturing technology, the foundry selected to manufacture the integrated circuit, the component library provided for a particular project, etc. In many cases, the selection by different design tools or methodologies to produce these different implementations can be arbitrary. In addition, for a single implementation of a particular functional specification of a circuit, it is common, for a given embodiment, to include a large number of devices (e.g., millions of transistors). Accordingly, the sheer volume of this information makes it impractical to provide a complete statement of the underlying structure for implementing a single embodiment, let alone a large array of equivalent viable implementations. For this reason, the present disclosure describes circuit structures using functional shorthand commonly employed in the industry. Various embodiments for password key exchange for establishing a shared secret are contemplated based on the foregoing description, including but not limited to the embodiments listed below. 1. One or more non-transitory computer-readable media having program instructions stored therein that are executable by a first computing device belonging to a first group of devices to cause the first device to perform operations including: receiving a request to perform a key exchange to establish a shared secret with a second device belonging to a second group of devices; verifying a key authorization data structure issued by a key authorization authority, wherein the key authorization data structure includes a first public key of a first participant authorization authority authorized to identify members of the first group of devices and a second public key of a second participant authorization authority authorized to identify members of the second group of devices; and in response to successful verification, performing the requested exchange using a public key pair certified by the first participant authorization authority as belonging to a member of the first group of devices. 2. The computer-readable media of embodiment 1, wherein the operations further include: generating a participant identity key (PIK) pair associated with an identity of the first device; and sending a request to cause the first participant authorization authority to issue a certification identifying the PIK pair as associated with a member of the first group of devices. 3. The computer-readable media of embodiment 1, wherein the request includes account information of a user account associated with each of the first group of devices, and the account information can be used by the first participant authorization authority to determine that the first device is a member of the first group of devices. 4. The computer-readable media of embodiment 2, wherein the generating includes: using previously stored key data trusted by the first participant authorization authority and usable by the first participant authorization authority to derive the PIK pair to establish that the first device is a member of the first group of devices. 5. The computer-readable media of embodiment 2, wherein performing the requested exchange includes: generating a temporary first participant exchange key (PEK) pair certified by the PIK pair; exchanging the public key of the first PEK pair and the public key of a second PEK pair generated by the second device with the second device; and deriving the shared secret by performing elliptic curve Diffie-Hellman (ECDH) using a private key of the first PEK pair and the exchanged public key of the second PEK pair. 6. The computer-readable media of embodiment 1, wherein the operations further include: receiving a revocation request to revoke the membership of the first device in the first group of devices; in response to the revocation request: deleting the public key pair certified by the first participant authorization authority; and sending a request to remove the first device from the first group of devices to the first participant authorization authority.7. The computer-readable medium as in Embodiment 1, wherein the operations further include: receiving a revocation request to revoke the membership of another device in the first device group; in response to the revocation request: sending a request to the first participant authorization unit to replace the first public key of the first participant authorization unit with another public key; and sending a request to the first participant authorization unit to authenticate another public key pair using a private key corresponding to the another public key. 8. The computer-readable medium as in Embodiment 1, wherein the operations further include: receiving a disaster recovery (DR) key pair authenticated by the key authorization unit; in response to determining that it is necessary to revoke the key authorization unit: signing a request using a private key of the DR key pair to prevent the members of the first device group and the second device group from continuing to use the key authorization data structure; and signing an authentication of another key authorization unit for authorizing key exchange between the first device group and the second device group using the private key of the DR key pair. 9. The computer-readable medium as in Embodiment 1, wherein the operations further include: exchanging a symmetric data encrypted using the established shared secret with the second device. 10. The computer-readable medium as in Embodiment 1, wherein the operations further include: providing a user authentication credential encrypted using the established shared secret to the second device. 11. A non-transitory computer-readable medium having program instructions stored therein, the program instructions executable by an operating system implementing a first participant authorization unit to cause the operating system to perform operations including: receiving a request from a first device to cause the first participant authorization unit to issue a signed authentication indicating that a public key of the first device belongs to a member of a first device group authorized to participate in a key exchange with members of a second device group; determining whether the first device is a member of the first device group including verifying a key authorization data structure issued by a key authorization unit, wherein the key authorization data structure includes a first public key of the first participant authorization unit authorized to identify members of the first device group and a second public key of a second participant authorization unit authorized to identify members of the second device group; and providing the authentication signed by a first private key corresponding to the first public key of the first participant authorization unit to the first device based on the determination. 12. The computer-readable medium as in Embodiment 11, wherein the operations further include: receiving a request to remove a second device from a given device group from the second device, the membership of which in the given device group is authenticated by the first participant authorization unit; and in response to the request, removing the second device from the given device group.13. The computer-readable medium as in Embodiment 11, wherein the request includes account information of a user account associated with each of the first device groups. 14. The computer-readable medium as in Embodiment 11, wherein the operations further comprise: receiving a revocation request to revoke the membership of the first device in the first device group; in response to the revocation request: replacing the first public key and the first private key with another public key pair; requesting from the key authorization unit another key authorization data structure including a public key of the another public key pair; and providing an indication that the signed authentication of the first device has been revoked to another member of the first device group. 15. The computer-readable medium as in Embodiment 14, wherein the operations further comprise: receiving a request from another device in the first device group to authenticate a public key pair of the another device; and providing another participant authentication authenticated by a private key of the another public key pair to the another device. 16. A non-transitory computer-readable medium having program instructions stored therein, the program instructions executable by an operating system implementing a key authorization unit to cause the operating system to perform operations including: receiving a request to cause the key authorization unit to authorize key exchange between a first device group and a second device group; signing, by the key authorization unit, a key authorization data structure including a first public key of a first participant authorization unit authorized to identify members of the first device group and a second public key of a second participant authorization unit authorized to identify members of the second device group; and providing the signed key authorization data structure to the first participant authorization unit and the second participant authorization unit to authorize key exchange between members of the first device group and members of the second device group. 17. The non-transitory computer-readable medium as in Embodiment 16, wherein the key authorization data structure further includes key exchange information indicating a specific usage policy of the devices participating in the key exchange. 18. The non-transitory computer-readable medium as in Embodiment 17, wherein the usage policy specifies that members of the first device group are allowed to send but not receive data objects from members of the second device group. 19. The non-transitory computer-readable medium as in Embodiment 16, wherein the operations further comprise: generating, by the key authorization unit, a disaster recovery (DR) key pair; signing a DR authentication data structure including a public key of the DR key pair; and sending, by the key authorization unit, the signed DR authentication data structure and a private key of the DR key pair to a given member of a given device group to grant the given member the ability to revoke the key authorization unit.20. The non-transitory computer-readable medium of claim 16, wherein the operations further comprise: generating, by the key authorization entity, a second key authorization data structure that authorizes key exchange to be performed among members of the first device group, members of the second device group, and members of the third device group whose members are identified by a third participant authorization entity; and providing the second key authorization data structure to the first participant authorization entity, the second participant authorization entity, and the third participant authorization entity. 10: Key exchange system; System 100: Device 100A: Computing device; Device 100A1: Device 100A2: Device 100B: Device 102: Processor 104: Memory 110: Application 110A: Device 110B: Device 112: Sensitive data object; Data object; Object 114: Request 120: Cryptographic circuit; Circuit; Security circuit 122: Key exchange; Exchange 130: Secure memory; Memory 132: Private key data; Key data 134: Shared secret 200: Authorization hierarchy; Hierarchy 210, 210A, 210B: Key authorization authority (KA) 212: KAK pair 212A: Private key of key authorization authority (KAK); KAK pair 212B: Public key; Public KAK 212B1, 212B2: Public KAK 214: Key authorization; Authentication 220, 220A, 220B: Participant authorization authority (PA) 222: PAK pair 222A, 222A1: Private PAK 222B: Public participant authorization authority key (PAK) 222B1, 222B2: Public key; Public PAK 224: Participant authentication; Authentication 230, 230A, 230B: Device group; Group 232: Participant identity key (PIK) pair 232A: Private PIK 232B: Public PIK 234: Participant exchange key (PEK); Participant exchange key (PEK) pair 234A: Private PEK 234B: Public PEK 300: Key exchange communication; Key exchange; Communication 302 - 326: Steps 400, 400A, 400B: Participant revocation; Revocation 401: Request 402: Revocation request 411: Request 412: Revocation request 450: Key authorization authority revocation; Revocation 460: Disaster recovery (DR) authentication 462: DR key pair 462A: Private DR key 462B: Public DR key 465: Request 470: Key authorization authority authentication 500: Secure enclave processor (SEP) 502: Interconnect 510: Filter 520: Secure mailbox mechanism; Secure mailbox; Mailbox mechanism; Mailbox 530: SEP processor; Processor 540: Secure ROM; ROM 542: Manager 560: Biosensor pipeline; Pipeline 562: Biometric data 570: Interconnect 610: Sorter; Sequence 620: Public key accelerator intellectual property (PKA IP); PKA; IP 630: PKA ROM; ROM 632: Immutable program instructions;Program instruction 640: RAM 650: Fuse 652: Unique identifier (UID) 660: Random number generator (RNG) IP 670: Hash IP 680: Interconnect 700: Method 705, 710: Steps 800: Method 805 - 815: Steps 830: Method 835 - 845: Steps 860: Method 865 - 875: Steps 900: Device 910: Mesh architecture 920: Computing complex 925: Bus interface unit (BIU) 930: Cache memory 935, 940: Core 945: Cache memory / memory controller; Controller 950: Input / output (I / O) bridge 965: Display unit 975: Graphics unit 1000: System or device 1010: Desktop computer 1020: Laptop computer 1030: Tablet computer 1040: Cellular or mobile phone 1050: Television 1060: Wearable device 1070: Cloud - based service 1080: Device 1090: Vehicle 1110: Media 1115: Design information 1120: Semiconductor manufacturing system 1130: Integrated circuit 1140: Computing system 1150: Lower - level design information 1160: Hardware circuit; Simulation model; Model; [FIG. 1] is a block diagram illustrating an example of a computing system configured to implement secure key exchange. [FIG. 2] is a block diagram illustrating an example of an authorization hierarchy for authorizing secure key exchange. [FIGS. 3A] and [FIG. 3B] are communication diagrams illustrating examples of messages communicated and actions performed during key exchange. [FIGS. 4A] to [FIG. 4C] are block diagrams illustrating examples of revocation associated with components of the authorization hierarchy. [FIG. 5] is a block diagram illustrating an example of an enclave processor including a cryptographic circuit system configured to perform secure key exchange. [FIG. 6] is a block diagram illustrating an example of a cryptographic circuit system including a secure memory for storing private key material. [FIG. 7] is a flowchart illustrating an example of a method performed by a device participating in secure key exchange. [FIGS. 8A] to [FIG. 8C] are flowcharts illustrating additional examples of methods for facilitating secure key exchange. [FIG. 9] is a block diagram illustrating an example computing device for implementing the disclosed technology. [FIG. 10] is a diagram illustrating an example application of a system and device employing the disclosed technology. [FIG. 11] is a block diagram illustrating an example computer - readable medium storing circuit design information for implementing a device employing the disclosed technology. 10: Key exchange system; System 100A: Computing device 100B: Device 102: Processor 104: Memory 110: Application 112: Sensitive data object; Encrypted data object; Object 114: Request 120: Cryptographic circuit; Circuit 122: Key exchange; Exchange 130: Secure memory; Memory 132: Private key data 134: Shared secret

Claims

1. A computing device comprising: a processor; memory accessible by the processor, the memory having program instructions stored therein, the program instructions being executable by the processor to: request a key exchange to establish a shared secret with another device; and a cryptographic circuit coupled to a secure memory inaccessible by the processor, wherein the cryptographic circuit is configured to: determine whether the key exchange is authorized by verifying a key authorization data structure signed by a key authorization authority external to the computing device, thereby instructing the computing device to be authorized to participate in the key exchange with the other device; and, in response to determining that the key exchange is authorized, execute the key exchange, the key exchange including deriving the shared secret using private key data stored in the secure memory.

2. The computing device of claim 1 further includes: a read-only memory (ROM) having immutable program instructions stored therein, which can be executed by the cryptographic circuit to perform the key exchange.

3. The computing device of claim 1, wherein the cryptographic circuit is configured to: execute a sequence of program instructions in a specific order to perform the key exchange; and prevent out-of-order execution of the sequence by clearing a portion of the secure memory used by the next program instruction in the specific sequence in response to receiving a given program instruction in the sequence.

4. The computing device of claim 1, wherein the key authorization data structure includes a public key associated with the computing device and a public key associated with the other device.

5. The computing device of claim 4, wherein the key authorization data structure indicates an authorization for a key exchange between a first device group and a second device group; wherein the public key associated with the computing device belongs to a first participant authorized entity authorized to identify the computing device as a member of the first device group; and wherein the public key associated with the other device belongs to a second participant authorized entity authorized to identify the other device as a member of the second device group.

6. The computing device of claim 4, wherein program instructions are executable by the processor to: receive a disaster recovery (DR) key pair generated by the key authority in response to the publication of the key authority data structure; and establish another key authority using the DR key pair in response to the subsequent revocation of the key authority.

7. The computing device of claim 4, wherein the private key data includes a public key pair of a private key of a user authenticated to use one of the public keys in the key authorization data structure; and wherein, Exporting this shared secret includes: performing an elliptic curve Diffie-Hellman (ECDH) operation using the private key information.

8. The computing device of claim 1, wherein program instructions are executable by the processor to: exchange with the other device a symmetric key encrypted with the derived shared secret.

9. The computing device of claim 1, wherein program instructions are executable by the processor to: exchange with the other device an authentication credential encrypted with the derived shared secret.

10. The computing device of claim 1, wherein program instructions are executable by the processor to: exchange with the other device a transaction credential encrypted using the derived shared secret.

11. The computing device of claim 1, further comprising: a random number generator circuit coupled to the cryptographic circuit and inaccessible by the processor, wherein the random number generator circuit is configured to: provide a random value to the cryptographic circuit for storage in the secure memory as part of the private key data.

12. The computing device of claim 1, further comprising: a fuse library coupled to the cryptographic circuit and inaccessible by the processor, wherein the fuse library is configured during the manufacture of the cryptographic circuit to store key data that can be used by the cryptographic circuit to extract a portion of the private key data stored in the secure memory.

13. The computing device of claim 1, wherein the cryptographic circuit is a public key accelerator.

14. One or more non-transitory computer-readable media having program instructions stored therein, which are executable by a computing device to cause the computing device to perform operations including: requesting a key exchange by a processor of the computing device to establish a shared secret with another device; determining whether the key exchange is authorized by verifying a key authorization data structure signed by a key authorization authority outside the computing device, thereby instructing the computing device to be authorized to participate in the key exchange with the other device; and based on the determination, causing a cryptographic circuit of the computing device to perform the key exchange including deriving the shared secret using private key data stored in a secure memory, the secure memory being coupled to the cryptographic circuit and inaccessible by the processor.

15. Computer-readable media as in claim 14, wherein the computer-readable media includes: A read-only memory (ROM) contains program instructions stored therein, which can be executed by the cryptographic circuit to perform the key exchange.

16. The computer-readable media of request item 14, wherein such operations further include: determining whether the key exchange is authorized by verifying a plurality of authentications associated with the public key pair exchanged during the key exchange.

17. Computer-readable media as requested in item 16, wherein the plurality of authentications includes: A first key authentication that identifies a public key of the computing device as a member of a first device group; and a second key authentication that identifies a public key of the other device as a member of a second device group.

18. Computer-readable media as requested in item 17, wherein the plurality of authentications includes: A key authorization identifies: 1) the public key of the computing device as a first public key of a first participant authorization unit corresponding to a member of the first device group; and 2) the public key of the other device as a second public key of a second participant authorization unit corresponding to a member of the second device group.

19. The computer-readable media of request 18, wherein the key authorization further identifies flags restricting such operation of the computing device and the other device.

20. A non-transitory computer-readable storage medium having design information stored thereon, the design information specifying a design of at least a portion of a hardware physical circuit in a format recognizable by a semiconductor manufacturing system, the semiconductor manufacturing system being configured to use the design information to manufacture the physical circuit according to the design, wherein the design information specifies that the physical circuit includes: a processor; memory accessible by the processor, the memory having program instructions stored therein, the program instructions being executable by the processor to: request a key exchange to establish a shared secret with another device; and a cryptographic circuit coupled to a secure memory inaccessible by the processor, wherein the cryptographic circuit is configured to: determine whether the key exchange is authorized by verifying a key authorization data structure signed by a key authorization unit external to the physical circuit, to instruct the physical circuit to be authorized to participate in the key exchange with the other device; In response to the determination that the key exchange was authorized and performed, the key exchange included using private key data stored in the secure memory to derive the shared secret.

Images