Patent Description:
Embodiments discussed herein relate to a cryptographic key management system, that includes processing circuitry to perform cryptographic processing and a plurality of cryptographic key registers. The plurality of cryptographic key registers includes at least a first cryptographic key register. The plurality of cryptographic key registers each include a cryptographic key portion to store a cryptographic key and attribute portion to store attribute indicators that are associated with (and/or inseparable from), the corresponding cryptographic key stored in the cryptographic key portions. The first cryptographic key register includes a first cryptographic key portion to store the first cryptographic key and a first attribute portion to store a first set of attribute indicators associated with the first cryptographic key. An interface receives commands that control the processing circuitry to perform cryptographic processing based at least in part on the first cryptographic key and the first set of attribute indicators. The processing circuitry comprises an access and tamper resistant circuit block configured to prevent key values of keys stored within the access and tamper resistant circuit block from being exposed outside of the access and tamper resistant circuit block, and to prevent any modification of the attribute portions after key generation.

In another embodiment, a method for deriving a cryptographic key includes receiving a first cryptographic key and receiving an indicator of an intended use for a derived key. The derived key is generated based on the first cryptographic key, one or more attribute values of the first cryptographic key that each indicate an allowable key derivation operation for the first cryptographic key, and the indicator of the intended use. The method is implemented in an access and tamper resistant circuit block configured to prevent key values of keys stored within the access and tamper resistant circuit block from being exposed outside of the access and tamper resistant circuit block, and to prevent any modification of the attribute portions after key generation.

In order to describe the manner in which the above-recited and other advantages and features can be obtained, a more particular description is set forth and will be rendered by reference to specific examples thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical examples and are not therefore to be considered to be limiting of its scope, implementations will be described and explained with additional specificity and detail through the use of the accompanying drawings.

Examples are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the subject matter of this disclosure. The implementations may be a machine-implemented method, a computing device, or included in an integrated circuit.

In an embodiment, a set of cryptographic keys and an associated set of attributes (key attributes) are stored within an access and tamper resistant (ATR) circuit block. Operations on these keys is provided only through a limited function hardware interface such that the key values themselves are never exposed outside of the ATR circuit block. In addition, the operations that can be performed on these keys is determined by the key attributes, and such operations can only be performed by the ATR circuit block. The key attributes can only be modified/set by the ATR block at key generation or derivation time - thereby preventing software access to the keys and limiting unintended usage or conversion of the keys (e.g., to a new use) via software.

<FIG> is a block diagram of a cryptographic key management system with key attributes. In <FIG>, cryptographic key management system <NUM> comprises access and tamper resistant (ATR) circuitry <NUM>, exposed circuitry <NUM>, and interface <NUM>. Interface <NUM> in the only information bridge between exposed circuitry <NUM> and ATR circuitry <NUM>. Thus, all access to pass commands, data, and/or results to or from ATC circuitry <NUM> passes through interface <NUM>.

ATR circuitry <NUM> includes cryptographic processing circuitry <NUM>, nonvolatile memory <NUM>, volatile memory <NUM>, cryptographic key registers <NUM>, and platform configuration registers (PCRs) <NUM>. Cryptographic key registers <NUM> includes N number of key registers <NUM>-<NUM>, where N is an integer. PCRs <NUM> include M number of PCR registers <NUM>-<NUM>, where M is an integer. Each key register <NUM>-<NUM> includes two portions: a key portion 131a-135a and an attribute portion 131b-135b, respectively. Each PCR register <NUM>-<NUM> is initialized to a unique, among other PCR registers <NUM>-<NUM>, initial value <NUM>-<NUM>, respectively.

ATR circuitry <NUM> uses key registers <NUM> to hold cryptographic keys in key portions 131a-135a and associated key attributes in attribute portions 131b-135b. PCRs <NUM> hold measurements. The N number of key registers <NUM>, (a. , key slots) and M number of PCRs <NUM> in ATR circuitry <NUM> is implementation defined. In an embodiment, a minimum of <NUM> key registers and <NUM> PCRs are defined. Each key portion 131a-135a may be, for example, <NUM> bits wide. Each attribute portion may be, for example, extra <NUM> bits wide. PCR registers <NUM> may be, for example, <NUM> bits wide. The key stored in a key register may be, for example, an Advanced Encryption Standard (AES) key (either <NUM>, <NUM> or <NUM>-bit), or an Elliptic-curve cryptography (ECC) private key (e.g., an ECC key that conforms to the NIST P-<NUM> - or other standardized/unstandardized ECC curves. ) The type of key held in a key register <NUM>-<NUM> is specified by the values in its attribute portion 131b-135b. The values in the attribute portions 131b-135b also control what type of operation can be performed on, or by, the key stored in the associated key portion 131a-135a.

