SECURE BOOT INFORMATION WITH VALIDATION CONTROL DATA SPECIFYING A VALIDATION TECHNIQUE

[0001] This application claims priority to U.S. provisional patent application No. 61/509,078, filed on Jul. 18, 2011, which is hereby incorporated by reference herein in its entirety.

[0002] A computing device, such as a device including a processor, may interact with secret or otherwise sensitive information during operation. As such, some computing devices may operate to protect the sensitive information. For example, a computing device may encrypt sensitive information using a security parameter, such as an encryption key, stored on the device. The computing device may also operate to protect the security parameter stored on the device.

[0009] As noted above, a computing device may operate to protect sensitive information using security parameters stored on the computing device. To protect both the sensitive information and the security parameters, an integrated circuit (IC) of a computing device may have multiple operating states that may each be utilized in different stages of the life cycle of the computing device. For example, when a computing device is being developed, tested, and/or initialized in a controlled environment, the IC may be operated in a clear state in which the IC provides little or no security for information stored on or utilized by the IC. For example, boot instructions executed by the IC in this clear state may be stored outside the processor in a cleartext (e.g., unencrypted, uncompressed, etc.) format.

[0010] When the computing device is operated in an environment in which it is vulnerable to security threats, the IC may be operated in a secure state in which the device may provide more security for information stored on or utilized by the IC than in the clear state. For example, secure boot information used to boot the computing device in the secure state may be stored outside of the IC in an encoded (e.g., encrypted) format to prevent an unauthorized party from determining the content of the information and tampering with the information to gain access to security parameters stored on the IC. Additionally, in response to a breach of the computing device's security, the IC may zeroize its security parameters and operate thereafter in a zeroize state in which the IC provides event reporting and diagnostic functionalities until the device is returned to the controlled environment.

[0011] To provide additional security for the secure state, an IC may perform an integrity check with a predefined validation technique to validate the integrity of the secure boot information stored outside of the IC prior to using the information (e.g., executing instructions). Different validation techniques provide different tradeoffs in complexity, speed, and security, so one validation technique may not be suitable or desirable for every context. For example, a fast, relatively simple validity check may be suitable for a computing device for which there is a relatively low risk of security threats. However, a more complex, more secure, slower validation technique may be desired for a computing device that, for example, is more vulnerable to security threats, that uses more sensitive information, etc. Additionally, a computing device may not meet certain security standards (e.g., government-imposed security standards) unless a particular validation technique is used.

[0012] To address these issues, in examples disclosed herein, an IC may verify the validity of secure boot information stored external to the IC by retrieving the secure boot information, determining a validation technique specified in the secure boot information, and verifying the integrity of the secure boot information with the specified validation technique. In such examples, the IC may be capable of using any one of a plurality of different validation techniques to validate the secure boot information. In this manner, examples disclosed herein may provide a single IC that may be used in a variety of contexts regardless of a desired validation technique. Additionally, by allowing a desired validation technique to be specified in the information to be validated, examples disclosed herein may provide much flexibility for the manner of validating information integrity. For example, as security threats or standards change, examples disclosed herein may allow the validation technique used by an IC to be readily changed by changing the validation technique specified in the information to be validated.

[0013] Referring now to the drawings. FIG. 1 is a block diagram of an example integrated circuit (IC) 100 to validate secure boot information with a validation technique specified in the secure boot information. In the example of FIG. 1, IC 100 includes a processor 110, a cryptography module 115, a machine-readable storage medium 120 including (e.g., encoded with) instructions 122, 124, 126, and 128. In some examples, storage medium 120 may include additional instructions. In other examples, instructions 122, 124, 126, 128, and any other instructions described herein in relation to storage medium 120 may be stored remotely from IC 100. In some examples, IC 100 may be included in a computing device. As used herein, a “computing device” may be a desktop or notebook computer, a tablet computer, a computer networking device (e.g., a hardware security module), a server, or any other device or equipment (e.g., an automated teller machine (ATM), etc.) including a processor.

[0014] As used herein, a “processor” may be electronic circuitry including at least one of a central processing unit (CPU), a graphics processing unit (GPU), a field-programmable gate array (FPGA) configured to retrieve and execute instructions stored on a machine-readable storage medium, other electronic circuitry suitable for the retrieval and execution of such instructions, or a combination thereof. Processor 110 may fetch, decode, and execute instructions stored on storage medium 120 to implement the functionalities described below. In other examples, the functionalities of any of the instructions of storage medium 120 may be implemented in the form of electronic circuitry, in the form of executable instructions encoded on a machine-readable storage medium, or a combination thereof.

[0015] Additionally, as used herein, a “machine-readable storage medium” may be any electronic, magnetic, optical, or other physical storage device to contain or store information such as executable instructions, data, and the like. For example, any machine-readable storage medium described herein may be any of Random Access Memory (RAM), flash memory, a storage drive (e.g., a hard disk), a Compact Disc Read Only Memory (CD-ROM), and the like, or a combination thereof. Further, any machine-readable storage medium described herein may be non-transitory.

[0016] In some examples, instructions 122 may retrieve, with processor 110, secure boot information 156 from external storage 155. In examples described herein, external storage 155 may be a machine-readable storage medium. In some examples, external storage 155 may be external to IC 100. In the example of FIG. 1, instructions 122 may cause processor 110 to retrieve secure boot information 156 via cryptography module 115 to decrypt secure boot information 156, which may be stored in an encrypted format in external storage 155. In some examples, instructions 122 may retrieve secure boot information 156 beginning at a secure reset vector. As used herein, a “reset vector” may be an address from which a processor may first retrieve information after undergoing a reset. In some examples, IC 100 may include multiple reset vectors. For example, a “secure reset vector” may be a reset vector used after a reset in a secure state, a “clear reset vector” may be a reset vector used after a reset in clear state, and a “zeroize reset vector” may be a reset vector used after a reset in zeroize state.

