Silicon key exchange

Abstract

Techniques related to cryptographic key exchange are disclosed. In some embodiments, a computing device includes cryptographic circuitry coupled to a secure memory that is not accessible by a processor of the computing device. Program instructions executing on a computing device may request to perform a key exchange to establish a shared secret with another device. The cryptographic circuitry is configured to perform a key exchange, including deriving a shared secret using a private key material maintained in the secure memory. In some embodiments, the key exchange includes verifying a key authorization data structure issued by a key authorization mechanism, the key authorization data structure including a first public key of a first participant authorization mechanism and a second public key of a second participant authorization mechanism. In response to successful verification, the exchange uses a public key pair that is certified by the first participant authorization as belonging to a member in the first group of devices.

Description

Technical Field

[0001] This disclosure relates generally to computer security, and more specifically to cryptographic key exchanges used to establish shared secrets. Background Technology

[0002] Devices such as smartphones, laptops, IoT devices, and servers frequently use internet communication to send sensitive data. For example, a device's password manager may share sensitive information such as passwords, encryption keys, and personal identification numbers (PINs). This sensitive data could be used by malicious parties for fraudulent purposes. For instance, malicious actors could eavesdrop on network communications and obtain credit card numbers being sent across the network. Malware may also attempt to access sensitive information stored on the device, for example, by compromising the operating system. To keep sensitive information private and secure to unauthorized parties, various cryptographic algorithms and protocols have been developed. Attached Figure Description

[0003] Figure 1 This is a block diagram illustrating an example of a computing system configured to implement secure key exchange.

[0004] Figure 2 This is a block diagram illustrating an example of an authorization hierarchy structure used for authorized secure key exchange.

[0005] Figure 3A and Figure 3B This is a communication diagram illustrating examples of the messages and actions communicated during key exchange.

[0006] Figures 4A to 4C This is a block diagram illustrating an example of revocation associated with a component in an authorization hierarchy.

[0007] Figure 5 This is a block diagram illustrating an example of a security zone processor that includes cryptographic circuitry configured to perform secure key exchange.

[0008] Figure 6 This is a block diagram illustrating an example of a cryptographic circuit that includes a secure memory for storing private key material.

[0009] Figure 7 This is a flowchart illustrating an example of a method performed by a device participating in a secure key exchange.

[0010] Figures 8A to 8C This is a flowchart illustrating an additional example of a method for facilitating secure key exchange.

[0011] Figure 9 This is a block diagram illustrating an example computing device used to implement the disclosed technology.

[0012] Figure 10 These are illustrations of example applications of systems and devices employing the disclosed technologies.

[0013] Figure 11 This is a block diagram illustrating an example computer-readable medium for storing circuit design information for implementing a device employing the disclosed technology. Detailed Implementation

[0014] The security of a cryptographic protocol typically depends on the security of the cryptographic material used in the protocol (e.g., the cryptographic key). Therefore, if the cryptographic material used in a particular cryptographic protocol is compromised, the protocol's security is lost. When a cryptographic protocol is implemented in software, the cryptographic material is usually maintained in memory accessible to the processor (e.g., RAM). In such cases, other (potentially malicious) software can gain 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, attackers can exploit vulnerabilities to escalate privileges and read the memory location where the private key material is stored, use side-channel attacks to obtain the private key material, and so on. Furthermore, software-implemented cryptographic protocols often store their instructions in memory, making them vulnerable to potential unauthorized modification.

[0015] The inventors have recognized that it is therefore desirable to maintain the private key material for key exchange in a secure memory inaccessible to the processor. As will be discussed in more detail below in some embodiments, an application executing on the processor of a computing device may request to perform a key exchange to establish a shared secret with another device. In response, the cryptographic circuitry of the computing device performs a key exchange using the shared secret derived from the private key material maintained in a secure memory inaccessible to the processor. In some embodiments, the instructions executed by the cryptographic circuitry may also be stored in a memory (e.g., ROM) inaccessible to the processor to prevent the instructions from being modified in some unauthorized manner. In some embodiments, this use of secure hardware can improve communication security by making it more difficult to compromise sensitive key material.

[0016] In some situations, device users may want to distribute sensitive information to more than one device, but control the devices authorized to access that information. For example, a device owner might want to share their passwords with other devices they own, while ensuring that previously owned devices do not receive any passwords. As will be discussed in some implementations below, an authorization hierarchy can be used to restrict which devices are authorized to participate in key exchanges for accessing sensitive data. Instead of having a single entity to authorize all devices, the hierarchy may include a key authorization authority that authorizes two or more groups of devices to exchange keys, but delegates identification of group membership to participant authorization authorities. When a device in one group later wants to participate in a key exchange with devices in another group, that device can determine whether such action is permissible by verifying a certificate issued by an authorization authority in the hierarchy.

[0017] Turn now Figure 1 A block diagram of a key exchange system 10 is depicted. In an illustrated embodiment, system 10 includes a computing device 100A, which 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 110, while secure memory 130 includes private key material 132 and a shared secret 134. System 10 also includes a device 100B. In some embodiments, system 10 may be implemented differently from what is shown—for example, computing devices 100A and 100B may include, as described below, relative to… Figures 5 to 6 One or more components under discussion.

[0018] In various implementations, application 110 is a set of program instructions stored in memory 104, which can be executed by processor 102 to store sensitive information and share sensitive information with device 100B, such as... Figure 1 Sensitive data object 112 is shown. For example, application 110 could be a password manager that stores passwords, an operating system that manages files, a digital car key application that maintains digital car keys, 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, parents might want to share digital car keys with their children using a car manufacturer's key management application.

[0019] However, in the illustrated implementation, application 110 is stored in memory 104, which is accessible by processor 102, and therefore its data may be more easily accessed in an unauthorized manner. If application 110 (or some other auxiliary application) wants to perform a key exchange with device 100B to establish a shared secret and uses memory 104 to store the key material for the exchange and the shared secret in memory 104, a malicious actor who has compromised device 100A may be able to read these shared secrets and / or materials—and thus decrypt the encrypted version of sensitive data object 112. A malicious actor may also attempt to modify the program instructions implementing the key exchange in order to compromise the integrity of key exchange 122.

[0020] As will be discussed, in some embodiments, instead of using memory 104 to store key data used for performing key exchange, hardware circuitry (e.g., cryptographic circuitry 120, secure memory 130) that cannot be accessed by processor 102 is used to protect the key data shown as... Figure 1 The private key material 132 and the key data of the shared secret 134 are stored in the cryptographic circuit 120. In an illustrated embodiment, application 110 may transmit a request 114 to cryptographic circuit 120 to perform a key exchange 122 with device 100B to establish the shared secret 134 between the two devices. Cryptographic circuit 120, coupled to secure memory 130 that cannot be accessed by processor 102, is then configured to perform key exchange 122, including deriving the shared secret 134 using the private key material 132 maintained in secure memory 130.

[0021] Cryptographic circuit 120 is a secure circuit configured to perform cryptographic operations (e.g., as...). Figure 5 As part of the Secure Area Processor (SEP) shown, these cryptographic operations include key generation and encryption and decryption using the keys, which may be stored in secure memory 130 (or stored externally in a protected manner). As used herein, the term "secure circuit" refers to circuitry that protects isolated internal resources from direct access by external circuitry such as processor 102. This internal resource may also be memory storing sensitive data such as personal information (e.g., biometric information, credit card information, etc.), encryption keys, random number generator seeds, etc. This internal resource may also be circuitry performing services / operations associated with sensitive data, such as encryption, decryption, digital signature generation and verification, etc. Cryptographic circuitry 120 may implement any suitable encryption algorithm, such as Data Encryption Standard (DES), Advanced Encryption Standard (AES), Rivest Shamir Adleman (RSA), Digital Signature Algorithm (DSA), etc. In some embodiments, circuitry 120 may further implement Elliptic Curve Cryptography (ECC).

[0022] In various implementations, secure memory 130 is circuitry configured to store data in a manner inaccessible to processor 102 0. Secure memory 130 may be local memory (e.g., internal memory) configured to store key data, which may include private key material 132, shared secret 134, encrypted data object 112, etc. In some implementations, secure memory 130 may be configured such that only cryptographic circuitry 120 can read and write data to secure memory 130. Therefore, while an application running on processor 102 may be able to request actions relative to data in secure memory 130 (e.g., key exchange 122), processor 102 may be unable to read or write data to secure memory 130. Thus, if processor 102 wants to execute compromised program instructions, processor 102 will be unable to read and write private key material 132 and shared secret 134 because memory 130 may lack, for example, a physical read and write interface to facilitate such actions by processor 102. In some implementations, the cryptographic circuit 120 may access other forms of storage devices, which may include other non-volatile storage devices, such as those described below relative to... Figure 6 The above is discussed. In some embodiments, these additional storage devices may also include a collection of fuses that are melted during manufacturing to record a portion of key material 132, such as a unique identifier (UID), which can be used to derive keys from private key material 132 or other key data. In some embodiments, to extend its available storage space, keys generated by cryptographic circuitry 120 may be stored externally to memory 130, but encrypted using one or more keys stored only in secure memory 130. This will be relative to... Figure 6 Exemplary components of the secure storage 130 will be discussed in more detail.

[0023] In various embodiments, cryptographic circuitry 120 is configured to receive from application 110 a request 114 to perform key exchange 122 to establish a shared secret 134 between devices 100A and 100B. In some embodiments, key exchange 122 includes an elliptic curve Diffie-Hellman (ECDH) exchange, in which circuitry 120 creates the shared secret 134 and stores it in secure memory 130. As part of this exchange, device 100 may initially generate a corresponding public key pair (hereinafter referred to as participant exchange keys) including a private key and a corresponding public key. Each device 100 may then share its own public key with the other device 100. Subsequently, each device 100 may use its private key and the other device's public key to perform Diffie-Hellman to derive the shared secret 134. In an illustrated embodiment, the private key material 132 of device 100 includes data for establishing the shared secret 134, such as device 100's private key, the received public key, and / or additional key material for deriving or proving these keys. For example, as will be discussed below with respect to Figure 3, the private key material 132 may also include identity keys for proving DH keys, which may further be temporary keys. After key exchange 122, circuitry 120 may use a shared secret 134 stored in secure memory 130 to further encrypt sensitive data object 112. Application 110 may then transmit the encrypted data object 112 (without accessing the shared secret 134). Device 100B may then use its derived shared secret 134 to decrypt the securely encrypted data object 112. In some embodiments, device 100B uses another instance of cryptographic circuitry 120 and secure memory 130 to implement key exchange 122 on its side; in other embodiments, device 100B may implement exchange 122 differently from device 100A.