These operations include, for example, the ability to performing AES encryption / decryption using the stored key, the applying a Key Derivation Function (KDF) to the stored key to derive another stored key, and using the stored key to decrypt and "load" a cryptographic key blob containing a key and associated attribute into another key register <NUM>-<NUM>. The combination of KDF and load operations, for example, enables a chain of cryptographic keys to be distributed. These operations enable, for example, the ability to distribute keys from servers (such as Xbox LIVE™) to client devices including cryptographic key management system <NUM>. These distributed keys may be used, for example, to decrypt games, music, movies, etc., as well as other useful applications, without exposing the unencrypted version of these key outside of ATC circuitry <NUM>.

In an embodiment, attribute portions 131b-135b of key registers <NUM> are <NUM> bits wide. The values in attribute portions (a. attribute fields) 131b-135b define the operations that processing circuitry <NUM> can perform on, or using, the key stored in the associated key portion (a. key field) 131a-135a. Processing circuitry <NUM> maintains the association between the key and its associated attributes such that the attributes follow the key and are not changed outside of ATR circuitry <NUM>. Accordingly, the rules for setting the attributes is enforced by ATR circuitry <NUM>. In an embodiment, however, attribute values may be read by exposed circuitry, via interface <NUM>, in unencrypted form.

ATR circuitry <NUM>, and processing circuitry <NUM>, in particular, may perform various cryptographic operations using keys stored in key portions 131a-135a and corresponding attributes stored in attribute portions 131b-135b. Some example operations are notionally illustrated in <FIG>. In <FIG>, ATR circuitry <NUM> includes key register <NUM>. Key register <NUM> includes key portion 231a and attribute portion 231b. Attribute portion 231b comprises N bits of storage 231b-<NUM> to 231b-<NUM>. Processing circuitry <NUM> may access and read key portion 231a to read and write a key <NUM>. Processing circuitry <NUM> may access and attribute portion <NUM> to read and write one or more attributes (a. , attribute indicators) <NUM>.

As illustrated notionally in <FIG>, exposed circuitry <NUM> may provide one or more commands 295a (a. , instructions) and/or data 296a to interface <NUM>. Interface <NUM> may provide the one or more commands 296a and/or data 296a to processing circuit <NUM> of ATR circuitry <NUM>. Processing circuitry <NUM> may, based on one or more commands 295a and/or data 296a received from exposed circuitry <NUM> perform cryptographic operations based (at least in part) on key <NUM> and attributes <NUM>. Processing circuitry may also provide the results (e.g., success, fail, encrypted cryptographic key blob, etc.) of commands 295a to exposed circuitry <NUM> via interface <NUM>.

In an embodiment, the key portions 131a-135a of key registers <NUM> are not writable in response to commands received via interface <NUM> without also writing the corresponding attribute portion. This is illustrated notionally in <FIG>. In <FIG>, one or more commands 295a (and optionally associated data 296b) is provided to interface <NUM> for provision to processing circuitry <NUM>. In response, processing circuitry <NUM> creates key register write value <NUM>. Key register write value <NUM>, which includes both a key value and a complete set of associated attributes is written to key register <NUM>.

In an embodiment, the key portions of 131a-135a of key registers <NUM> are not readable, in response to commands received via interface <NUM>, in unencrypted form. However, the attribute portions131b-135b of the cryptographic key registers <NUM> are readable, in unencrypted form, via interface <NUM> in response to commands received via the interface. This is illustrated notionally in <FIG>. In <FIG>, one or more commands 295c are provided to interface <NUM> for provision to processing circuitry <NUM>. In response, processing circuitry <NUM> read key <NUM> and attributes <NUM> from key register <NUM>. Processing circuitry <NUM> may provide an encrypted form <NUM> of cryptographic key <NUM> to interface <NUM> for provision to exposed circuitry <NUM>. In an embodiment, encrypted form <NUM> may be generated by encrypting key <NUM> with some other key that is unique to this ATR <NUM>. In another embodiment, encrypted form <NUM> may be generated by encrypting key <NUM> along with attributes <NUM> and/or other information (e.g., a salt value. ) The encryption key for generating encrypted form <NUM> may be obtained from a key register (e.g., one of key registers <NUM>-<NUM>. ) Processing circuitry <NUM> may provide unencrypted form of attribute <NUM> to interface <NUM> for provision to exposed circuitry <NUM>. Note that the key used to encrypt <NUM> should be unique to ATR <NUM> and not available to exposed circuitry <NUM>. If the key was set by exposed circuitry <NUM> and available to exposed circuitry <NUM>, then exposed circuitry <NUM> would be able to decrypt <NUM> back to <NUM> which defeats the ability to keep keys in ATR <NUM> secret.