[0017] As used herein, a “cryptography module” is a module implementing at least one information formatting technique and that may reformat input information with any one of the formatting techniques. Example information formatting techniques that may be implemented by a cryptography module include, for example, encryption and/or decryption techniques, compression and/or decompression techniques, and any other information encoding and/or decoding techniques. In some examples, a cryptography module may implement a plurality of different formatting techniques and reformat input information with a selected one of the formatting techniques. Any cryptography module described herein may be implemented in the form of electronic circuitry, in the form of executable instructions encoded on a machine-readable storage medium, or a combination thereof.

[0018] Additionally, as used herein, “boot information” is information that may be used by a processor of a computing device to boot the computing device. In some examples, the boot information may include at least one of boot data (e.g., addresses and/or other information, etc.) and boot instructions. As used herein. “boot instructions” are a set of instructions that may be executed by a processor of a computing device to boot the computing device. Boot instructions may include, for example, instructions to test and/or configure components and/or functionalities of the computing device. In such examples, computing device components that may be tested and/or configured may include a processor, memory, a memory management unit, cryptographic functionalities, and the like, or a combination thereof. Also, as used herein, “secure boot information” may be boot information used to boot a computing device in a secure mode of operation. In some examples, secure boot information may include secure boot instructions, which may be boot instructions used to boot a computing device in a secure mode of operation.

[0019] In some examples, instructions 122, when executed, may cause processor 110 to provide at least one read request to external storage 155 (e.g., via an external bus controller) to retrieve secure boot information 156. In response to the at least one read request, external storage 155 may provide encrypted secure boot information 156 to cryptography module 115 (e.g. via the external bus controller). In such examples, cryptography module 115 may decrypt the encrypted secure boot information 156 to generate decrypted secure boot information 160, which may be in a cleartext format. In some examples, in response to the read request, a memory management unit may configure cryptography module 115 with cryptographic information corresponding to the memory region targeted in the read request, such as a cryptographic technique, a cryptographic key, or the like. In such examples, cryptography module 115 may use this cryptographic information to decrypt information read from storage 155. In some examples, cryptography module 115 may provide decrypted secure boot information 160 to an internal storage at which processor 110 may access secure boot information 160. In other examples, cryptography module 115 may provide decrypted secure boot information 160 to processor 110 without first providing the secure boot information 160 to internal storage. In such examples, processor 110 may store the received decrypted secure boot information 160 in internal storage (e.g., cache).

[0020] As used herein, information in a “cleartext” format for a given computing device is information that a processor of the computing device is able to execute or otherwise operate on without first reformatting (e.g., decrypting, decoding, etc.) the information. For example, instructions in a cleartext format may be instructions that the processor may execute without first reformatting the instructions. Information in a cleartext format may also be referred to herein as “decrypted” information. As used herein, information in an “encrypted” format for a given computing device is information in a format that a processor of the computing device may execute or otherwise operate on after the information is decrypted.

[0021] In the example of FIG. 1, secure boot information 160 may include validation control data 162, secure boot instructions 170, and validation data 168 for secure boot information 160. As used herein, “validation data” for a collection of information is data derived from the collection of information at a given point in time that may be used subsequently to determine whether the information (or a particular portion thereof) has changed since the generation of the validation data. In some examples, validation data for a collection of information may be, for example, a digest, a code, a hash, a digital signature, or the like, derived from at least a portion of the information. In some examples, validation control data 162 may be located at or near the beginning of secure boot information 160. In other examples, validation control data 162 may be located at any other location within secure boot information 160. Additionally, in the example of FIG. 1, validation data 168 is separate from validation control data 162. In some examples, validation data 168 may be located at or near the end of secure boot information 160. In other examples, validation data 168 may be located elsewhere in secure boot information 160. In other examples, validation control data 162 may include validation data 168. In some examples, encrypted secure boot information 156 may comprise secure boot information 160 in an encrypted format.

[0022] Storage medium 120 further comprises instructions 124 to determine, with any one of a plurality of different validation techniques, whether validation data 168 is consistent with the decrypted secure boot information 160. In such examples, instructions 124 may determine whether validation data 168 is consistent with secure boot information 160 using whichever of the plurality of validation techniques is specified in secure boot information 160. As used herein, a “validation technique” is a process for determining whether given validation data is consistent with a given collection of information. Additionally, as used herein, validation data “is consistent with” a collection of information for a given validation technique if test data derived from at least a portion of the information as part of the validation technique is equivalent to the validation data or data derived from the validation data as part of the validation technique.

[0023] In the example of FIG. 1, instructions 124 may utilize any one of a plurality of different validation techniques to determine whether validation data 168 is consistent with the decrypted secure boot information 160. In some examples, instructions 124 may include instructions to perform each of the plurality of different validation techniques. In other examples, instructions 124 may include instructions to utilize a cryptography module to perform each of the different validation techniques.

[0024] As used herein, validation techniques are “different” if they use different processes for determining whether validation data for a collection of information is consistent with the information. In some examples, validation techniques using different functions for deriving the test data from given information may be considered different validation techniques herein. For example, two hash validation techniques using different hash functions, respectively, to derive test data from a given set of information may be considered different validation techniques herein. Another example of different validation techniques may be an error-detection validation technique and a hash validating technique using different functions for deriving test data from a given collection of information. In other examples, validation techniques using different processes after deriving the test data may be considered different validation techniques herein. For example, a hash validation technique may determine that given validation data is consistent with given information if the validation data is equivalent to test data derived from the information using a hash function. However, a different digital signature validation technique may determine that the validation data is consistent with the given information if test data derived from the information is equivalent to other data derived by decrypting the validation data with a public key.