[0024] In some implementations, a user may want to share sensitive data object 112 with different devices, but control the device authorized to participate in key exchange 122—and therefore authorized to receive object 112. For example, a user might want to share sensitive data between his or her devices, which may be different from each other (e.g., using different types of platforms, processor services, or manufacturers). For example, a credential manager user might want to transfer passwords from Apple... ® One or more devices among the devices associated with the account share with Google. ® Account-linked Android ® Devices, although each device is associated with a different platform. As will be discussed in some implementations below, an authorization hierarchy can be used to authorize and authenticate participating devices 100, such as Google. ® Android can be built and verified ®Ownership of the device, and Apple ® Apple can be set up and verified ® Ownership of the devices. Therefore, the group of devices authorized to participate in key exchange 122 can be verifiable to prevent unauthorized devices from obtaining sensitive data objects 112.

[0025] Turn now Figure 2 A block diagram illustrating an example of an authorization hierarchy structure 200 for authorization key exchange is depicted. In the illustrated embodiment, the authorization hierarchy structure 200 includes a key authorization authority 210, participant authorization authorities 220A and 220B, and devices 100A and 100B belonging to device groups 230A and 230B, respectively. In some embodiments, the authorization hierarchy structure 200 may be implemented differently—for example, the hierarchy structure 200 may include additional device groups, participant authorization authorities, key authorization authorities, etc.

[0026] In various implementations, device group 230 is a collection of devices 100 that can share one or more common attributes with each other. For example, devices 100 in a given group 230 could belong to a single user, a member of a household, employees working in the same office, devices sharing the same operating system, applications, underlying hardware, manufacturer, servers belonging to the same server cluster, etc. As noted above, users may expect to transfer sensitive data between devices in different groups without the participation of unauthorized devices in the exchange. For example, members of a household with multiple devices may expect to share sensitive objects 112, such as digital car keys, website passwords, etc. To ensure that unauthorized devices do not participate in key exchange to obtain sensitive data objects 112, the authorization hierarchy 200 provides a way to verify that device 100 is authorized to participate in key exchange 122.

[0027] In various implementations, a Key Authorization Authority (KA) 210 is a trusted computing system configured to authorize a specific participant group 230 by identifying a Participant Authorization Authority (PA) 220, which in turn identifies members of group 230. In an exemplary implementation, KA 210 grants authorization to PA 220 by generating a Key Authorization 214. In some implementations, KA 210 may initially receive requests for key exchange between devices in authorization group 230A and devices in group 230B, along with public keys 222B1 and 222B2 of the respective PAs 220A and 220B responsible for identifying group membership. For example, KA 210 may provide a web interface that allows trusted individuals to provide these Public Participant Authorization Authority (PAK) keys 222B—or delegate computing systems to act as PAs 220, with these PAs individually providing their PAK 222B. As shown in the figure, KA 210 can use a Private Key Authority (KAK) 212A to sign Key Authorization 214, which includes public PAK 222B1 of PA 220A and public PAK 222B2 of PA 220B. Then, the corresponding public key 212B of the private KAK 212A can be distributed to PA 220 and device 100 to verify the signature of Key Authorization 214. When signing multiple PAKs 222B together using the same Key Authorization 214, KA 210 not only grants PA 220 the authority to determine group membership but also binds their respective groups 230A and 230B together, preventing PA 220 from granting any other group the authority to participate in Key Exchange 122 between groups 230A and 230B. In some implementations, Key Authorization 214 may include more than two public PAKs 222B to enable more than two groups to participate in Key Exchange 122. For example, an IT administrator in a company with three offices might want to enable three site administrators to identify servers that are permitted to communicate with each other, and have KA 210 issue a single key authorization 214 for PA 220 located at each site. However, in another implementation, multiple key authorizations 214 can be issued to enable key exchange 122 between the three sites. It should be noted that in other implementations, KA 210 directly authorizes individual devices (e.g., devices 110A and 110B) instead of using participant permissions. In this case, the authorized individual device will be its own participant authority, while other devices can still verify via KA 210 whether the device is authorized to perform key exchange 122.

[0028] In some implementations, key authorization 214 may include additional information describing the exchange between participant permissions 220. This information may restrict the operations that each device 100 can perform relative to the transmitted data object 112, thus implementing usage policies for these devices. For example, key authorization 214 may include flags specifying that a device 100 registered by participant authorization authority 220A is permitted to transmit only a specific data object 112 but not receive data objects 112 from a device 100 registered by participant authorization authority 220B, while a device 100B registered by participant authorization authority 220B may receive data objects 112 only from a device 100A registered by authorization authority 220A. The integrity of these flags is preserved through the signature of key authorization 214. Therefore, cryptographic circuit 120 can protect the specified usage policy from tampering by verifying key authorization 214 (e.g., using public KAK 212B) and stop key exchange 122 in the event of verification failure.

[0029] In various implementations, PA 220 is a trusted computing system configured to establish and maintain membership in a specific group 230. In an exemplary implementation, PA 220 identifies device 100's membership in a specific group by generating a participant certificate 224. To generate the certificate 224, device 100 may initially generate (e.g., using cryptographic circuitry 120) a participant identity key (PIK) pair 232 to be associated with device 100's identity. Device 100 may then transmit a registration request to participant authorization authority 220 to issue the certificate 224 identifying device 100 as a member of device group 230. In some implementations, the request includes account information of a user account associated with each device in group 230 and usable by PA 220 to determine that device 100 should be a member of device group 230. In some implementations, previously stored key material 132 (e.g., as per [reference to key information]) is used. Figure 6 The unique identifier (UID) discussed is used to derive the PIK pair 232. This previously stored key material is trusted by PA 220 and can be used by PA 220 to authenticate device 100. Continuing with the password sharing example mentioned above, KA 210 can be a server associated with a cross-platform password manager, which is configured to support two separate platforms (such as Android). ® and Apple ® The device is used by the user. Then, KA 210 can issue a key authorization 214 to the user's account, which grants PA 220A and 220B associated with these platforms the ability to identify the user's iCloud account. ® The account is associated with device 100A, group 230A, and the user's Google. ®The permissions of device 100B associated with the account in group 230B. After determining that device 100 should be a member of group 230, PA 220 can then provide participant certificate 224, which includes device 100's public PIK 232B and is signed by private PAK 222A. The certificate 224 can then be verified by verifying the signature of the certificate 224 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.

[0030] As will be discussed next Figures 3A to 3B The two devices 100A and 100B in the different groups 230A and 230B discussed can then participate in key exchange 122, whereby they can use the previously obtained key authorization 214 and its corresponding participant proof 224 to confirm that a member of group 230 is authorized to participate in key exchange 122. The exchange 122 may also include exchanging these participant exchange keys (PEKs) proved by the private PIK 232A of the participant exchange key (PEK) 234.

[0031] Turn now Figure 3A A communication diagram is depicted for key exchange communication 300 used to implement key exchange 122. In the illustrated embodiment, key exchange 300 includes the steps of both key exchange 122 and the transmission of data object 112. In some embodiments, key exchange 300 may be implemented differently from that shown—for example, steps may be performed in a different order, steps may be performed concurrently, or steps may be omitted; key exchange 300 may include more steps than shown; etc. In various embodiments, security circuitry 120 implements various steps among those discussed with respect to communication 300.

[0032] As shown in the figure, key exchange 300 begins at step 302, in which device 100A verifies key authorization 214 and participant proof 224 from participant authorization authority 220A to confirm that the device has been authorized to participate in exchange 122. Therefore, device 100A can use a stored copy of public KAK 212B to initially verify key authorization 214 (and thus public PAKs 222B1 and 222B2) to verify the signature in authorization 214. Device 100A can then use a stored copy of public PAK 222B1 to verify its participant proof 224 to confirm its membership in group 230A associated with PA 220A. At 304, security circuitry 120 in device 100A loads sensitive data object 112 from application 110 to share it with device 100B.

[0033] Key exchange 300 continues in step 306 (which can be performed in parallel with steps 302-304), where device 100B verifies key authorization 214 and participant credentials 224 from participant authorization authority 220B. Similar to step 302, device 100B may verify its participant credentials 224 and key authorization 214 to confirm that device 100B is registered in group 230B and authorized to perform key exchange 122.

[0034] At step 308, device 100B generates and proves a temporary participant exchange key (PEK) pair 234. In various embodiments, device 100B proves the pair 234 by signing the public key of the pair 234 using its private PIK 232A, which is proved by its participant proof 224. At step 310, device 100B transmits its proved public PEK 234B and its participant proof 224 including its public PIK 232B to device 100A.

[0035] At step 312, device 100A verifies key authorization 214 and participant proof 224 of device 100B. Therefore, device 100A can use the public PAK 222B2 of PA 220B, which includes key authorization 214 (already verified in step 302), to verify the participant proof 224 of device 100B (and thus verify the public PIK 232B of device 100B) to confirm device 100B's membership in group 230B. Device 100A can then use the public PIK 232B of device 100B, which is included in its participant proof 224, to further verify the signature of the public PEK 234B of device 100B's proof.

[0036] At step 314, in response to successful verification, device 100A generates its own PEK pair 234 and proves the PEK pair by signing the public PEK 234B with its private PEK 232A, which is proved by its participant proof 224. At step 316, device 100A then derives the shared secret 134 by performing an elliptic curve Diffie-Hellman (ECDH) operation using its private PEK 234A and device 100B's public PEK 234B (verified in step 312). Then, at step 318, device 100A can use the shared secret 134 to encrypt sensitive data object 112.

[0037] Key exchange communication 300 continues Figure 3B The figure depicts the remainder of communication 300, in which, at step 320, device 100A transmits its participant proof 224, including public PIK 232B, its public PEK 234B (provided using private PIK 232A), and encrypted data object 112.

[0038] At step 322, device 100B verifies key authorization 214 and participant proof 224 of device 100A, including verifying participant proof 224 of device 100A and the signed public PEK 234B, similar to step 312. In response to this successful verification, device 100B performs EDCH at step 324 to derive the same shared secret 134 using device 100B's private PEK 234A and device 100A's public PEK 234B. Finally, at step 326, device 100B uses the derived shared secret 134 to decrypt the encrypted data object 112.