In an embodiment, based on one or more commands received via interface <NUM>, a randomly generated cryptographic key and an associated set of attributes may be written to a cryptographic key register <NUM>-<NUM> where the randomly generated cryptographic key is generated by processing circuitry <NUM>. This is illustrated notionally in <FIG>. In <FIG>, one or more commands 295d are provided to interface <NUM> for provision to processing circuitry <NUM>. In response, processing circuitry <NUM> creates a random key <NUM> using random number generator circuitry <NUM>. Random key <NUM> and an associated set of attributes <NUM> (e.g., provided at least in part by a command 295d) are combined into a key register write value <NUM> that is written to key register <NUM>.

In an embodiment, based on one or more commands received via interface <NUM>, a randomly generated cryptographic key having an attribute that indicates the randomly generated cryptographic key is statistically unique among other cryptographic key management systems may be written to a cryptographic key register <NUM>-<NUM>. This is illustrated notionally in <FIG>. In <FIG>, one or more commands 295e are provided to interface <NUM> for provision to processing circuitry <NUM>. In response, processing circuitry <NUM> creates a random key <NUM> using random number generator circuitry <NUM> and may set one or more attributes to indicate the key is unique. Random key <NUM> and the unique attribute indicator <NUM> are combined into a key register write value <NUM> that is written to key register <NUM>. The statistical uniqueness of key <NUM> does not guarantee absolute uniqueness. However, because key <NUM> is based on very large pool of potential key values (e.g., <NUM><NUM> possible values), chances of two keys having the same value is very small thus making each key, for practical purposes, unique. In an embodiment, generated random keys (e.g., key <NUM>) may be only known within the hardware instance of ATR <NUM> that generated them and never outside (e.g., by exposed circuitry <NUM>.

In an embodiment, based on one or more commands received via interface <NUM>, a derived cryptographic key and an associated set of attributes are written to a cryptographic key register (e.g., key register <NUM>) where the derived cryptographic key is generated by the processing circuitry <NUM> based at least in part on a first cryptographic key stored in another cryptographic key register (e.g., key register <NUM>). This is illustrated notionally in <FIG>. In <FIG>, one or more commands 295f are provided to interface <NUM> for provision to processing circuitry <NUM>. In response, processing circuitry <NUM> reads the contents <NUM> (both key and attribute portions) of key register <NUM>. Processing circuitry <NUM> then, based on contents <NUM> (e.g., key portion 231a alone, or key portion 231a along with attribute portion 231b) derives a key <NUM> using key derivation function circuitry <NUM>. Key derivation circuitry <NUM> may derive key <NUM> based on key portion 231a and new attributes <NUM>. Derived key <NUM> and its associated set of attributes <NUM> are combined into a key register write value <NUM> that is written to key register <NUM>. In an embodiment, the attributes <NUM> that are associated with derived key <NUM> are based at least in part on the attributes from contents <NUM>. In an embodiment, the attributes <NUM> that are associated with derived key <NUM> are based at least in part on attributes provided by a command 295f. In an embodiment, one or more indicators from attribute portion 231b may determine whether processing circuitry <NUM> will perform the key derivation operation specified by command 295f.

In an embodiment, based on one or more commands received via interface <NUM>, a cryptographic key and associated set of attributes from an encrypted cryptographic data block are decrypted using a cryptographic key stored in a cryptographic register (e.g., key register <NUM>) and written to another (or the same) key register (e.g., key register <NUM>). This is illustrated notionally in <FIG>. In <FIG>, one or more commands <NUM> and an encrypted cryptographic data block <NUM> are provided to interface <NUM> for provision to processing circuitry <NUM>. Encrypted cryptographic data block <NUM> includes an encrypted version of cryptographic key <NUM> and attributes <NUM>. In response to command(s) <NUM>, processing circuitry <NUM> reads the contents <NUM> (both key and attribute portions) of key register <NUM>. Processing circuitry <NUM> then, based on contents <NUM> (e.g., key portion 231a alone, or key portion 231a along with attribute portion 231b) decrypts encrypted data block <NUM> using key decryption circuitry <NUM>. Key decryption circuitry provides unencrypted key <NUM> and unencrypted attributes <NUM> to processing circuitry <NUM>. Key <NUM> and its associated set of attributes <NUM> are combined into a key register write value <NUM> that is written to key register <NUM>. In an embodiment, processing circuitry <NUM> ensures that the attributes <NUM>, as written to key register <NUM>, cannot specify that key <NUM> is unique among other cryptographic key management systems. Processing circuitry <NUM> may ensure that the attributes <NUM>, as written to key register <NUM>, do not specify that key <NUM> is unique among other cryptographic key management systems based on key <NUM> being provided from exposed circuitry <NUM> (as opposed to being internally generated by ATR circuitry <NUM>. ) In an embodiment, one or more indicators from attribute portion 231b may determine whether processing circuitry <NUM> will perform the key derivation operation specified by command <NUM>.

ATR circuitry <NUM> includes PCRs <NUM>. The values stored in PCRs <NUM> are generated by circuity internal to ATR circuitry <NUM> in response to command received via interface <NUM>. These internally generated PCR values stored in PCRs <NUM> are readable via interface <NUM> in response to commands received via interface <NUM>. However, the values stored in PCRs <NUM> are not writable with values received via interface <NUM> (i.e., values from exposed circuitry <NUM>. ) This is illustrated notionally in <FIG> and <FIG>.

In <FIG>, one or more commands <NUM> (and associated data <NUM> - e.g., an extend value) are provided to interface <NUM> for provision to processing circuitry <NUM>. In response, processing circuitry <NUM> reads the contents <NUM> of PCR register <NUM>. Using PCR value generation circuitry <NUM>, processing circuitry generates a new PCR value <NUM> based on the value <NUM> read from PCR register <NUM> and optionally also based on data <NUM> received via interface <NUM>. In an embodiment, PCR value generation circuitry <NUM> generates the new value <NUM> to be written to PCR <NUM> using a Secure Hash Algorithm (e.g., SHA-<NUM>, SHA-<NUM>, etc.) PCR value generation circuitry <NUM> may generates the new value <NUM> to be written to PCR <NUM> by hashing a concatenation of the current value <NUM> of PCR <NUM> and data <NUM>. The new value <NUM> is written to PCR <NUM>. In an embodiment, one or more indicators from attribute portion 231b may determine whether processing circuitry <NUM> will perform the key derivation operation specified by command <NUM>.

In <FIG>, one or more commands <NUM> are provided to interface <NUM> for provision to processing circuitry <NUM> in an attempt to write a value <NUM> to PCR <NUM>. Processing circuitry <NUM> blocks this attempt (illustrated by <NUM>).

In an embodiment, based on one or more commands received via interface <NUM>, a derived cryptographic key and an associated set of attributes are written to a cryptographic key register (e.g., key register <NUM>) where the derived cryptographic key is generated by the processing circuitry <NUM> based at least in part on a first cryptographic key stored in another cryptographic key register (e.g., key register <NUM>) and based on a value in a platform configuration register (e.g., PCR <NUM>). This is illustrated notionally in <FIG>. In <FIG>, one or more commands 295j (and optionally data 296j) are provided to interface <NUM> for provision to processing circuitry <NUM>. In response, processing circuitry <NUM> reads the contents <NUM> (both key and attribute portions) of key register <NUM>. Processing circuitry <NUM> also reads the contents <NUM> of PCR register <NUM>. Processing circuitry <NUM> then, based on contents <NUM> (e.g., key portion 231a alone, or key portion 231a along with attribute portion 231b) and contents <NUM>, derives a key <NUM> using key derivation function circuitry <NUM>. In an embodiment, key derivation circuitry <NUM> may derive key <NUM> based on contents <NUM> along with contents <NUM> alone (e.g., key portion 231a alone, or key portion 231a along with attribute portion 231b). In another embodiment, key derivation circuitry <NUM> may derive key <NUM> based on contents <NUM> along with contents <NUM> (e.g., key portion 231a alone, or key portion 231a along with attribute portion 231b) and new attributes <NUM>. Derived key <NUM> and its associated set of attributes <NUM> are combined into a key register write value <NUM> that is written to key register <NUM>. In an embodiment, the attributes <NUM> that are associated with derived key <NUM> are based at least in part on the attributes from contents <NUM>. In an embodiment, one or more indicators from attribute portion 231b may determine whether processing circuitry <NUM> will perform the key derivation operation specified by command <NUM>.

The following gives a set of example operations that may be performed by ATR circuitry <NUM>:.

As described herein, attribute indicators stored in attribute portions 131b-135b may affect, or prevent, operations that processing circuitry <NUM> performs on, or using, the keys stored in respective key portions 131a-135a. Figure 3A-<NUM> are notional diagrams of key attributes affecting operations that may be securely performed by cryptographic key management system <NUM>.

In an embodiment, the attribute indicators stored attribute portions <NUM>-b-135b determine a respective subset of operations that processing circuitry <NUM> is allowed to perform using the associated cryptographic key values stored in the corresponding cryptographic key portions 131a-135a. This is illustrated notionally in <FIG>. In <FIG>, the contents of key register <NUM> are read inside of ATR <NUM>. These contents include a key 341a and attributes 351a. Attributes 351a may allow or disallow certain operations by processing circuitry <NUM>. This is illustrated in <FIG> by the arrows running from attributes 351a to key operations <NUM>-<NUM> inside processing circuitry <NUM>. The "X" on the arrow running from attributes 351a to key operation #<NUM><NUM> illustrates the disallowance of key operation by attributes 351a. The lack of an "X" on the arrows between attributes 351a and key operation <NUM> and key operation <NUM> illustrate the allowance of key operation <NUM> and <NUM>.

In an embodiment, the attribute indicators stored attribute portions 131b-135b correspond to an intended use of the key values stored in the corresponding cryptographic key portions 131a-135a. This intended use may determine a respective subset of operations that processing circuitry <NUM> is allowed to perform using the associated cryptographic key values stored in the corresponding cryptographic key portions 131a-135a. This is illustrated notionally in <FIG>. In <FIG>, the contents of key register 331b are read inside of ATR <NUM>. These contents include a key 341b and attributes 351b. Attributes 351b include a use 352b. Attributes 351b, and use indicator 352b may allow or disallow certain operations by processing circuitry <NUM>. This is illustrated in <FIG> by the arrows running from use indicator 352b to key operations <NUM>-<NUM> inside processing circuitry <NUM>. The "X" on the arrow running from use indicator 352b to key operation #<NUM><NUM> illustrates the disallowance of key operation by use indicator 352b. The lack of an "X" on the arrows between use indicator 352b and key operation <NUM> and key operation <NUM> illustrate the allowance of key operation <NUM> and <NUM> by use indicator 352b.

In an embodiment, one or more attribute indicators that indicate an intended use of the corresponding cryptographic key is determined in response to commands received via interface <NUM> that instruct processing circuitry <NUM> to calculate a corresponding cryptographic key. This is illustrated notionally in <FIG>. In <FIG>, one or more commands 395c that include information 396c about an intended use for the generated key are provided to interface <NUM> for provision to processing circuitry <NUM>. In response, processing circuitry <NUM> generates a key 341c using key generator circuitry <NUM> and also sets one or more use attributes 352c to indicate an intended use. Generated key 341c and attributes 351c with use attributes 352c are combined into a key register write value 361c that is written to key register <NUM>.

In an embodiment, based on one or more commands received via interface <NUM>, a cryptographic key is exported via interface <NUM> in an encrypted form where the encrypted block holding the cryptographic key is generated based on both cryptographic key being exported and at least one attribute indicator. In an embodiment, the encrypted block holding the cryptographic key is generated based on both cryptographic key being exported and all of the attribute indicators. This operation is illustrated notionally in <FIG>. In <FIG>, contents 361d (which includes key 341d and attributes 351d) of key register <NUM> are provided to encryption circuitry <NUM> of processing circuitry <NUM>. Encryption circuitry <NUM> generates an encrypted version 391d of key 341d based on both key 341d and attributes 351d. Encrypted version 341d is provided to interface <NUM> for export to exposed circuitry <NUM>.

In an embodiment, a unique identity of cryptographic management system <NUM> may be established using cryptographic operations that are based on at least a cryptographic key stored in a key register <NUM>-<NUM> and associated attributes. This is illustrated notionally in <FIG>. In <FIG>, one or more commands 395e are provided to interface <NUM> for provision to processing circuitry <NUM>. These commands <NUM> include commands <NUM> to establish the identity of ATR <NUM> using the key 341e and attributes 351e stored in key register <NUM>. In response, contents 361e (which includes key 341e and attributes 351e) of key register <NUM> are provided to identity check operation <NUM> of processing circuitry <NUM>. Identity check operation <NUM> processes key 341e, attributes 351e and information provided by check identity command <NUM> to provide a response, via interface <NUM>, that establishes the identity of ATR circuitry <NUM> to exposed circuitry <NUM>. An example embodiment of the identity check operation is to ECC Sign a check identity nonce <NUM> received in the command 395e. In such a case, key 341e may be an ECC private key that is used to perform the ECC Sign operation in block <NUM>. In order for exposed circuitry <NUM> to verify the identity of the ATR circuitry <NUM>, the corresponding ECC public key associated with 341e must be signed into some form of certificate during the manufacturing of ATR circuitry <NUM>. This enables the receiver of the check identity response (e.g., exposed circuitry <NUM>) to verify the ECC signature and confirm that it is talking to a valid ATR circuit <NUM>. Another requirement for check identity to work is that the ATR circuit <NUM> must be able to create the same key 361e on every boot cycle. Thus, ATR circuitry <NUM> uses at least one root key that is used to derive 361e. This at least one root key comes initially from nonvolatile storage (e.g., NVRAM or fuses) the ATR circuitry <NUM> starts up. This enables the same value for key 361e to be derived over all boot sessions.

An example set of key attribute bits is given in Table <NUM>.

<FIG> is a flowchart of a method of operating a cryptographic key management system with key attributes. The steps illustrated in <FIG> may be performed by one or more elements of cryptographic key management system <NUM>. By access and tamper resistant circuitry, a first encryption key is received (<NUM>). For example, key values stored in cryptographic key portions 131a-135a may be received by cryptographic key registers <NUM>-<NUM>. These key values may be generated by ATR <NUM>. These key values may be received via interface <NUM> from exposed circuitry <NUM>.

By the access and tamper resistant circuitry, an indicator of an intended use for a derived key that is based on the first cryptographic key is received (<NUM>). For example, attributes that are to be associated with a key derived from a key stored in key portion 131a may be based at least in part on the attributes read from the contents of the attributes in attribute portion 131b, where the attributes in attribute portion 131b indicate an intended use of the key stored in key portion 131a.

The derived key is generated based on the first cryptographic key and the indicator of the intended use (<NUM>). For example, processing circuitry <NUM> may, based on both the key value in key portion 131a and the attributes in attribute portion 131b, derives a key using key derivation function circuitry. This derived key and its associated set of attributes may be combined into a key register write value that is written to key register <NUM>. In an embodiment, the attributes that are associated with the derived key may be based at least in part on the attributes read from the attribute portion 131b. In an embodiment, the attributes that are associated with the derived key may be based at least in part on attributes received from exposed circuitry <NUM>.

<FIG> is a block diagram of a computer system. In an embodiment, computer system <NUM> and/or its components include circuits, software, and/or data that implement, or are used to implement, the methods, systems and/or devices illustrated in the Figures, the corresponding discussions of the Figures, and/or are otherwise taught herein.

Devices, circuits, and systems described herein may be implemented using computer-aided design tools available in the art, and embodied by computer-readable files containing software descriptions of such circuits. This includes, but is not limited to one or more elements of system <NUM>, and/or its components. These software descriptions may be: behavioral, register transfer, logic component, transistor, and layout geometry-level descriptions.

Data formats in which such descriptions may be implemented are stored on a non-transitory computer readable medium include, but are not limited to: formats supporting behavioral languages like C, formats supporting register transfer level (RTL) languages like Verilog and VHDL, formats supporting geometry description languages (such as GDSII, GDSIII, GDSIV, CIF, and MEBES), and other suitable formats and languages. Physical files may be implemented on non-transitory machine-readable media such as: <NUM> magnetic tape, <NUM> magnetic tape, <NUM>-<NUM>/<NUM>-inch floppy media, CDs, DVDs, hard disk drives, solid-state disk drives, solid-state memory, flash drives, and so on.

The functionally described herein can be performed, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs), Application-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), multi-core processors, graphics processing units (GPUs), etc..