[0025] In the example of FIG. 1, instructions 126 may determine which of the plurality of different validation techniques is specified in validation control data 162 of secure boot information 160. For example, validation control data 162 may include a validation technique identifier 164. In such examples, instructions 126 may determine the specified validation technique of the plurality of validation techniques based on validation technique identifier 164.

[0026] In the example of FIG. 1, instructions 124 may determine whether validation data 168 is consistent with decrypted secure boot information 160 with the validation technique specified by identifier 164. In some examples, instructions 124 may determine, with the specified validation technique, whether validation data 168 is consistent with decrypted secure boot information 160 after all of secure boot information 156 is retrieved from external storage 155. In such examples, instructions 124 may cause test data to be derived from at least a portion of secure boot information 160 stored in internal memory of IC 100. In other examples, instructions 124 may determine, with the specified validation technique, whether validation data 168 is consistent with decrypted secure boot information 160 at least partially in parallel with retrieving secure boot information 156. For example, after retrieving and decrypting the portion of secure boot information 160 including validation control data 162, instructions 126 may determine the specified validation technique. In such examples, instructions 124 may begin deriving the test data from portions of secure boot information 160 output by cryptography module 115 before all of secure boot information 156 is retrieved from external storage 155. In such examples, instructions 124 may continue deriving the test data as the encrypted secure boot information 156 is retrieved and decrypted. In some examples, instructions 124 may derive the test data from information 160 output by cryptography module 115 before, after, or at least partially in parallel with information 160 being stored in internal storage of IC 100. In other examples, instructions 124 may derive the test data from information 160 output by cryptography module 115 before or at least partially in parallel with information 160 being encrypted again by cryptography module 115 and stored in other storage external to IC 100 (e.g., an external DRAM).

[0027] In some examples, instructions 128 may boot a computing device including IC 100 with secure boot instructions 170 if it is determined, with the validation technique specified by identifier 164 of control data 162, that validation data 168 is consistent with the decrypted secure boot information 160. As noted above, secure boot information 160 output by cryptography module 115 may be stored in internal storage (e.g., cache) of IC 100. In some examples, instructions 128 may boot the computing device with secure boot instructions 170 by causing processor 110 to jump to secure boot instructions 170 stored in the internal memory, or by otherwise transferring control to secure boot instructions 170 stored in the internal memory. In other examples, in response to determining that validation data 168 is consistent with secure boot information 160, instructions 128 may trigger the execution of secure boot instructions 170 stored in external storage 155. In such examples, instructions 128 may trigger the retrieval of at least secure boot instructions 170 via cryptography module 115 and the execution of the received secure boot instructions 170 without validating the retrieved information again. In other examples, instructions 128 may trigger the retrieval of at least secure boot instructions 170 stored in the other external storage (e.g., external DRAM) via cryptography module 115 and the execution of the received secure boot instructions 170 without validating the retrieved information again.

[0028] Examples described herein provide the ability to validate secure boot information using any one of a plurality of different validations techniques. In examples described herein, secure boot information retrieved from external storage may be validated using a validation technique specified in validation control data of the secure boot information. In this manner, examples disclosed herein may provide flexibility in the validation of information retrieved from external storage by implementing a plurality of different validation techniques and allowing a validation technique for validating a given collection of information to be specified in the information to be validated. In some examples, functionalities described herein in relation to FIG. 1 may be provided in combination with functionalities described herein in relation to any of FIGS. 2-5.

[0029] FIG. 2 is a block diagram of an example computing device 201 comprising an IC 200 to determine a validation technique specified in secure boot information. In the example of FIG. 2, IC 200 may include a processor 110, a cryptography module 115, and a machine-readable storage medium 120, as described above in relation to FIG. 1. Storage medium 120 may include instructions 232, 234, 236, and 225, in addition to instructions 122, 124, 126, and 128 described above in relation to FIG. 1. IC 200 may also include internal storage 216, which may be a machine-readable storage medium. In addition to IC 200, computing device 201 may also include external storage 155, as described above in relation to FIG. 1. In other examples, external storage 155 may be remote from IC 200 and computing device 201.

[0030] In the example of FIG. 2, instructions 122, when executed, may cause processor 110 to retrieve secure boot information 156 from external storage 155 via cryptography module 115 to decrypt secure boot instructions 156 to generate decrypted secure boot information 160, as described above in relation to FIG. 1. In the example of FIG. 2, cryptography module 160 may store decrypted secure boot information 160 in internal storage 216. In such examples, processor 110 may access decrypted secure boot information 160 stored in internal storage 216.

[0031] In the example of FIG. 2, instructions 124 may determine whether validation data 168 of secure boot information 160 is consistent with secure boot information 160 with any one of a plurality of different validation techniques, as described above in relation to FIG. 1. In some examples, instructions 124 may derive test data from at least a portion of secure boot information 160 in accordance with the specified validation technique and determine whether the derived test data is equivalent to validation data 168 or data derived from validation data 168 as part of the specified validation technique.

[0032] In the example of FIG. 2, validation control data 162 may include a validation length 266. In such examples, instructions 124 may comprise instructions to derive the test data from a portion of decrypted secure boot information 160 having a length equal to validation length 266. For example, if instructions 124 derive the test data from information 160 using a hashing function, then instructions 124 may derive the test data by performing the hashing function on a portion of information 160 having a length equal to validation length 266, such as the first portion of information 160 having validation length 266. In other examples, the test data may be derived from the entire length of information 160, excluding validation data 168, for example.