[0039] As already discussed, key exchange 300 relies on multiple proofs 214 and 224. If any break occurs in the proof chain (e.g., signature verification fails relative to one of proofs 214 or 224), device 100 may suspend the execution of key exchange 300 (and thus suspend the exchange of sensitive data object 112). Figures 4A to 4C The discussion may involve instances where the ability to revoke the participation of a given device 100, PA 220, or KA 210 in the authorization hierarchy 200 is desired. Various revocation procedures will now be discussed.

[0040] Turn now Figure 4A The diagram illustrates the participant revocation 400A. In some cases, the owner of device 100 may have control of device 100 but wish to cease using it, as if the owner had sold or gifted device 100 to someone else. While the owner still owns device 100, the owner can initiate participant revocation 400A to prevent the next user of device 100 from using it to obtain data object 112 belonging to the original owner.

[0041] As shown in the figure, participant revocation 400 may begin when device 100 receives 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 remotely generated by a user or administrator interacting with a server, which then forwards request 401 to device 100A. In response to receiving request 401, device 100 then deletes its private PIK pair 232, thereby preventing it from proving any PEK pair 234 that can be generated in any subsequent key exchange 122. Device 100 may also transmit a revocation request 402 that notifies PA 220 of the revocation, such that PA 220 will not issue any new participant proof 224 for any subsequently generated PIK pair 232.

[0042] In other cases, the device may be unavailable to participants involved in revoking 400A, and therefore an alternative revocation procedure may be used, such as the following relative to... Figure 4B As described.

[0043] Turn now Figure 4B The diagram illustrates the process of a participant revoking 400B. In some instances, if, for example, device 100A1 is offline, stolen, or lost, device 100A1 may be unable to participate in the revocation process. Therefore, another device 100A2, which may be a member of the same group 230, can be used to revoke the membership of device 100A1 via the execution of revocation 400B.

[0044] As shown in the figure, revocation 400B can begin when device 100A2 receives a request 411 to revoke the membership of device 100A1 (e.g., the device may have been lost). In response to request 411, device 100A2 transmits a revocation request 412 to its participant authorization authority 220, thereby notifying it of the expectation to revoke device 100A1. Since the lost device 100A1 may still possess a PIK pair 232 with the corresponding participant proof 224, it may make sense to revoke all devices 100 in a given group and re-register the devices 100 that are still members. To achieve this, PA 220 may replace its old PAK pair 222 (including the old private PAK 222A1) with a new PAK pair 222 (including the new private PAK 222A1) and request KA 210 to issue a new key authorization 214 including the new public PAK 222B1. In some implementations, device 100A2 sends another registration request 413 to participant authorization authority 220A to certify device 100A2's new PIK pair 232. PA 220 can then send a new participant certification 224 including the new public PIK 232B. PA 220 can then repeat the process for other valid devices 100 that are still members of group 230. After revocation 400B is executed, the lost device 100A1 no longer has a PIK pair 232 that can be verified using the newly issued key authorization 214—thus preventing the device from participating in key exchanges 122 with any other member.

[0045] Although not shown, a process similar to revocation 400B can be performed to revoke a given PA 220, in which KA 210 can be contacted to replace the given key authorization 214 with a new key authorization 214 having a new public PAK 222B1 associated with the new PA 220 and a public PAK 222B2 associated with the other remaining PAs 220B.

[0046] Turn now Figure 4CA block diagram depicts the revocation of key authorization authority 450. In some instances, it may also be desirable to revoke a specific KA 210—although this may not occur frequently. For example, a server implementing a given KA 210A might lose its private KAK 212A, be compromised, or suffer from a problem preventing it from signing additional key authorization 214. In the illustrated implementation, revocation 450 provides a way not only to revoke the previous KA 210A but also to register a new KA 210B.

[0047] In some implementations, revocation 450 may begin before any determination of revocation of a given KA 210 (such as when the authorization hierarchy 200 is initially established). As shown, key authorization authority 210A may initially sign DR proof 460 for disaster recovery (DR) key pair 462 to enable its future revocation if such an event becomes necessary. In some implementations, KA 210A may generate DR key pair 462 and share it with device 100; in other implementations, device 100 generates pair 462 and provides a public DR key 462B to be included in DR proof 460.

[0048] If the revocation of KA 210A becomes necessary, device 100 can use DR key pair 462 and DR proof 460 to establish another key authority 210B. As shown, device 100 can delete the old public KAK 212B1 (and any key material whose proof chain depends on the old KAK pair 212A) and send a request 465 to the new key authority 210B requesting its registration in the hierarchical structure 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 can use private DR key 462A to sign a new key authority proof 470 including the new public KAK 212B2. In some embodiments, device 100 can also use private DR key 462A to sign a request (not shown) for other members of groups 230A and 230B to stop using the revoked key authorization 214 of the old KA 210A. Once the new KA 210B has received the Key Authorization Authority (KAA) certificate 470, it can proceed to generate Key Authorization 214 as part of the new hierarchy 200 that replaces the old hierarchy. Although depicted as being performed by device 100, another device with access to the private DR key 462A can use the new KAA certificate 470. For example, the owner of device 100A can share the DR key 462A with another device (e.g., a key from device 100A via key exchange 122), which allows the owner to register both device 100A and the other device in the new hierarchy 200.

[0049] Turn now Figure 5A block diagram of a secure area processor (SEP) 500 is depicted. In an illustrated embodiment, the SEP 500 includes a filter 510, a secure mailbox mechanism 520, a processor 530, a secure ROM 540, cryptographic circuitry 120, secure memory 130, and a biosensor pipeline 560, all coupled together via an interconnect 570. In some embodiments, the SEP 500 may include, compared to Figure 5 More (or fewer) components are shown. In various embodiments, SEP 500 is a tamper-proof security circuit. In an illustrated embodiment, SEP 500 achieves tamper-proofness by using filter 510 and security mailbox 520.

[0050] Filter 510 is circuitry configured to tightly control access to SEP 500 to increase the isolation of SEP 500 relative to the rest of device 100 and thus improve the overall security of device 100. More specifically, in some embodiments, filter 510 may only allow read / write operations from processor 102 (or, in some embodiments, other coupled peripherals coupled to interconnect 502) to address secure mailbox 520. Other operations must not proceed from interconnect 502 into SEP 500. Even more specifically, filter 510 may allow write operations to addresses assigned to the inbox portion of secure mailbox 520 and read operations to addresses assigned to the outbox portion of secure mailbox 520. Filter 510 may prevent / filter all other read / write operations. In some embodiments, filter 510 may respond to other read / write operations using errors. In one implementation, filter 510 may sink write data associated with a filtered write operation without passing that write data to local interconnect 570. In one implementation, filter 510 may provide random number data as read data for a filtered read operation. Random number data (e.g., “useless data”) may typically be data not associated with an addressed resource within SEP 500. Filter 510 may supply any data as random number data (e.g., all zeros, all ones, random data from a random number generator, data programmed into filter 510 to respond as read data, the address of a read transaction, etc.). Thus, filter 510 may prevent direct access by external entities such as processor 102 to internal components 530-570. In various implementations, filter 510 may filter only incoming read / write operations. Thus, components of SEP 500 may have full access to other components of computing device 100. Thus, filter 510 may not filter responses from interconnect 502 provided in response to read / write operations issued by SEP 500.

[0051] In some implementations, the secure mailbox 520 is a circuit that includes an inbox and an outbox. Both the inbox and the outbox can be first-in, first-out (FIFO) buffers for data. The buffers can have 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 interconnect 502. The outbox can store write data from write operations originating from processor 530. (As used herein, "mailbox mechanism" refers to a memory circuit that temporarily stores 1) the inputs of a secure circuit until they can be retrieved by that circuit and / or 2) the outputs of a secure circuit until they can be retrieved by external circuitry.) In some implementations, software executing on processor 102 (such as application 110) (or other peripheral devices coupled to interconnect 502) can request services from SEP 500 via an application programming interface (API) supported by the operating system of device 100—that is, the requester can make API calls to request services from SEP 500. These calls can cause the corresponding request to be written to mailbox authority 520, which is then retrieved from mailbox 520 and analyzed by processor 530 to determine whether it should provide services for the request. Thus, the API can be used to transmit, for example, key exchange requests 114, key material 132 received from another device 100 participating in key exchange 122, sensitive data objects 112 for encryption or decryption, biometric data, etc., via mailbox 520. By isolating SEP 500 in this way, the integrity of SEP 500 can be enhanced—including preventing, for example, malicious processes running on processor 102 from extracting private key material 132, sharing secrets 134, biometric data, etc.

[0052] SEP processor 530 is configured to process commands received from various resources in computing device 100 and can implement these commands using various secure peripheral devices. Processor 530 can then execute instructions stored in ROM 540 (or elsewhere, such as memory 104), such as manager 542, which can use components of SEP 500 to facilitate the execution of the various actions described above with respect to key exchange 122. For example, in response to receiving a request 114 to perform key exchange 122, SEP processor 530 can execute manager 542 to provide appropriate commands for notifying cryptographic circuitry 120 of the received request 114. Manager 542 can also interact with other components of SEP 500, such as biosensor pipeline 560, which can facilitate key exchange 122 if, for example, key exchange 122 (or the use of key material 132 or shared secret 134) presupposes successful biometric authentication of a user of device 100.

[0053] Secure ROM 540 is a memory configured to store program instructions for booting SEP 500. In some embodiments, ROM 540 may respond only to a specific address range assigned to Secure ROM 540 on local interconnect 570. The address range may be hardwired, and processor 530 may be hardwired to fetch from that address range at boot time to boot from Secure ROM 540. Filter 510 may filter addresses within the address range (as mentioned above) assigned to Secure ROM 540, thereby preventing access to Secure ROM 540 from components outside SEP 500. In some embodiments, Secure ROM 540 may include additional software executed by SEP processor 530 during use. This software may include program instructions for manager 542 to perform key exchange 122, process inbox messages, and generate outbox messages, etc. In some embodiments, the program instructions executed by SEP processor 530 are signed by a trusted licensing authority (e.g., the manufacturer of device 100) to ensure their integrity. These program instructions may include those stored in the secure ROM 540 and those stored externally (such as in memory 104); however, the externally stored program instructions may have their signatures verified by the program instructions in the ROM 540 before being allowed to be executed by the processor 530.