<FIG> illustrates a block diagram of an example computer system. In an embodiment, computer system <NUM> and/or its components include circuits, software, and/or data that implement, or are used to implement, the methods, systems and/or devices illustrated in the Figures, the corresponding discussions of the Figures, and/or are otherwise taught herein.

Computer system <NUM> includes communication interface <NUM>, processing system <NUM>, storage system <NUM>, user interface <NUM>, and trusted platform module (TPM) <NUM>. ATR circuitry <NUM> may be included in TPM <NUM>. ATR circuitry <NUM> may be included in Processing system <NUM>. Processing system <NUM> is operatively coupled to storage system <NUM>. Storage system <NUM> stores software <NUM> and data <NUM>. Processing system <NUM> is operatively coupled to communication interface <NUM> and user interface <NUM>. Processing system <NUM> may be an example of processing system <NUM>, and/or its components.

Computer system <NUM> may comprise a programmed general-purpose computer. Computer system <NUM> may include a microprocessor. Computer system <NUM> may comprise programmable or special purpose circuitry. Computer system <NUM> may be distributed among multiple devices, processors, storage, and/or interfaces that together comprise elements <NUM>-<NUM>.

Communication interface <NUM> may comprise a network interface, modem, port, bus, link, transceiver, or other communication device. Communication interface <NUM> may be distributed among multiple communication devices. Processing system <NUM> may comprise a microprocessor, microcontroller, logic circuit, or other processing device. Processing system <NUM> may be distributed among multiple processing devices. User interface <NUM> may comprise a keyboard, mouse, voice recognition interface, microphone and speakers, graphical display, touch screen, or other type of user interface device. User interface <NUM> may be distributed among multiple interface devices. Storage system <NUM> may comprise a disk, tape, integrated circuit, RAM, ROM, EEPROM, flash memory, network storage, server, or other memory function. Storage system <NUM> may include computer readable medium. Storage system <NUM> may be distributed among multiple memory devices.