[0033] In some examples, validation control data 162 may also include at least one validation parameter 267 for the validation technique specified by validation technique identifier 164. Validation parameters 267 may include, for example, at least one of an initialization value for a process for deriving test data from secure boot information (e.g. a cyclic redundancy check (CRC) technique), a public key used in a digital signature validation technique, the length of the public key, an indication of whether the public key is included in validation control data 162, and any other parameters that may be used by the validation technique specified by identifier 164. In examples in which the public key is not included in validation control data 162, the public key may be stored in IC 200.

[0034] In the example of FIG. 2, instructions 124 may include instructions to perform each of the plurality of different validation techniques to determine whether validation data 168 of secure boot information 160 is consistent with secure boot information 160. In some examples, instructions 124 may include instructions 232 to determine, with an error-detection validation technique, whether validation data 168 is consistent with decrypted secure boot information 160. In examples described herein, an error-detection validation technique may be a validation technique in which the test data is derived from a given collection of information by an error-detection process, such as a checksum process, a cyclic redundancy check (CRC) process, or any other suitable error-detection process. In such examples, an error-detection validation technique may determine that given validation data is consistent with the given information if the test data derived with the error-detection process is equivalent to the validation data. In some examples, instructions 232 may include a plurality of different error-detection validation techniques, each deriving the test data with a different error-detection process.

[0035] Instructions 124 may also include instructions 234 to determine, with a hashing validation technique, whether validation data 168 is consistent with decrypted secure boot information 160. In examples described herein, a hashing validation technique may be a validation technique in which the test data is derived from a given collection of information by performing a hash function on (i.e., hashing) at least a portion of the information. In such examples, a hashing validation technique may determine that given validation data is consistent with the given information if the test data derived by performing the hash function on the given information is equivalent to the validation data. In some examples, instructions 234 may include a plurality of different hashing validation techniques, each deriving the test data with a different hash function. Example hash functions may include, for example, cryptographic hash functions (e.g., SHA-256, SHA-512, etc.), non-cryptographic hash functions (e.g., FNV hash, etc.), or any other hash function.

[0036] Additionally, instructions 124 may include instructions 236 to determine, with a digital signature validation technique, whether validation data 168 is consistent with decrypted secure boot information 160. In examples described herein, a digital signature validation technique may be a validation technique in which test data is derived from given information by hashing at least a portion of the information and decrypted data is derived from given validation data by decrypting the validation data. In such examples, a digital signature validation technique may determine that the given validation data is consistent with the given information if the test data is equivalent to the decrypted data derived from the validation data. In some examples, instructions 236 may include a plurality of different digital signature validation techniques, each differing in at least one of a hash function for deriving test data, a decryption process, etc. Example digital signature validation techniques may include techniques based on, for example, an RSA/PKCS based technique, a federal information processing standard (FIPS) digital signature algorithm (DSA), a elliptic curve digital signature algorithm (ECDSA), an Elgamal signature technique, or any other digital signature technique.

[0037] In the example of FIG. 2, instructions 126 may determine which of the plurality of different validation techniques is specified by validation technique identifier 164 of validation control data 162 of secure boot information 160, as described above in relation to FIG. 1. In some examples, validation control data 162 may be located at any location within secure boot information 160. In such examples, secure boot information 160 may include a control data flag 261 in addition to validation control data 162, secure boot instructions 170, and validation data 168, as described above in relation to FIG. 1. Control data flag 261 may be any information indicating the location of validation control data 162 in decrypted secure boot information 160. For example, control data flag 261 may be a particular bit-mask, data pattern, or other information reserved for flag 261 and known by instructions 225. In such examples, instructions 225 may identify control data flag 261 in decrypted secure boot information 160 output from module 115.

[0038] In some examples, instructions 225 may use the location of flag 261 to determine the location of validation control data 162. For example, secure boot information 160 may be organized such that validation control data 162 directly follows flag 261 in secure boot information 160 or is located at another predefined location relative to flag 261 within information 160. In such examples, after instructions 225 identify the location of validation control techniques, instructions 126 may determine which of the plurality of different validation techniques is specified by validation technique identifier 164 of validation control data 162, as described above in relation to FIG. 1.

[0039] In other examples, secure boot information 160 may be organized such that validation control data 162 has a constant location in secure boot information 160. In such examples, flag 261 and instructions 225 may be omitted, and instructions 126 may look to the constant location within secure boot information 160 to find validation control data 162. For example, validation control data 162 may be located at a predefined offset within secure boot information 160. In such examples, instructions 126 may determine the specified validation technique from the validation technique identifier 164 of the validation control data 162 at the constant location within secure boot information 160. For example, validation control data 162 may start at a first location of secure boot information 160, or any other location in secure boot information 160.

[0040] In the example of FIG. 2, after instructions 126 determine the validation technique specified in validation control data 162, instructions 124 may determine whether validation data 168 is consistent with secure boot information 160 using whichever of the plurality of the validation techniques is specified by validation technique identifier 164 of validation control data 162. In some examples, instructions 124 may determine, with the specified validation technique, whether validation data 168 is consistent with decrypted secure boot information 160 at least partially in parallel with retrieving secure boot information 156, as described above in relation to FIG. 1. If instructions 124 determine that validation data 168 is not consistent with secure boot information 160, then instructions 124 may output an alarm and not boot computing device 201. The alarm may be output by instructions 124 on at least one status indicator (e.g., lights) of computing device 201 connected to IC 200.