[0054] In various embodiments, the biosensor pipeline 560 is circuitry configured to authenticate a user by comparing biometric data captured from an authenticated user by a biosensor of device 100 with biometric data 562 of an authorized user that can be stored in memory 104 or elsewhere. As used herein, “biometric data” refers to data that uniquely identifies a user among others (at least with high accuracy) based on the user’s physical or behavioral characteristics. In some embodiments, the biosensor is a camera configured to collect facial data of a user’s face (or eyes) to perform facial recognition (or iris recognition). In other embodiments, the biosensor may be configured to collect other forms of biometric data, such as voice recognition data, fingerprint data, vascular data, etc. In some embodiments, pipeline 560 may use an ensemble of neural networks included in pipeline 560 to perform the comparison, each network being configured to compare biometric data captured in a single frame with multi-frame biometric data captured in multiple frames for an authorized user. As shown, pipeline 560 can be configured to read biometric data 562 from memory 104. This biometric data may be protected by encryption in some embodiments and / or stored in an associated portion of memory 104 accessible only by SEP 500. (In another embodiment, SEP 500 may internally store the biometric data 562.) Based on a comparison of the biometric data 562, pipeline 560 can provide an authentication result / confirmation indicating whether authentication was successful or failed. In some embodiments, this authentication result / confirmation can be used to determine whether the use of private key material and / or sharing of secret 134 is permitted.

[0055] The various components of SEP 500 facilitate the implementation of key exchange 122 by cryptographic circuit 120 and help improve the security of circuit 120.

[0056] Turn now Figure 6 A block diagram depicts the components within cryptographic circuit 120. As shown, cryptographic circuit 120 may include a sequencer 610, a public key accelerator (PKA) intellectual property (IP) 620, a PKA ROM 630, RAM 640, a fuse 650, a random number generator (RNG) IP 660, and a hash IP 670, all connected via interconnect 680. In the illustrated embodiment, secure memory 130 includes ROM 630, RAM 640, and fuse 650. In other embodiments, circuit 120 may be implemented differently and include more (or fewer) components—for example, RNG IP 660 and hash IP 670 may be external to circuit 120 but included in SEP 500, and secure memory 130 may not include fuse 550, etc.

[0057] The sequencer 610 is a circuit configured to decode commands received from the SEP processor 530 and generate a series of subcommand / program instructions for the PKAIP 620 (or other components in the cryptographic circuitry 120) to implement these commands. For example, these commands may include commands for performing actions such as generating key pairs for private key material 132, encrypting or decrypting data using the key pairs, signing data, verifying data, implementing ECDH, etc. They may also include commands for generating random numbers and hash values ​​for RNG IP 660 and hash IP 670. In an illustrated embodiment, the sequencer 610 accesses the PKAROM 630 to retrieve subcommands for provision to components in the cryptographic circuitry 120. In some embodiments, the sequencer 610 may use logic and / or program instructions stored in the ROM 630 to decode the received commands and issue corresponding subcommands.

[0058] PKA IP 620 is circuitry configured to perform various public-key cryptographic operations (such as those noted above) relative to private key material 132 to implement key exchange 122. Therefore, 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, IP 620 may support other cryptographic algorithms, such as those noted above. In some implementations, PKA IP 620 may be the only circuitry capable of accessing private key material 132 in secure memory 130. PKA IP 620 may also interact with other components in cryptographic circuitry 120, such as RNG IP 660 and hash IP 670, to perform various actions, such as key and signature generation, signature verification, etc.

[0059] PKA ROM 630 is a ROM configured to store immutable program instructions 632 that can be executed by components of cryptographic circuitry 120 to perform various operations described herein with respect to circuitry 120, including the execution of key exchange 122. In various embodiments, these instructions are stored in ROM 630 during manufacturing—and are therefore known to be trustworthy. During manufacturing, ROM 630 may also utilize static data provisioning used by circuitry 120. As noted above, by storing the program instructions 632 and data in ROM 630 to make them immutable, the security of cryptographic circuitry 120 (and therefore key exchange 122) is enhanced.

[0060] RAM 640 is a RAM configured to store various intermediate results generated by PKA IP 620 during operation. In the illustrated embodiment, these results include private PIK 232A and private PEK 234A—or other components of private key material 132. RAM 640 may also include shared secret 134, key material received from device 100B, key authorization 214, participant authentication 224, etc. To further enhance security, cryptographic circuitry 120 can execute a sequence of program instructions in a specific order to perform key exchange, and prevents out-of-order execution of the sequence by clearing portions of secure memory between executed instructions, so as to prevent out-of-order instructions from affecting subsequently executed instructions. For example, in response to receiving a given program instruction in the sequence, zero (or some other default value) can be written to a portion of secure memory used by the next program instruction in the specific order.

[0061] Fuse 650 is a fuse library configured to store key material that can be used by cryptographic circuitry 120 to derive a portion of private key material 132 used in key exchange 122. In an illustrated embodiment, the key material includes a unique identifier (UID) 652 that uniquely identifies device 100A from other devices. The key material may also include a unique generation identifier (GID), etc. These values ​​can be recorded during the manufacture of device 100A by burning various fuses in fuse 650. In various embodiments, fuse 650 cannot be accessed by components outside cryptographic circuitry 120 (or outside SEP500), such as processor 102.

[0062] RNG IP 660 is a circuit configured to generate random numbers for use by various components in cryptographic circuitry 120. Therefore, RNG IP 660 can provide random values ​​to PKA IP 620 for storage in RAM 640 as part of private key material 132. While RNG IP 660 may implement a pseudo-random number generator in some embodiments, in others, it implements a true random number generator that uses an external random source such as measured temperature. In various embodiments, RNG IP 660 cannot be accessed by components outside SEP 500, such as processor 102.

[0063] Hash IP 670 is a circuit configured to implement any suitable hash algorithm that can be used by the components in SEP 500, such as the Secure Hash Algorithm (SHA), Hash-based Message Authentication Code (HMAC), etc. Therefore, Hash IP 670 can generate hash values ​​that are encrypted / signed by PKA IP 620—or compared by PKA IP 620 in signature verification.

[0064] Turn now Figure 7 A flowchart is depicted for a method 700 for establishing a shared secret between two devices. Method 700 is one embodiment of a method performed by a computing device such as device 100A, which may include cryptographic circuitry 120. In some instances, execution of method 700 may allow the device (e.g., device 100A) to establish a shared secret (e.g., shared secret 134) without revealing key material (e.g., private key material 132) to insecure components of the device.

[0065] In step 705, (e.g. via request 114) the execution of a key exchange (e.g., key exchange 122) is requested to establish a shared secret with another device (e.g., device 100B).

[0066] In step 710, the cryptographic circuitry (e.g., cryptographic circuitry 120) performs a key exchange that includes deriving a shared secret using private key material maintained in a secure memory (e.g., secure memory 130). In some embodiments, deriving the shared secret includes performing an elliptic curve Diffie-Hellman (ECDH) operation using the private key material. In some embodiments, the processor exchanges sensitive data (e.g., symmetric keys, asymmetric private keys, authentication credentials, transaction credentials, etc.) encrypted using the derived shared secret with another device. In some embodiments, the cryptographic circuitry is a public key accelerator (e.g., PKA 620).

[0067] In some embodiments, the device also includes a read-only memory (ROM) storing immutable program instructions (e.g., PKA ROM 630) that can be executed by cryptographic circuitry to perform a key exchange. In some embodiments, the cryptographic circuitry is further configured to execute a sequence of program instructions in a specific order to perform a key exchange, and to prevent out-of-order execution of the sequence by clearing portions 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.