Processing system <NUM> retrieves and executes software <NUM> from storage system <NUM>. Processing system <NUM> may retrieve and store data <NUM>. Processing system <NUM> may also retrieve and store data via communication interface <NUM>. Processing system <NUM> may create or modify software <NUM> or data <NUM> to achieve a tangible result. Processing system may control communication interface <NUM> or user interface <NUM> to achieve a tangible result. Processing system <NUM> may retrieve and execute remotely stored software via communication interface <NUM>.

Software <NUM> and remotely stored software may comprise an operating system, utilities, drivers, networking software, and other software typically executed by a computer system. Software <NUM> may comprise an application program, applet, firmware, or other form of machine-readable processing instructions typically executed by a computer system. When executed by processing system <NUM>, software <NUM> or remotely stored software may direct computer system <NUM> to operate as described herein.

Claim 1:
A cryptographic key management system (<NUM>), comprising:
processing circuitry (<NUM>) to perform cryptographic processing based at least in part on a first cryptographic key;
a plurality of cryptographic key registers (<NUM>) within the access and tamper resistant circuit block, the plurality of cryptographic key registers (<NUM>) including cryptographic key portions to store cryptographic keys and attribute portions to store respective pluralities of attribute indicators that are associated with corresponding cryptographic keys stored in the cryptographic key portions, the plurality of cryptographic key registers (<NUM>) including a first cryptographic key register that includes a first cryptographic key portion to store the first cryptographic key and a first attribute portion to store a first set of attribute indicators associated with the first cryptographic key; and
an interface to receive commands that control the processing circuitry (<NUM>) to perform cryptographic processing based at least in part on the first cryptographic key and the first set of attribute indicators,
characterised in that the processing circuitry comprising an access and tamper resistant circuit block configured to prevent key values of keys stored within the access and tamper resistant circuit block from being exposed outside of the access and tamper resistant circuit block, the plurality of cryptographic key registers (<NUM>) are stored within the access and tamper resistant circuit block, and one or more attribute indicators of the first set of attribute indicators each indicates an allowable key derivation operation for the first cryptographic key, and wherein the access and tamper resistant circuit block is configured to prevent any modification of the attribute portions after key generation.