[0041] In some examples, instructions 128 may boot computing device 201 with secure boot instructions 170 if it is determined, with the validation technique specified by identifier 164, that validation data 168 is consistent with decrypted secure boot information 160, as described above in relation to FIG. 1. In some examples, instructions 128 may trigger execution of secure boot instructions 170 by processor 110 if validation data 168 is determined to be consistent with information 160. In the example of FIG. 2, secure boot information 160 may be stored in internal storage 216. In such examples, instructions 128 may boot computing device 201 with instructions 170 by triggering execution, by processor 110, of secure boot instructions 170 stored on internal storage 216 if validation data 168 is consistent with decrypted secure boot information 160. In such examples, instructions 128 may cause processor 110 to jump to instructions 170 on internal storage 216, or otherwise transfer control to instructions 170. In other examples, instructions 128 may cause processor 110 to retrieve and execute instructions 170 from external storage 155 if validation data 168 is consistent with decrypted secure boot information 160. In other examples, secure boot information stored in internal storage 216 may be encrypted again by cryptography module 115 and stored in other storage external to IC 100, such as an external DRAM, if validation data 168 is consistent with decrypted secure boot information 160. In such examples, instructions 128 may cause processor 110 to retrieve and execute instructions 170 from the other external storage (e.g., external DRAM). In some examples, functionalities described herein in relation to FIGS. 1-2 may be provided in combination with functionalities described herein in relation to any of FIGS. 3-5.

[0042] FIG. 3 is a block diagram of an example computing system 395 including an IC 300 to decrypt and validate secure boot information stored in external storage 155. In the example of FIG. 3, computing system 395 includes IC 300 and external storage 155. IC 300 includes a processor 310 and internal storage 320 including (e.g., encoded with) a set of executable internal instructions 321, including instructions 322, 324, 326, 328, and 332. Internal storage 320 may be a machine-readable storage medium. Processor 310 may fetch, decode, and execute instructions stored on internal storage 320 to implement the functionalities described below. In other examples, the functionalities of any of the instructions of internal storage 320 may be implemented in the form of electronic circuitry, in the form of executable instructions encoded on a machine-readable storage medium, or a combination thereof.

[0043] IC 300 may also include a cryptography module 115, as described above in relation to FIG. 1, a cryptography module 314, a memory management unit 318, and secure storage 370. In some examples, memory management unit 318 may be implemented in the form of electronic circuitry, in the form of executable instructions encoded on a machine-readable storage medium, or a combination thereof. Secure storage 370 may be a machine-readable storage medium. Additionally, in some examples, secure storage 370 may be a machine-readable storage medium.

[0044] In the example of FIG. 3, processor 310 may execute internal instructions 321 in response to a reset request 381 if, at least, a secure state value is stored in operating state storage 314 of IC 300. In some examples, processor 310 may execute internal instructions 321 in response to a reset request 381 if a secure state value is stored in operating state storage 314 of IC 300. In other examples, processor 310 may execute internal instructions 321 in response to a reset request 381 if a secure state value is stored in operating state storage 314 and a non-validated value is stored in validation result storage 316 of IC 300.

[0045] In some examples, internal instructions 321 may be instructions to validate secure boot instructions prior to executing the secure boot instructions in a secure mode of operation. For example, it may be desirable to validate the integrity of secure boot information 160 prior to executing instructions 170 to provide additional protection for sensitive information and security parameters utilized by a computing device including IC 300. Such validation, which may delay booting, may not be desirable in a clear state primarily used in a secure environment or in a zeroize state in which security parameters have been zeroized and are likely not vulnerable. Accordingly, in some examples, internal instructions 321 may be executed in a secure state, and not in a clear or zeroize state.

[0046] In the example of FIG. 3, a reset handler 312 of processor 310 may receive reset request 381 and, in response to reset request 381, determine whether to execute internal instructions 321. In such examples, in response to reset request 381, reset handler 312 may determine whether a secure state value (e.g., a value indicating a secure state) is stored in operating state storage 314. In some examples, operating state storage 314 may store a value indicating the state (e.g., secure, clear, zeroize, etc.) in which IC 300 is to operate after reset. For example, if a clear state value or a zeroize state value is stored in state storage 314, then reset handler 312 may determine not to execute internal instructions 321 in response to reset request 381.

[0047] In some examples, reset handler 312 may determine to execute internal instructions 321 in response to reset request 381 if a secure state value is stored in operating state storage 314. In other examples, reset handler 312 may determine to execute internal instructions 321 in response to reset request 381 if a secure state value is stored in operating state storage 314 and a non-validated value is stored in validation result storage 316 for information 160, indicating that information 160 has not been validated. In such examples, reset handler 312 may determine not to execute internal instructions 321 if a valid result value is stored in result storage 316 for information 160, indicating that information 160 has already been validated, regardless of whether a secure state value is stored in storage 314. In some examples, if a clear state value is stored in storage 314, reset handler 312 may determine not to execute internal instructions 321, and may instead begin to retrieve information from a clear state reset vector. In such examples, if a zeroize state value is stored in storage 314, reset handler 312 may determine not to execute internal instructions 321, and may instead begin to retrieve information from a zeroize state reset vector.

[0048] In some examples, reset request 381 may be generated by instructions executed by processor 310 (e.g. a software generated reset). In other examples, reset request 381 may be received from outside of processor 310. Additionally, in some examples, at least one of operating state storage 314 and validation result storage 316 may be included in internal storage 320. In other examples, operating state storage 314 and validation result storage 316 may be separate from internal storage 320. In such examples, each of storage 314 and storage 316 may each be part of a machine-readable storage medium. Additionally, in some examples, the functionalities of reset handler 312 may be implemented in the form of electronic circuitry, in the form of executable instructions encoded on a machine-readable storage medium, or a combination thereof.

[0049] In some examples, if reset handler 312 determines to execute internal instructions 321, reset handler 312 may cause processor 310 to jump to internal instructions 321, transfer control to instructions 321, or otherwise trigger the execution of instructions 321. In the example of FIG. 3, internal instructions 321 include instructions 322, 324, 326, 328, and 332. Instructions 322 may associate a secure region 157 of external storage 155 with a first cryptographic technique in the memory management unit 318.