[0068] In some embodiments, method 700 further includes cryptographic circuitry verifying a key authorization data structure (e.g., key authorization 214) from a key authorization authority (e.g., key authorization authority 210) to indicate that a 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 authority (e.g., participant authorization authority 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 authority (e.g., participant authorization authority 220B) authorized to identify the other device as a member of the second device group.

[0069] In some embodiments, method 700 further includes a random number generator circuit (e.g., RNG IP 660) coupled to the cryptographic circuit and inaccessible to the processor, providing random values ​​to the cryptographic circuit for storage in secure memory as part of private key material. In some embodiments, a fuse library (e.g., fuse 650) coupled to the cryptographic circuit and inaccessible to the processor is configured during the manufacture of the cryptographic circuit to store key material (e.g., UID 652) that can be used by the cryptographic circuit to derive a portion of the private key material stored in secure memory.

[0070] In some implementations, method 700 further includes determining whether the key exchange was authorized by verifying multiple proofs (e.g., participant proof 224) associated with the public key pair exchanged during the key exchange. The multiple proofs may include a first key proof (participant proof 224) identifying a computing device's public key (e.g., public PIK 232B) as a member of a first device group (e.g., device group 230A) and a second key proof identifying another device's public key as a member of a second device group (e.g., device group 230B). The multiple proofs may also include key exchange authorization (e.g., key authorization 214) identifying a first public key (e.g., public PAK 222B1) of a first participant authorizing authority (e.g., participant authorizing authority 220A) and a second public key (e.g., public PAK 222B2) of a second participant authorizing authority (e.g., participant authorizing authority 220B), the first participant authorizing authority identifying the computing device's public key as a member of the first device group and the second participant authorizing authority identifying another device's public key as a member of the second device group.

[0071] In some implementations, in response to the issuance of a key authorization data structure, a disaster recovery (DR) key pair (e.g., keys 462A-462B) generated by a key authorization authority (e.g., a revoked key authorization authority 210A) is received. In this implementation, in response to the subsequent revocation of the key authorization authority (e.g., via key authorization authority revocation 450), the DR key pair is used to establish another key authorization authority (e.g., a new key authorization authority 210B).

[0072] Turn now Figure 8A A flowchart is depicted for a method 800 for establishing a shared secret between two devices. Method 800 is another implementation of a method performed by a first computing device (such as device 100A) belonging to a first device group (such as device group 230A). In some instances, the execution of method 800 may allow for more secure key exchange because an authorization hierarchy can be used to verify participants.

[0073] 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 the second device group (e.g., device group 230B).

[0074] In step 810, the computing system verifies a key authorization data structure (e.g., key authorization 214) issued by a key authorization authority (e.g., key authorization authority 210), wherein the key authorization data structure includes a first public key (e.g., public PAK 222B1) of a first participant authorization authority (e.g., participant authorization authority 220A) authorized to identify members of a first device group and a second public key (e.g., public PAK 222B2) of a second participant authorization authority (e.g., participant authorization authority 220B) authorized to identify members of a second device group.

[0075] In step 815, the computing device, in response to successful verification, performs the requested exchange using a public key pair (e.g., PEK pair 234) that has been certified by the first participant's authorized authority as a member of the first device group. In some embodiments, method 800 also includes exchanging sensitive data encrypted with a second device using an established shared secret (e.g., a symmetric key, user authentication credentials, or asymmetric (private) key).

[0076] In some embodiments, method 800 further includes generating a Participant Identity Key (PIK) pair (e.g., PIK 232A-232B) associated with the identity of the first device, and transmitting a request to a first participant authority to issue proof identifying the PIK pair as associated with a member of the first device group. In this embodiment, the generation may include deriving the PIK pair using previously stored key material (e.g., UID 652), which is trusted by the first participant authority and can be used by the first participant authority to establish that the first device is a member of the first device group. In some embodiments, the request includes account information for a user account associated with each device in the first device group and which can be used by the first participant authority to determine that the first device is a member of the first device group. In some implementations, performing the requested exchange may include: generating a temporary first participant exchange key (PEK) pair (e.g., PEK pair 234) certified by the PIK pair; exchanging the public keys of the first PEK pair and the second PEK pair generated by the second device with the second device; and deriving the shared secret by performing an elliptic curve Diffie-Hellman (ECDH) operation using the private key of the first PEK pair and the exchanged public key of the second PEK pair.

[0077] In some embodiments, method 800 further includes: receiving a revocation request to revoke the membership of a first device in a first device group (e.g., revocation request 402); and in response to the revocation request: deleting the public key pair certified by the first participant's authorized authority; and transmitting a request to the first participant's authorized authority to remove the first device from the first device group. In some embodiments, method 800 further includes: receiving a revocation request to revoke the membership of another device (e.g., lost device 100A1) in a first device group (e.g., revocation request 412); and in response to the revocation request: transmitting a request to the first participant's authorized authority to replace the first public key of the first participant's authorized authority with another public key (e.g., a new public PAK 222B1); and transmitting a request to the first participant's authorized authority to certify the other public key pair using a private key corresponding to the other public key (e.g., a new private PAK 222A1) (e.g., via new participant certification 224).

[0078] In some implementations, method 800 further includes: receiving a disaster recovery (DR) key pair certified by a key authority (e.g., DR keys 462A-462B associated with DR certificate 460); and in response to determining that the revocation of the key authority is necessary: ​​signing a request for members of the first and second device groups to cease using the key authorization data structure using the private key of the DR key pair (e.g., private DR key 462A); and signing a certificate (e.g., key authority certificate 470) for establishing another key authority (e.g., new key authority 210B) for authorizing key exchange between the first and second device groups using the private key of the DR key pair.

[0079] Turn now Figure 8B A flowchart is depicted for providing proof, specifically method 830. Method 830 is an implementation of a method performed by a participant-authorizing body, such as participant-authorizing body 220A. In some instances, the performance of method 830 may provide benefits similar to those noted above with respect to method 800.

[0080] In step 835, the participant authorizing authority receives from the first device (e.g., device 100A) a request for a signed certificate (e.g., participant certificate 224) issued to the first participant authorizing authority, the signed certificate indicating that the public key of the first device (e.g., public PIK 232B) belongs to a member of the first device group (e.g., device group 230A) authorized to participate in key exchanges (e.g., key exchange 122) with members of the second device group (e.g., device group 230B).

[0081] In step 840, the participant authorizing authority determines whether the first device is a member of the first device group, including verifying a key authorization data structure (e.g., key authorization 214) issued by a key authorizing authority (e.g., key authorizing authority 210), wherein the key authorization data structure includes a first public key (e.g., public PAK 222B1) of the first participant authorizing authority authorized to identify a member of the first device group and a second public key (e.g., public PAK 222B2) of the second participant authorizing authority (e.g., participant authorizing authority 220B) authorized to identify a member of the second device group.

[0082] In step 845, the participant authorizing authority provides the first device with a certificate signed by a first private key (e.g., private PAK 222A1) corresponding to the first public key, based on the determination.

[0083] Turn now Figure 8CA flowchart is depicted for a method 860 for providing key authorization. Method 860 is an implementation of a method performed by a key authorization authority such as key authorization authority 210. In some instances, the execution of method 860 may provide benefits similar to those noted above with respect to method 800.

[0084] In step 865, the key authorization authority receives a request to authorize the execution of a key exchange (e.g., key exchange 122) between the first device group (e.g., device group 230A) and the second device group (e.g., device group 230B).

[0085] In step 870, the key authorization authority signs a key authorization data structure (e.g., key authorization 214), which includes a first public key (e.g., public PAK 222B1) of a first participant authorization authority (e.g., participant authorization authority 220A) authorized to identify members of a first device group (e.g., device group 230A) and a second public key (e.g., public PAK 222B2) of a second participant authorization authority (e.g., participant authorization authority 220B) authorized to identify members of a second device group (e.g., device group 230B).

[0086] In step 875, the key authorizing authority provides a signed key authorizing data structure to the first participant authorizing authority and the second participant authorizing authority to authorize the execution of key exchange between members of the first device group and the second device group.

[0087] Exemplary computer system Now for reference Figure 9 A block diagram illustrating an example embodiment of device 900 is shown. In some embodiments, device 900 may implement the functionality of one or both of devices 100A and 100B. In some embodiments, the components of device 900 may be included within a system-on-a-chip. In some embodiments, device 900 may be included in a mobile device that may be battery-powered. Therefore, the power consumption of device 900 may be an important design consideration. In the illustrated embodiment, device 900 includes a structure 910, a computing 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, as supplements or alternatives to the illustrated components, device 900 may also include other components (not shown), such as video processor encoders and decoders, image processing or recognition elements, computer vision elements, etc.

[0088] Structure 910 may include various interconnects, buses, MUXs, controllers, etc., and may be configured to facilitate communication between various components of device 900. In some embodiments, portions of structure 910 may be configured to implement various different communication protocols. In other embodiments, structure 910 may implement a single communication protocol, and components coupled to structure 910 may internally switch from a single communication protocol to other communication protocols.

[0089] In the illustrated implementation, computing complex 920 includes a bus interface unit (BIU) 925, a cache 930, and cores 935 and 940. In various implementations, computing complex 920 may include a variety of numbers of processors, processor cores, and caches. For example, computing complex 920 may include one, two, four, or any other suitable number of processor cores. In one implementation, cache 930 is a set-associative L2 cache. In some implementations, cores 935 and 940 may include internal instruction and data caches. In some implementations, a coherence unit (not shown) in architecture 910, cache 930, or elsewhere in device 900 may be configured to maintain coherence between the various caches of device 900. BIU 925 may be configured to manage communication between computing complex 920 and other elements of device 900. Processor cores (such as cores 935 and 940) may be configured to execute instructions of a specific instruction set architecture (ISA) that may include operating system instructions and user application instructions. These instructions may be stored in a computer-readable medium, such as memory coupled to the memory controller 945 discussed below. In some embodiments, the computing complex may implement the processor 102 discussed above.

[0090] As used herein, the term "coupled to" can indicate one or more connections between elements, and coupling can include intermediate elements. For example, in Figure 9 In this context, the graphics unit 975 can be described as being "coupled" to memory via structure 910 and cache / memory controller 945. In contrast, in... Figure 9 In the exemplary implementation, the graphics unit 975 is "directly coupled" to the structure 910 because there are no intermediate elements.

[0091] The cache / memory controller 945 can be configured to manage data transfer between the architecture 910 and one or more caches and memories. For example, the cache / memory controller 945 may be coupled to an L3 cache, which in turn may be coupled to system memory. In other embodiments, the cache / memory controller 945 may be directly coupled to memory. In some embodiments, the cache / memory controller 945 may include one or more internal caches. The memory coupled to the controller 945 can be any type of volatile memory, such as dynamic random access memory (DRAM), synchronous DRAM (SDRAM), dual 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 may be coupled onto a circuit board to form a memory module, such as a single in-line memory module (SIMM), a dual in-line memory module (DIMM), etc. Alternatively, these devices may be mounted with integrated circuits in a chip-stacked configuration, a package-stacked configuration, or a 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, nanometer RAM (NRAM), magnetoresistive RAM (MRAM), phase-change RAM (PRAM), raceway memory, memristor memory, etc. As noted above, the memory may store program instructions (such as those of application 110) that can be executed by the computing complex 920 to cause the computing device to perform the functionalities described herein.

[0092] The graphics unit 975 may include one or more processors, such as one or more graphics processing units (GPUs). For example, the graphics unit 975 may receive graphics-oriented instructions, such as OpenGL. ® Metal ® Or DIRECT3D ®Instructions. The graphics unit 975 can execute dedicated GPU instructions or perform other operations based on received graphics-oriented instructions. The graphics unit 975 is typically configured to process large blocks of data in parallel and can construct an image in a framebuffer for output to a display, which may be included in a device or may be a separate device. The graphics unit 975 may include a transformation engine, a lighting engine, a triangle engine, and a rendering engine in one or more graphics processing pipelines. The graphics unit 975 can output pixel information for displaying the image. In various embodiments, the graphics unit 975 may include programmable shader circuitry, which may include highly parallel execution cores configured to execute graphics programs, which may include pixel tasks, vertex tasks, and computation tasks (which may be graphics-dependent or not).

[0093] Display unit 965 can be configured to read data from a frame buffer and provide a stream of pixel values ​​for display. In some embodiments, display unit 965 can be configured as a display pipeline. Additionally, display unit 965 can be configured to blend multiple frames to produce an output frame. Furthermore, display unit 965 may include one or more interfaces (e.g., MIPI) for coupling to a user display (e.g., a touchscreen or an external display). ® Or embedded display port (eDP)).

[0094] I / O bridge 950 may include various components configured to implement functionalities such as Universal Serial Bus (USB) communication, security, audio, and low-power always-on connectivity. I / O bridge 950 may also include interfaces such as pulse-width modulation (PWM), general-purpose input / output (GPIO), serial peripheral interface (SPI), and internal integrated circuit (I2C). Various types of peripheral devices and equipment can be coupled to device 900 via I / O bridge 950.

[0095] In some embodiments, device 900 includes network interface circuitry (not explicitly shown) that can be connected to structure 910 or I / O bridge 950. This network interface circuitry can be configured to communicate via various networks, which can be wired networks, wireless networks, or both. For example, the network interface circuitry can be configured to communicate via a wired local area network (LAN), a wireless LAN (e.g., via Wi-Fi), or a wireless LAN. ™ The network interface circuitry can communicate via one or more cellular networks using one or more radio access technologies, or wide area networks (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 ™Communication can be achieved through direct connection, etc. In various implementations, the network interface circuitry can provide device 900 with connectivity to various types of other devices and networks.

[0096] Example Application Turn now Figure 10 This can include various types of systems, including any of the circuits, devices, or systems discussed above. The system or device 1000, which may utilize one or more of the techniques described herein in combination with or otherwise, can be used in a wide range of fields. For example, the system or device 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 a television).

[0097] Similarly, the disclosed components can be used in wearable devices 1060 such as smartwatches or health monitoring devices. In many embodiments, a smartwatch can perform a variety of different functions—for example, access to email, cellular services, calendars, health monitoring, etc. Wearable devices can also be designed to perform only 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, implantable devices, and glasses or helmets designed to provide computer-generated reality experiences, such as those based on augmented reality and / or virtual reality.

[0098] System or device 1000 can also be used in a variety of other contexts. For example, system or device 1000 can be used in the context of a server computer system (such as a dedicated server) or on shared hardware implementing cloud-based services 1070. Furthermore, system or device 1000 can be implemented in a wide range of dedicated everyday devices, including common household appliances 1080 such as refrigerators, thermostats, security cameras, etc. The interconnection of such devices is often referred to as the “Internet of Things” (IoT). Components can also be implemented in various modes of transportation. For example, system or device 1000 can be used in control systems, guidance systems, entertainment systems, etc., of various types of vehicles 1090.

[0099] Figure 10 The applications illustrated are merely exemplary and are not intended to limit the potential future applications of the disclosed systems or devices. Other example applications include, but are not limited to, portable gaming devices, music players, data storage devices, and unmanned aerial vehicles.

[0100] Example computer-readable media Various example circuits have been described in detail above in this disclosure. It is intended that this disclosure cover not only embodiments including such circuits, but also computer-readable storage media that include design information specifying such circuits. Therefore, this disclosure is intended to support claims that specify storage media for circuits in formats that cover not only means including the disclosed circuits, but also analog models for programming computing systems to generate hardware circuits, manufacturing systems configured to generate hardware (e.g., integrated circuits) including the disclosed circuits. Claims for such storage media are intended to cover entities that, for example, generate circuit designs but do not themselves perform complete operations (such as design simulation, design synthesis, circuit fabrication, etc.).

[0101] Figure 11 This 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 may include executing instructions included in the design information, interpreting instructions included in the design information, compiling, transforming, or otherwise updating the design information. Thus, in some embodiments, the design information (e.g., by programming computing system 1140) controls computing system 1140 to perform the various operations discussed below.

[0102] In the illustrated example, computing system 1140 processes design information to generate both a computer simulation model of hardware circuitry 1160 and lower-level design information 1150. In other embodiments, computing system 1140 may generate only one of these outputs, may generate other outputs based on the design information, or both. Regarding the computational simulation, computing system 1140 may execute instructions in a hardware description language, which includes register transfer level (RTL) code, behavioral code, structural code, or a combination thereof. The simulation model may perform the functionality specified by the design information, facilitate verification of the functional correctness of the hardware design, generate power consumption estimates, generate timing estimates, etc.

[0103] In the illustrated example, computing system 1140 also processes design information to generate lower-level design information 1150 (e.g., gate-level design information, netlists, etc.). As shown, this may include synthesis operations such as constructing multi-level networks, optimizing the network using technology-independent techniques, technology-dependent techniques, or both, and outputting a gate network (with potential constraints based on a library of available gate pairs, size adjustments, delays, power, etc.). Based on the lower-level design information 1150 (and potentially other inputs), semiconductor manufacturing system 1120 is configured to manufacture integrated circuit 1130 (which may correspond to the functionality of simulation model 1160). Note that computing system 1140 may generate different simulation models based on design information at various descriptive levels (including information 1150, 1115, etc.). Data representing design information 1150 and model 1160 may be stored on medium 1110 or one or more other media.

[0104] In some implementations, lower-level design information 1150 controls (e.g., programs) the 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 circuits disclosed herein.

[0105] The nontransitory computer-readable storage medium 1110 may include any of a variety of suitable types of memory devices or storage devices. The nontransitory computer-readable storage medium 1110 may be an installation medium, such as a CD-ROM, floppy disk, or magnetic tape device; computer system memory or random access memory, such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memory, such as flash memory; magnetic media, such as a hard disk drive or optical storage device; registers or other similar types of memory elements, etc. The nontransitory computer-readable storage medium 1110 may also include other types of nontransitory memory or combinations thereof. Therefore, the nontransitory computer-readable storage medium 1110 may include two or more memory media; such media may reside in different locations—for example, in different computer systems connected via a network.

[0106] Design information 1115 can be specified using any 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 format of the various design information can be recognized by one or more applications executed by computing system 1140, semiconductor manufacturing system 1120, or both. In some embodiments, the design information may also include one or more cell libraries specifying the composition, layout, or both of integrated circuit 1130. In some embodiments, the design information is specified wholly or partially in the form of a netlist specifying cell library elements and their connectivity. Individually, the design information discussed herein may or may not include sufficient information for manufacturing the corresponding integrated circuit. For example, the design information may specify the circuit elements to be manufactured but not their physical layout. In this case, the design information may be combined with layout information to actually manufacture the specified circuit.

[0107] In various implementations, integrated circuit 1130 may include one or more custom macrocells, such as memory, analog or mixed-signal circuitry, etc. In such cases, design information may include information associated with the included macrocells. Such information may include, but is not limited to, schematic capture databases, mask design data, behavioral models, and device or transistor-level netlists. Mask design data may be formatted according to a Graphical Data System (GDSII) or any other suitable format.

[0108] The semiconductor manufacturing system 1120 may include any of the suitable elements configured to manufacture integrated circuits. This may include elements for, for example, depositing semiconductor material (e.g., on a wafer that may include a mask), removing material, changing the shape of the deposited material, modifying the material (e.g., by doping the material or by using ultraviolet treatment to modify the dielectric constant), etc. The semiconductor manufacturing system 1120 may also be configured to perform various tests on the manufactured circuits to ensure proper operation.

[0109] In various embodiments, integrated circuit 1130 and model 1160 are configured to operate according to a circuit design specified by design information 1115, which may include performing any of the functionalities described herein. For example, integrated circuit 1130 may include Figure 1 Any of the various components shown, such as cryptographic circuitry 120 and secure memory 130. Furthermore, integrated circuit 1130 can be configured to perform the various functions described herein in conjunction with other components. Moreover, the functionality described herein can be performed by multiple interconnected integrated circuits.

[0110] As used herein, a phrase in the form of “design information specifying a circuit configured to…” does not imply that the circuit in question must be manufactured to satisfy the element. Rather, the phrase indicates that the design information describes a circuit that, when manufactured, will be configured to perform the indicated actions or will include the specified components. Similarly, stating that “instructions of a hardware description programming language” are “executable” to program a computing system to generate a computer simulation model does not mean that the instructions must be executed to satisfy the element, but rather specifies the characteristics of those instructions. In this case, additional features associated with the model (or the circuit represented by the model) may similarly relate to the characteristics of those instructions. Therefore, an entity selling a computer-readable medium having instructions that satisfy the stated characteristics may provide an infringing product even if another entity actually executes those instructions on the medium.

[0111] It is important to note that a given design, at least within a digital logic context, can be implemented using multiple different gate arrangements, circuit techniques, etc. As an example, different designs may choose or connect gates based on design trade-offs (e.g., focusing on power consumption, performance, circuit area, etc.). Furthermore, 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 layers (e.g., from behavioral specifications to the physical layout of gates).

[0112] However, once a digital logic design is specified, those skilled in the art do not need to perform extensive experiments or studies to determine these specific implementations. Instead, they understand the process for reliably and predictably producing 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 (potentially involving trade-offs between different design goals), but the logic function remains unchanged between different circuit implementations of the same circuit design.

[0113] In some implementations, instructions included in 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 netlist representing the hardware circuitry based on the RTL information as input. Similarly, these instructions provide behavioral information and can be executed by the computing system to synthesize netlists or other lower-level design information. The lower-level design information can be used to program manufacturing system 1120 to manufacture integrated circuit 1130.

[0114] This disclosure includes references to “one implementation” or “a group of implementations” (e.g., “some implementations” or “various implementations”). An implementation is a different specific embodiment or instance of the disclosed concepts. References to “implementation,” “one implementation,” and “specific implementation,” etc., do not necessarily refer to the same implementation. A large number of possible implementations are contemplated, including those specifically disclosed, as well as modifications or alternatives that fall within the substance or scope of this disclosure.

[0115] This disclosure may discuss potential advantages that may arise from the disclosed embodiments. Not all specific implementations of all these embodiments will necessarily exhibit any or all of the potential advantages. Whether a particular embodiment achieves an advantage depends on many factors, some of which are outside the scope of this disclosure. In fact, there are many reasons why an embodiment falling within the scope of the claims may not exhibit some or all of any of the disclosed advantages. For example, a particular embodiment may include other circuitry outside the scope of this disclosure, in conjunction with one embodiment of the disclosed embodiments, which negates or diminishes one or more of the disclosed advantages. Furthermore, suboptimal design execution of a particular embodiment (e.g., the implementing technique or tool) may also negate or diminish the disclosed advantages. Even assuming an implementation of the technique, the realization of advantages may still depend on other factors, such as the environmental circumstances in which the implementation is deployed. For example, the inputs provided to a particular embodiment may prevent one or more problems addressed in this disclosure from occurring in a particular context, and as a result, the benefits of its solution may not be realized. In view of the existence of possible factors outside this disclosure, it is hereby expressed that any potential advantages described herein should not be construed as a limitation of the claims that must be satisfied in order to prove infringement. Rather, the identification of such potential advantages is intended to illustrate the types of improvements available to the designer who benefits from this disclosure. Describing such advantages permanently (e.g., stating that a particular advantage "may occur") is not intended to convey a question about whether such advantages can actually be realized, but rather to recognize that the realization of such advantages often depends on the technological reality of additional factors.