[0050] In some examples, memory management unit 318 may include information mapping regions of external storage 155 to cryptographic information to be used when retrieving information from those regions, respectively. In the example of FIG. 3, instructions 322 may associate secure region 157 with a first cryptographic technique by mapping secure region information 317 with first cryptographic data 319 in memory management unit 318. In such examples, secure region information 317 may be information corresponding to (e.g., identifying the addresses encompassed by) secure region 157 that may be used, for example, to identify access requests (e.g., read and write requests) for secure region 157. In some examples, first cryptographic data 319 may identify at least one of a first cryptographic technique and a cryptographic technique parameter. In other examples, first cryptographic data 319 may include a location of first cryptographic information stored outside of memory management unit 318. In such examples, instructions 322 may map secure region information 317 with an address at which first cryptographic information 372A is stored in secure storage 370.

[0051] Instructions 324 may request to read secure boot information 156 from secure region 157 of external storage 155. For example, instructions 324 may request to read secure boot information 156 from a secure reset vector, which may be an address in secure region 157. In some examples, in response to the request to read from secure region 157, cryptography module 155 may decrypt secure boot information 156 with the first cryptographic technique associated with secure region 157 in memory management unit 318 to generate decrypted secure boot information 160. Decrypted secure boot information 160 may be stored in internal storage by module 115, as described above in relation to FIGS. 1 and 2. In some examples, in response to a request to access external storage 155, memory management unit 318 may configure cryptography module 115 to use a cryptographic technique associated with the region to be accessed so that information read from or written to that region may be formatted using the appropriate cryptographic technique.

[0052] For example, processor 310 may provide the read request of instructions 324 to memory management unit 318, which may determine, based on secure region information 317, that the read request is a request to access secure region 157. In response, memory management unit 318 may configure cryptography module 115 with the first cryptographic technique based on first cryptographic data 319 associated with secure region information 317. For example, first cryptographic data 319 may be an address of first cryptographic information 372A in secure storage 370. In such examples, memory management unit 318 may retrieve first cryptographic information 372A from secure storage 370 in response to the read request. Memory management unit 318 may receive information 372A via a communication 383, and provide information 372A to cryptographic module 115, via a communication 384, to configure cryptography module 115 to utilize information 372A when reading from secure region 157. In other examples, first cryptographic data 319 may include first cryptographic information 372A, which memory management unit 318 may provide to cryptography module 115 in response to the read request.

[0053] In the example of FIG. 3, secure storage 370 may store at least one set of cryptographic information. For example, secure storage 370 may store first and second cryptographic information 372A and 372B. In such examples, first cryptographic information 372A may include at least one of a first cryptographic technique identifier 374A and at least one first technique parameter 376A. In some examples, second cryptographic parameters 3728 may include at least one of a second cryptographic technique identifier 374B and at least one second technique parameter 3768.

[0054] In examples described herein, a cryptographic technique may be, for example, any information formatting technique, such as an encryption and/or decryption technique, a compression and/or decompression technique, or any other information encoding and/or decoding technique. In examples described herein, a technique parameter may be any parameter used by any cryptographic technique, such as, for example, an encryption key, a cryptographic mode identifier, an operation type identifier, an initialization value, or the like. In examples described herein, a cryptographic mode identifier may identify a mode in which a cryptographic technique is to operate (e.g., electronic codebook (ECB), cipher-block chaining (CBC), XTS-AES, etc.). Additionally, in examples described herein, an operation type identifier may identify an operation type (e.g., encryption, decryption, etc.) to be used with a cryptographic technique.

[0055] In some examples, other regions of external storage 155 may be associated with other cryptographic data in memory management unit 318. For example, alternate region 159 may be associated with second cryptographic data including second cryptographic information 372B or pointing to second cryptographic information 372B in secure storage 370. In such examples, in response to a request to access alternate region 159, memory management unit may provide second cryptographic information 372B to cryptography module 115 to configure module 115 to format information read from or written to region 159 in accordance with second cryptographic information 372B. In some examples, alternate region 159 may be a region storing boot information for the zeroize operating state or boot information for the clear operating state. In such examples, second cryptographic information 372B may include information for a different cryptographic technique than first cryptographic information 372A. Additionally, in some examples, cryptographic information, such as second cryptographic information 3728, may indicate that information is to be passed through cryptography module 115 without being reformatted. In such examples, second cryptographic information 3728 may configure module 115 with a null cryptographic technique in which no reformatting is performed so that information stored in cleartext (e.g., clear state boot information) may be property read through module 115 without reformatting (e.g., decrypting) the information.

[0056] In other examples, alternate region 159 may be another secure region of storage 155. In such examples, a first portion of secure boot information 156 may be stored in secure region 157 and a second portion of secure boot information 156 may be stored in alternate region 159. In such examples, the first and second portions of secure boot information 156 may be encrypted differently. In some examples, to appropriately decrypt each portion, regions 157 and 159 may be associated with different cryptographic information in memory management unit 318.

[0057] In such examples, memory management unit 318 may configure ayptographic module 115 with the appropriate cryptographic information when processor 310 accesses each region. For example, in response to any request to read from secure region 157, memory management unit 318 may configure cryptography module 115 with first cryptographic information 372A, as described above. Additionally, in response to any request to any request to read from alternate region 159, memory management unit 318 may configure cryptography module 115 with second cryptographic information 372B. In examples in which first and second portions of secure boot information 156 are encrypted differently, instructions 322 may additionally associate alternate region 159 with a second cryptographic technique in memory management unit 318 by, for example, associating region 159 with second cryptographic information 3728 in memory management unit 318. Additionally, in some examples, cryptography module 115 may decrypt the first and second portions of secure boot information 156 to generate decrypted secure boot information 160.