[0116] Unless otherwise stated, the embodiments are non-limiting. That is, the disclosed embodiments are not intended to limit the scope of the claims drafted based on this disclosure, even where only a single example is described with respect to a particular feature. The disclosed embodiments are intended to be illustrative and not restrictive, without any statement to the contrary in this disclosure. Therefore, this application is intended to allow for claims covering the disclosed embodiments, as well as such alternatives, modifications, and equivalents, which will be apparent to those skilled in the art to the advantage of this disclosure.

[0117] For example, the features in the present application can be combined in any suitable manner. Thus, during the filing of the present application (or an application claiming priority therefrom), new claims can be made for any such combination of features. Specifically, referring to the appended claims, the features of dependent claims can be combined with the features of other dependent claims, where appropriate, including claims that depend on other independent claims. Similarly, where appropriate, the features from corresponding independent claims can be combined.

[0118] Thus, although the appended dependent claims can be drafted such that each dependent claim depends on a single other claim, additional dependencies are also contemplated. Any combination of dependent features that conform to the present disclosure is contemplated, and such combinations can be claimed in the present application or another application. In short, the combinations are not limited to those specifically listed in the appended claims.

[0119] Where 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).

[0120] Since the present disclosure is a legal document, various terms and phrases are subject to administrative and judicial interpretation. It is hereby announced that the following paragraphs and the definitions provided throughout the present disclosure will be used to determine how claims drafted based on the present disclosure are to be interpreted.

[0121] Unless the context clearly indicates otherwise, a reference to an item in the singular form (i.e., a noun or noun phrase preceded by "a", "an", or "the") is intended to mean "one or more". Thus, without accompanying context, a reference to an "item" in a claim does not exclude additional instances of that item. "Multiple" items means a collection of two or more items in the set of items.

[0122] The word "may" is used herein in an allowable sense (i.e., having the potential to be able), rather than in a mandatory sense (i.e., must).

[0123] The terms "comprising" and "including" and their forms are open-ended and mean "including but not limited to".

[0124] When the term “or” is used in this disclosure relative to a list of options, it will generally be understood to be used in an inclusive sense unless the context otherwise provides. Thus, the expression “x or y” is equivalent to “x or y, or both”, and therefore covers 1) x but not y, 2) y but not x, and 3) both x and y. On the other hand, phrases such as “either x or y, but not both” make it clear that “or” is used in an exclusive sense.

[0125] The expressions “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 a single element up to the total number of elements in the set. For example, given the set [w, x, y, z], these phrases cover any single element in 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. The phrase “...at least one of w, x, y, and z” therefore refers to at least one element in the set [w, x, y, z], thus covering all possible combinations of that list of elements. This phrase should not be interpreted as requiring the existence of 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.

[0126] In this disclosure, various “labels” may precede nouns or noun phrases. Unless the context otherwise provides, different labels used for features (e.g., “first circuit,” “second circuit,” “specific circuit,” “given circuit,” etc.) refer to different instances of the feature. Additionally, unless otherwise stated, the labels “first,” “second,” and “third” do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) when applied to features.

[0127] The phrase "based on" is used to describe one or more factors that influence the determination. This term does not exclude the possibility that additional factors might influence the determination. That is, the determination may be based solely on the specified factors or on the specified factors along with other unspecified factors. Consider the phrase "A is determined based on B." This phrase specifies that B is a factor used to determine A or that B influences the determination of A. This phrase does not exclude the possibility that the determination of A may also be based on some other factor, such as C. This phrase is also intended to cover implementations where A is determined solely based on B. As used herein, the phrase "based on" is synonymous with the phrase "at least partially based on."

[0128] The phrases “responding to” and “responding” describe one or more factors that trigger an effect. This phrase does not exclude the possibility that additional factors may influence or otherwise trigger the effect, whether these factors are used in conjunction with or independently of the specified factor. That is, the effect may respond solely to these factors, or it may respond to the specified factor as well as other unspecified factors. Consider the phrase “responding to B and executing A.” This phrase specifies that B is a factor that triggers the execution of A or triggers a specific result of A. This phrase does not exclude that the execution of A may also respond to certain other factors, such as C. This phrase also does not exclude that the execution of A may be jointly executed in response to B and C. This phrase is also intended to cover implementation schemes where A is executed solely in response to B. As used herein, the phrase “responding” is synonymous with the phrase “at least partially responding to.” Similarly, the phrase “responding to” is synonymous with the phrase “at least partially responding to.”

[0129] Within this disclosure, different entities (which may be referred to differently as “units,” “circuits,” other components, etc.) may be described or protected by the claims as being “configured” to perform one or more tasks or operations. This expression—[entity] configured to [perform one or more tasks]—is used herein to refer to a structure (i.e., a tangible thing). More specifically, this expression is used to indicate that the structure is arranged to perform one or more tasks during operation. A structure may be considered “configured” to perform a task even if the structure is not currently being operated. Thus, an entity described or stated as being “configured” to perform a task refers to tangible things such as devices, circuits, systems with processor units, and memory storing program instructions executable to perform the task. This phrase is not used herein to refer to intangible things.

[0130] In some cases, various units / circuits / components may be described herein as a collection of entities that perform tasks or operations. It should be understood that these entities are "configured" to perform those tasks / operations, even if not specifically stated otherwise.

[0131] The term "configured as" is not intended to mean "able to be configured as." For example, an unprogrammed FPGA is not considered "configured as" to perform a specific function. However, the unprogrammed FPGA can be "configurable as" to perform that function. After proper programming, the FPGA can then be considered "configured as" to perform a specific function.

[0132] For the purposes of this U.S. patent application based on this disclosure, the statement in the claims that a structure is “configured” to perform one or more tasks is expressly intended not to invoke 35 USC § 112(f) for that claim element. If an applicant wishes to invoke part 112(f) during the filing of a U.S. patent application based on this disclosure, it will use the “component for [performing a function]” structure to state the elements of the claims.

[0133] Different “circuits” may be described in this disclosure. These circuits, or “circuits”, constitute hardware that includes various types of circuit elements, such as combinational logic, clock storage devices (e.g., flip-flops, registers, latches, etc.), finite state machines, memories (e.g., random access memory, embedded dynamic random access memory), programmable logic arrays, etc. Circuits may be custom-designed or taken from standard libraries. In various specific implementations, circuits may include digital components, analog components, or a combination of both, depending on the circumstances. Certain types of circuits may be commonly referred to as “cells” (e.g., decoding units, arithmetic logic units (ALUs), functional units, memory management units (MMUs), etc.). Such cells also refer to circuits or circuitry.

[0134] Therefore, the circuits / units / components and other elements illustrated in the accompanying drawings and described herein include hardware elements, such as those described in the preceding paragraphs. In many cases, the internal arrangement of hardware elements in a particular circuit can be specified by describing the function of that circuit. For example, a particular “decoding unit” can be described as having the function of executing “the opcode of a processing instruction and routing that instruction to one or more of a plurality of functional units,” meaning that the decoding unit is “configured” to perform that function. To those skilled in the art of computers, this functional specification is sufficient to suggest a set of possible structures for the circuit.

[0135] In various implementations, as discussed in the preceding paragraphs, circuits, cells, and other elements can be defined by the functions or operations they are configured to perform. The arrangement of these circuits / cells / components relative to each other and the manner in which they interact form a microarchitecture definition of hardware, which is ultimately manufactured in an integrated circuit or programmed into an FPGA to form a physical implementation of the microarchitecture definition. Therefore, a microarchitecture definition is considered by those skilled in the art to be a structure from which many physical implementations can be derived, all of which fall within the broader structure described by the microarchitecture definition. That is, those skilled in the art, with the microarchitecture definition provided according to this disclosure, can implement this structure without excessive experimentation and using the application of a person of ordinary skill in the art, by encoding the description of the circuits / cells / components in a hardware description language (HDL) such as Verilog or VHDL. The HDL description is often expressed in a way that can be revealed as functional. However, for those skilled in the art, the HDL description is a way of transforming the structure of a circuit, cell, or component into the details of the next level of implementation. Such HDL descriptions can take the following forms: behavioral code (which is typically non-synthesizable), Register Transfer Language (RTL) code (which is typically synthesizable compared to behavioral code), or structural code (e.g., a netlist specifying logic gates and their connectivity). HDL descriptions can be sequentially synthesized against a library of cells designed for a given integrated circuit manufacturing technology and can be modified for timing, power, and other reasons to obtain a final design database that is sent to the factory to generate masks and ultimately produce integrated circuits. Some hardware circuitry or portions thereof can also be custom-designed in a schematic editor and captured into the integrated circuit design along with the synthesized circuitry. The integrated circuit can include transistors and other circuit elements (e.g., passive components such as capacitors, resistors, inductors, etc.), as well as interconnects between transistors and circuit elements. Some implementations may implement multiple integrated circuits coupled together to implement the hardware circuitry, and / or discrete components may be used in some implementations. Alternatively, the HDL design can be synthesized into a programmable logic array such as a Field Programmable Gate Array (FPGA) and implemented within the FPGA. This decoupling between the design of a set of circuits and their subsequent low-level implementations often results in a situation where the circuit or logic designer never specifies a particular set of structures for the low-level implementation that goes beyond a description of what the circuit is configured to do, because that process is performed at different stages of the circuit implementation process.

[0136] The fact that a circuit can be implemented to the same specifications using many different low-level combinations of circuit elements results in a large number of equivalent circuit structures. As noted, these low-level circuit implementations can vary depending on the manufacturing technology, the foundry chosen to manufacture the integrated circuit, the cell library provided for a particular project, and so on. In many cases, the choice of different design tools or methods to produce these different implementations can be arbitrary.

[0137] Furthermore, for a given implementation, a single concrete implementation of the circuit's specific functional specifications typically involves a large number of devices (e.g., millions of transistors). Therefore, the shearing volume of this information makes it impractical to provide a complete description of the low-level structure used to implement a single implementation, let alone a large number of equivalent possible implementations. To this end, this disclosure describes the structure of a circuit using functional abbreviations commonly used in industry.

[0138] Based on the foregoing description, various implementation schemes for establishing a shared secret cryptographic key exchange are envisioned, including but not limited to the implementation schemes listed below.