[0058] In the example of FIG. 3, instructions 326 may determine which of a plurality of different validation techniques is specified in validation control data of secure boot information. For example, instructions 326 may determine which of a plurality of different validation techniques is specified in validation control data of secure boot information retrieved from secure region 157 and decrypted by cryptography module 115. In such examples, secure boot information may include validation control data, as described above in relation to FIGS. 1 and 2. In some examples, instructions 326 may determine the specified validation technique from a validation technique identifier included in the validation control data. For example, instructions 326 may determine the specified validation technique by accessing the validation control data of decrypted secure boot information 160 after at least a portion of secure boot information 156 has been decrypted to generate at least a portion of secure boot information 160. In some examples, the validation control data may include at least one of an identifier associated with one of the validation techniques, a validation technique parameter, and a validation length, as described above in relation to FIG. 2.

[0059] In some examples, instructions 328 may determine, with the specified validation technique, whether validation data of the decrypted secure boot information 160 is consistent with the decrypted secure boot information 160, as described above in relation to FIGS. 1 and 2. In some examples, the specified validation technique may include deriving test data from at least a portion of decrypted secure boot information 160, as described above in relation to FIGS. 1 and 2. In some examples, instructions 328 may derive the test data from the portion of decrypted secure boot information 160 in accordance with the specified validation technique at least in part with another cryptography module 314. In such examples, instructions 328 may instruct cryptography module 314 to derive the test data from the portion of decrypted secure boot information 160 in accordance with the specified validation technique (e.g., by hashing the information with a particular hash function, etc.). In some examples, the test data may be derived at least partially in parallel with retrieving encrypted secure boot information 156 from external storage, as described above in relation to FIGS. 1 and 2.

[0060] In the example of FIG. 3, instructions 332 may cause processor 310 to execute secure boot instructions of decrypted secure boot information 160 (e.g., instructions 170 of FIG. 2) in response to determining that the validation data is consistent with decrypted secure boot information 160. In some examples, instructions 332 may cause processor 310 to execute secure boot instructions of secure boot information 160 stored in internal storage of IC 300, as described above in relation to FIG. 2.

[0061] In other examples, instructions 332 may cause processor 310 to execute secure boot instructions of encrypted secure boot information 156 stored on external storage 155. For example, in response to determining that the validation data is consistent with decrypted secure boot information 160, instructions 332 may store a valid result value in validation result storage 316 and then generate a reset request 381. In such examples, in response to the reset request 381, reset handler 312 may determine that a secure state value is stored in storage 314 and a valid result value is stored in storage 316 and thus determine not to execute internal instructions 321, since secure boot information 156 has already been validated. In such examples, reset hander 312 may cause processor 310 to jump to secure boot instructions of secure boot information 156 stored on external storage 155 to boot a computing device including IC 300. In such examples, the secure boot instructions may be retrieved from external storage 155, decrypted by cryptography module 115 as configured by memory management unit 318 according to the memory region being accesses as described above, and executed by processor 310 after being decrypted.

[0062] FIG. 4 is a flowchart of an example method 400 for generating test validation data with a validation technique specified in validation control data. Although execution of method 400 is described below with reference to computing system 395 of FIG. 3, other suitable components for execution of method 400 can be utilized (e.g., IC 100 and computing device 201). Additionally, method 400 may be implemented in the form of executable instructions encoded on a machine-readable storage medium, in the form of electronic circuitry, or a combination thereof.

[0063] At 405 of method 400, processor 310 may map a first secure region of external storage (e.g., secure region 157) to a first cryptographic technique in memory management unit 318 of IC 300. In some examples, the processor 310 may map or otherwise associate information identifying the first secure region with an address of first cryptographic information 372A in secure storage 370. In such examples, first cryptographic information 372A may include a technique identifier 374A identifying the first cryptographic technique. At 410, memory management unit 318 may, in response to a request from processor 310 to read from the first secure region storing at least a first portion of secure boot information, configure cryptography module 115 of IC 300 to decrypt information with the first cryptographic technique. In some examples, memory management unit 318 may configure module 115 by providing first cryptographic information 372A to module 115, as described above in relation to FIG. 3. In some examples, the first portion of the secure boot information may be a first portion of encrypted secure boot information 156 stored in external storage 155. In such examples, a second portion of secure boot information 156 may be stored in another region of external storage 155 (e.g., alternate region 159) and may be encrypted differently than the first portion of the secure boot information. In other examples, all of encrypted secure boot information 156 may be encrypted in the same manner (e.g., with the same technique and key) and stored in the first secure region (e.g., secure region 157).

[0064] At 415, cryptography module 115 may decrypt at least the first portion of the secure boot information with the first cryptographic technique as the secure boot information is read from external storage 155. In some examples, processor 310 may read the secure boot information from external storage 155 via cryptography module 115, which may decrypt at least the first portion of the secure boot information as it is read from external storage 155. In such examples, memory management unit 318 may configure cryptography module 115 to decrypt information read from the first secure region with the first cryptographic technique (e.g., decryption technique) specified in first cryptographic information 372A and any first parameters specified therein, as described above. In examples in which all of the secure boot information is stored in the first secure region, module 115 may decrypt all of the secure boot information with the first cryptographic technique and the first parameters.

[0065] In some examples, the secure boot information may include validation control data, as described above in relation to FIGS. 1-3. At 420, processor 310 may determine what validation technique is specified by the validation control data of the secure boot information. In some examples, the validation control data may include a validation technique identifier, as described above in relation to FIGS. 2 and 3. In such examples, processor 310 may determine, at 420, the validation technique indicated by the validation technique identifier of the validation control data.

[0066] If the validation control data specifies the first validation technique, then method 400 may proceed to 425. At 425, processor 310 may determine, with the first validation technique, whether validation data of the secure boot information is consistent with the secure boot information, as described above in relation to FIGS. 1 and 2. If the validation control data specifies the second validation technique, then method 400 may proceed to 430. At 430, processor 310 may determine, with the second validation technique, whether validation data of the secure boot information is consistent with the secure boot information, as described above in relation to FIGS. 1 and 2. In the example of FIG. 4, the first and second validation techniques are different validation techniques.