[0139] 1. A non-transitory computer-readable medium having program instructions stored thereon, the program instructions being executable by a first device belonging to a first group of devices to cause the first computing device to perform operations including: Receive a request to perform a key exchange to establish a shared secret with a second device belonging to the second device group; Verify the key authorization data structure issued by the 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 device group and a second public key of a second participant authorization authority authorized to identify members of the second device group; and In response to the successful verification, the requested exchange is performed using a public key pair that has been certified by the first participant's authorized authority as a member of the first device group.

[0140] 2. The computer-readable medium according to embodiment 1, wherein the operation further includes: Generate a participant identity key (PIK) pair associated with the identity of the first device; and The request is transmitted to the first participant's authorizing body to issue a certificate identifying the PIK pair as associated with a member of the first device group.

[0141] 3. The computer-readable medium according to embodiment 2, wherein the request includes account information of a user account associated with each device group in the first device group and usable by the first participant's authorizing authority to determine that the first device is a member of the first device group.

[0142] 4. The computer-readable medium according to embodiment 2, wherein the generation includes: The PIK pair is derived using previously stored key material trusted by the first participant's authorized authority and capable of being used by the first participant's authorized authority to establish that the first device is a member of the first device group.

[0143] 5. The computer-readable medium according to embodiment 2, wherein performing the requested exchange includes: Generate a temporary first participant exchange key (PEK) pair proved by the PIK pair; Exchange the public keys of the first PEK pair and the second PEK pair generated by the second device with the second device; and The shared secret is derived by performing an elliptic curve Diffie-Hellman (ECDH) algorithm using the private key of the first PEK pair and the exchanged public key of the second PEK pair.

[0144] 6. The computer-readable medium according to embodiment 1, wherein the operation further includes: Receive a revocation request to revoke the membership of the first device in the first device group; In response to the revocation request: Delete the public key pair certified by the first participant's authorized authority; and A request to remove the first device from the first device group is sent to the first participant's authorized agency.

[0145] 7. The computer-readable medium according to embodiment 1, wherein the operation further includes: Receive a revocation request to revoke the membership of another device in the first device group; In response to the revocation request: Send a request to the first participant's authorizing authority to replace the first public key of the first participant's authorizing authority with another public key; and A request is sent to the first participant's authorized authority to prove another public key pair using a private key corresponding to another public key.

[0146] 8. The computer-readable medium according to embodiment 1, wherein the operation further includes: Receive a disaster recovery (DR) key pair certified by the key authorization authority; It is necessary to determine the revocation of the key authorization authority: The private key pair of the DR key pair is used to sign requests from members of the first device group and the second device group to stop using the key authorization data structure; and The DR key pair is used to sign a certificate of the private key pair, which establishes another key authority for authorizing key exchanges between the first device group and the second device group.

[0147] 9. The computer-readable medium according to embodiment 1, wherein the operation further includes: The second device exchanges a shared secret encrypted symmetric key with the second device.

[0148] 10. The computer-readable medium according to embodiment 1, wherein the operation further includes: Provide the second device with user authentication credentials encrypted using the established shared secret.

[0149] 11. A non-transitory computer-readable medium having program instructions stored therein, the program instructions being executable by a computing system implementing a first participant's authorization to cause the computing system to perform operations including: The first device receives a request for a certificate of signature issued to the first participant's authorizing authority, the certificate of signature indicating that the first device's public key belongs to a member of the first device group authorized to participate in key exchange with members of the second device group; Determining whether the first device is a member of the first device group includes verifying a key authorization data structure issued by a key authorization authority, wherein the key authorization data structure includes a first public key of the first participant authorization authority authorized to identify a member of the first device group and a second public key of a second participant authorization authority authorized to identify a member of the second device group; and Based on the determination, the first device is provided with the proof signed by the first private key of the first public key corresponding to the first participant's authorized authority.

[0150] 12. The computer-readable medium according to embodiment 11, wherein the operation further includes: The second device receives a request to remove itself from a given group of devices, the membership of which is certified by the first participant's authorized body; and The second device is removed from the given group of devices in response to the request.

[0151] 13. The computer-readable medium according to embodiment 11, wherein the request includes account information of a user account associated with each device in the first group of devices.

[0152] 14. The computer-readable medium according to embodiment 11, wherein the operation further comprises: Receive a revocation request to revoke the membership of the first device in the first device group; In response to the revocation request: Replace the first public key and the first private key with another public key pair; Request from the key authorization authority another key authorization data structure including the public key in the other public key pair; and Provide another member of the first device group with an indication that the proof of the signature of the first device has been revoked.

[0153] 15. The computer-readable medium according to embodiment 14, wherein the operation further includes: Receive a request from another device in the first device group to prove the public key pair of the other device; and Provide the other device with proof from the private key of the other public key pair.

[0154] 16. A non-transitory computer-readable medium having program instructions stored thereon, the program instructions being executable by a computing system implementing a key authorization authority to cause the computing system to perform operations including: Receive a request to authorize the execution of a key exchange between the first device group and the second device group by the key authorization authority; The key authorization data structure is signed by the key authorization authority, and the key authorization data structure includes a first public key of a first participant authorization authority that identifies members of the first device group and a second public key of a second participant authorization authority that identifies members of the second device group; and The signature key authorization data structure is provided to the first participant organization and the second participant organization to authorize the execution of key exchange between members of the first device group and members of the second device group.

[0155] 17. The non-transitory computer-readable medium according to embodiment 16, wherein the key authorization data structure further includes key exchange information indicating a specific usage strategy of the devices participating in the key exchange.

[0156] 18. The non-transitory computer-readable medium according to embodiment 17, wherein the usage policy specifies that members of the first device group are permitted to transmit but not receive data objects from members of the second device group.

[0157] 19. The non-transitory computer-readable medium according to embodiment 16, wherein the operation further includes: The disaster recovery (DR) key pair is generated by the key authorization authority. Sign the DR proof data structure, which includes the public key of the DR key pair; and The key authorizing authority transmits the signed DR proof data structure and the 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 authorizing authority.

[0158] 20. The non-transitory computer-readable medium according to embodiment 16, wherein the operation further includes: The key authorization authority generates a second key authorization data structure, which authorizes the execution of key exchange among members of the first device group, the second device group, and the third device group, wherein the members of the third device group are identified by a third participant authorization authority; and The second key authorization data structure is provided to the first participant institution, the second participant institution, and the third participant institution.

Claims

1. A computing device, the computing device comprising: processor; A memory accessible to the processor and containing program instructions stored therein, which the processor can execute to: Request to perform key exchange to establish a shared secret with another device; and Cryptographic circuitry coupled to a secure memory inaccessible by the processor, wherein the cryptographic circuitry is configured to: Performing the key exchange includes deriving the shared secret using private key material maintained in the secure storage.

2. The computing device according to claim 1, further comprising: 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 according to claim 1, wherein the cryptographic circuit is configured as follows: The key exchange is performed by executing a sequence of program instructions in a specific order; and Out-of-order execution of the sequence is prevented by clearing a portion of the security 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 performing the key exchange comprises: The cryptographic circuit verifies a key authorization data structure received from a key authorization authority to indicate that the computing device is authorized to participate in key exchange with the other device, 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 authorization for key exchange between the first device group and the second device group; The public key associated with the computing device belongs to a first participant authorization authority 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 authority that is authorized to identify the other device as a member of the second device group.

6. The computing device of claim 4, wherein the program instructions are executable by the processor to: In response to the issuance of the key authorization data structure, a disaster recovery (DR) key pair generated by the key authorization authority is received; and In response to the subsequent revocation of the key authority, another key authority is established using the DR key pair.

7. The computing device of claim 4, wherein the private key material comprises a public key pair using private key proof of one of the public keys in the key authorization data structure; and The process of deriving the shared secret includes: The private key material is used to perform elliptic curve Diffie-Hellman (ECDH).

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

9. The computing device of claim 1, wherein the program instructions are executable by the processor to: Exchange authentication credentials encrypted with the exported shared secret with the other device.

10. The computing device of claim 1, wherein the program instructions are executable by the processor to: Exchange with the other device the exported shared secret encrypted transaction credentials.

11. The computing device according to 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 as follows: A random value is provided to the cryptographic circuit for use as part of the private key material stored in the secure memory.

12. The computing device according to claim 1, further comprising: A fuse library coupled to the cryptographic circuit and inaccessible by the processor, wherein the fuse library is configured to store key material during the manufacture of the cryptographic circuit, the key material being usable by the cryptographic circuit to derive a portion of the private key material 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 thereon, the program instructions being executable by a computing device to cause the computing device to perform operations including: The processor of the computing device requests a key exchange to establish a shared secret with another device; and The cryptographic circuitry of the computing device performs the key exchange, including deriving the shared secret using private key material maintained in a secure memory coupled to the cryptographic circuitry and inaccessible to the processor.

15. The computer-readable medium of claim 14, wherein the computer-readable medium comprises: A read-only memory (ROM) having program instructions stored therein, which can be executed by the cryptographic circuit to perform the key exchange.

16. The computer-readable medium of claim 14, wherein the operation further comprises: Whether the key exchange was authorized is determined by verifying multiple proofs associated with the public key pair exchanged during the key exchange.

17. The computer-readable medium of claim 16, wherein the plurality of evidences includes: The first key proof identifies the public key of the computing device as a member corresponding to the first device group; and The second key proof identifies the public key of the other device as a member corresponding to the second device group.

18. The computer-readable medium of claim 17, wherein the plurality of evidences includes: Key authorization, wherein the key authorization identifier is: 1) identifying the public key of the computing device as the first public key of the first participant authorization authority corresponding to a member of the first device group; and 2) identifying the public key of the other device as the second public key of the second participant authorization authority corresponding to a member of the second device group.

19. The computer-readable medium of claim 18, wherein the key authorization further identifies a flag restricting the operation of the computing device and the other device.

20. A non-transitory computer-readable storage medium having stored thereon design information specifying at least a portion of a design of a hardware integrated circuit in a format recognizable by a semiconductor manufacturing system, the semiconductor manufacturing system being configured to use the design information to manufacture the integrated circuit according to the design, wherein the design information specifying the integrated circuit includes: processor; A memory accessible to the processor and containing program instructions stored therein, which the processor can execute to: Request to perform key exchange to establish a shared secret with another device; and Cryptographic circuitry coupled to a secure memory inaccessible by the processor, wherein the cryptographic circuitry is configured to: Performing the key exchange includes deriving the shared secret using private key material maintained in the secure storage.

Images