[0067] At 435, processor 310 may execute secure boot instructions of the secure boot information if the validation data is consistent with the secure boot information. For example, if the specified validation technique is the first validation technique, processor 310 may execute the secure boot instructions if the validation data was determined, with the first validation technique, to be consistent with the secure boot information. In other examples, if the specified validation technique is the second validation technique, processor 310 may execute the secure boot instructions if the validation data was determined, with the second validation technique, to be consistent with the secure boot information. In some examples, the secure boot instructions may be executed as described above in relation to FIGS. 1-3.

[0068] FIG. 5 is a flowchart of an example method 500 for decrypting secure boot information with at least one cryptographic technique and a specified validation technique. Although execution of method 500 is described below with reference to computing system 395 of FIG. 3, other suitable components for execution of method 500 can be utilized (e.g., IC 100 and computing device 201). Additionally, method 500 may be implemented in the form of executable instructions encoded on a machine-readable storage medium, in the form of electronic circuitry, or a combination thereof.

[0069] At 505 of method 500, processor 310 may map a first secure region of external storage (e.g., secure region 157) to a first cryptographic technique in memory management unit 318 of IC 300. In some examples, processor 310 may map or otherwise associate information identifying the first secure region with an address of first cryptographic information 372A in secure storage 370. In such examples, first cryptographic information 372A may include a technique identifier 374A identifying the first cryptographic technique. At 510, processor 310 may map a second secure region of external storage (e.g., alternate region 159) to a second cryptographic technique in memory management unit 318 of IC 300. In some examples, processor 310 may map or otherwise associate information identifying the second secure region with an address of second cryptographic information 372B in secure storage 370. In such examples, second cryptographic information 372B may include a technique identifier 374B identifying the second cryptographic technique.

[0070] At 515, memory management unit 318 may, in response to a request from processor 310 to read from the first secure region storing a first portion of secure boot information, configure cryptography module 115 of IC 300 to decrypt information with the first cryptographic technique. In some examples, memory management unit 318 may configure module 115 by providing first cryptographic information 372A to module 115, as described above in relation to FIG. 3, in response to any request to read from the first secure region. In some examples, the first portion of the secure boot information may be a first portion of encrypted secure boot information 156 stored in external storage 155. In such examples, a second portion of secure boot information 156 may be stored in the second secure region of external storage 155 and may be encrypted differently than the first portion of the secure boot information.

[0071] At 520, cryptography module 115 may decrypt at least the first portion of the secure boot information with the first cryptographic technique as the secure boot information is read from external storage 155. In some examples, processor 310 may read the first portion of the secure boot information from external storage 155 via cryptography module 115, which may decrypt the first portion of the secure boot information with the first cryptographic technique as it is read from external storage 155. In such examples, memory management unit 318 may configure cryptography module 115 to decrypt information read from the first secure region with the first cryptographic technique (e.g. decryption technique) and any parameters of first cryptographic information 372A, as described above, in response to any request to read from the first secure region.

[0072] At 525, memory management unit 318 may, in response to a request from processor 310 to read from the second secure region storing a second portion of secure boot information, configure cryptography module 115 of IC 300 to decrypt information with the second cryptographic technique. In some examples, memory management unit 318 may configure module 115 by providing second cryptographic information 3728 to module 115, as described above in relation to FIG. 3, in response to any request to read from the second secure region. In some examples, the second portion of the secure boot information may be a second portion of encrypted secure boot information 156 stored in external storage 155 encrypted differently than the first portion of the secure boot information.

[0073] At 530, cryptography module 115 may decrypt the second portion of the secure boot information with the second cryptographic technique as the second portion of the secure boot information is read from external storage 155. In some examples, processor 310 may read the second portion of the secure boot information from external storage 155 via cryptography module 115, which may decrypt the second portion of the secure boot information with the second cryptographic technique as it is read from external storage 155. In such examples, memory management unit 318 may configure cryptography module 115 to decrypt information read from the second secure region with the second cryptographic technique (e.g., decryption technique) and any parameters of first cryptographic information 372B, as described above, in response to any request to read from the second secure region.

[0074] In some examples, the secure boot information may include validation control data, as described above in relation to FIGS. 1-3. At 535, processor 310 may determine what validation technique is specified by the validation control data of the secure boot information. In some examples, the validation control data may include a validation technique identifier, as described above in relation to FIGS. 1 and 2. In such examples, processor 310 may determine, at 535, the validation technique indicated by the validation technique identifier of the validation control data.

[0075] If the validation control data specifies an error-detection validation technique, then method 500 may proceed to 540. At 540, processor 310 may determine, with the error-detection validation technique, whether validation data of the secure boot information is consistent with the secure boot information, as described above in relation to FIGS. 1-3. If the validation control data specifies a hashing validation technique, then method 500 may proceed to 545. At 545, processor 310 may determine, with the hashing validation technique, whether validation data of the secure boot information is consistent with the secure boot information, as described above in relation to FIGS. 1-3. If the validation control data specifies a digital signature validation technique, then method 500 may proceed to 550. At 550, processor 310 may determine, with the digital signature validation technique, whether validation data of the secure boot information is consistent with the secure boot information, as described above in relation to FIGS. 1-3.

[0076] At 555, processor 310 may execute secure boot instructions of the secure boot information if the validation data is determined, with the specified validation technique, to be consistent with the secure boot information. In some examples, functionalities described herein in relation to FIGS. 4-5 may be provided in combination with functionalities described herein in relation to any of FIGS. 1-3.