Secure Encryption Coprocessor

Abstract

A device with an integrated circuit (IC) chip can provide protection against attacks on the cryptographic coprocessor. An attacker can compromise the cryptographic coprocessor, for example, by obtaining a secret encryption key or instruction code. To counter these attacks, an implementation stores information in encrypted form. This information can correspond to data, instruction codes, or intermediate values ​​in a status register. To safely and quickly "erase" such stored information, the cryptographic coprocessor can change the encryption key. In another implementation, the random numbers are provided with two different levels of "randomness quality" suitable for different types of procedures. The cryptographic coprocessor can include two registers that store randomized bits according to two different quality levels for fast access during cryptographic operations. To further thwart possible attacks, the cryptographic coprocessor can verify the content or usage of the instruction code executed to perform the cryptographic operation.

Description

Background Art

[0001] Background Electronic devices play an indispensable role in manufacturing, communication, transportation, healthcare, commerce, social interaction, and entertainment. For example, electronic devices supply power to server farms that provide cloud-based distributed computing capabilities for commercial transactions and communication. Electronic devices are also incorporated into various types of modern equipment, from medical devices to household appliances, and from vehicles to industrial tools. Using personal electronic devices enables portable video viewing and convenient access to smart digital assistants. Furthermore, the smartphone, one of the multi-purpose electronic devices, has become an almost essential item within reach. As electronic devices become widespread and indispensable in various aspects of modern life, device security has become essential.

[0002] Many people are familiar with malware, sometimes collectively referred to as "computer viruses." Some malware is designed to illegally access the information stored on electronic devices or to attack electronic devices. Some strategies can help protect the user's devices and information from security threats by combating specific types of malware. These strategies include the adoption of a resilient operating system and regular updates, the practice of secure computing, and the installation of anti-malware programs. Unfortunately, these strategies cannot make electronic devices invulnerable to all malware attacks.

[0003] Furthermore, an electronic device can be vulnerable to other types of attacks than those executed by software-based malware. For example, the secure and reliable operation of an electronic device, and the security of the information stored in such a device can be put at risk by physical attacks on the hardware or high-frequency attacks on wireless communications. In other words, some attack forms can avoid or weaken the strategies mentioned above, enabling malicious parties to breach the electronic device and potentially access the accounts used on that device.

[0004] An electronic device includes at least one integrated circuit (IC) that provides the intelligence to enable various functions. These functions facilitate commerce, streamline access to healthcare, provide entertainment, support social media interactions, and enable other services identified above. An electronic device can also store or utilize information that should be protected. To support these functions and promote secure operation, some electronic devices include hardware-based protection in the form of a security circuit that is part of the IC. Unfortunately, existing approaches to security circuits are insufficient to counter the various software, hardware, and wireless attacks launched against electronic devices today. SUMMARY OF THE INVENTION PROBLEMS TO BE SOLVED BY THE INVENTION

[0005] Overview Certain electronic devices, such as server computers and smartphones, are responsible for providing services to users. Users rely on these electronic devices to obtain important services accessed using one or more accounts, such as financial services, air travel, and government official documents. The link between the electronic device and the account can allow unwanted access to the services linked to the account or unauthorized access to the account itself through a compromised electronic device. Further, to provide the services associated with such accounts, these electronic devices may store account-related information that should be protected, such as financial data, usernames, passwords, and confidential keys for encryption. Unfortunately, malware countermeasures cannot block all means of attacking an electronic device. For example, malware countermeasures may not provide protection against direct physical attacks that use small probes to detect voltage levels on an integrated circuit (IC) chip. Therefore, it is beneficial to incorporate hardware-based countermeasures into electronic devices that can identify, block, repel, or prevent attacks on the electronic device, including countermeasures against physical attacks.

[0006] Accordingly, an electronic device may include a security circuit to counter attacks from malicious parties. In some cases, the security circuit detects inappropriate or suspicious activities and takes protective measures. The security circuit can be implemented in various ways. For example, a computer engineer can manufacture the security circuit as a stand-alone IC chip or as part of another chip such as a system-on-chip (SoC). In either case, the security circuit can be part of a protected enclave, a trusted chip platform, a hardware-based root of trust (RoT) (e.g., a silicon RoT), or a combination thereof. Regardless of how and where the security circuit is incorporated into the electronic device, a computer engineer can design a security circuit that counteracts many different types of attacks, as described next.

[0007] Attacks on electronic devices can take the form of programs that observe screen images or monitor repetitive actions to infer information, applications that attempt to read data from protected areas of memory, direct physical probes of circuits, and the like. The security circuit performs multiple functions to counter one or more of these attacks. For example, the security circuit can protect encryption keys during use, transportation, or storage. To do so, dedicated memory and a private data bus can be used. The security circuit can also generate high-quality pseudo-random numbers and operate an encryption engine in an area separated from applications that may act as malware. Additionally, the security circuit can be designed to ensure that the hardware is booted using an unmodified and correct bootable Basic Input / Output System (BIOS).

[0008] Accordingly, the security circuit can be responsible for implementing a diverse set of functions to counter a wide variety of attacks on electronic devices. However, existing approaches to security circuits employ hardware architectures designed on an ad-hoc basis. Different circuit parts of the security circuit can also be designed relatively separately from each other. As a result, circuit parts designed to counter different security threats may not interoperate as intended, and the security of the hardware can be degraded. Furthermore, insufficient communication between components can create new attack paths for would-be malicious actors. Additionally, this ad-hoc approach makes the design and test phases of the security circuit more difficult, longer, and more costly. This can result in some security threats being overlooked or inadequately addressed during the development of the security architecture. Therefore, with these ad-hoc architectures, it becomes even more difficult to protect electronic devices from a wide variety of security threats.

Means for Solving the Problem

[0009] However, this document describes an approach that can provide an adaptable and flexible framework or platform that can generate resilient programmable security hardware to counter various forms of attacks on electronic devices in some examples. In some implementations of security circuits, different types of circuits, or circuit portions that provide different security-related functions, communicate using an extended protocol that generates reliable and consistent signaling despite this. This communication protocol enables circuits that provide different security-related functions to interact seamlessly according to a specified design framework. The design framework and the communication protocol generate "compatible components" that are suitable for consistent deployment with stable and predictable interactions, even if they are circuit components designed separately from each other. As used herein, "compatible components" includes these components designed to conform to a common framework so that the components are suitable for use together. In some cases, compatibility provides a degree of plug-and-play functionality between two or more security-related components of an integrated circuit chip.

[0010] A security circuit can include a plurality of peripheral devices in addition to a processor and interconnections. Each peripheral device of the plurality of peripheral devices can perform some function that contributes to the security or proper functioning of the security circuit. Thus, each peripheral device can provide a security-related core function or support function. This function supports the overall purpose of the security circuit, such as controlling access to data and performing encryption operations. Such purposes can include providing a function that enables secure computing by other circuits and / or ICs of the electronic device. For predictability and interoperability, each peripheral device can be implemented as a compatible component.

[0011] In general, computing and other electronic devices are subject to attacks, including physical attacks, that can destroy or steal data. Hardware Root of Trust (RoT) approaches can counter many attacks, including physical attacks. RoT silicon can be implemented in integrated circuits that provide security functions. In some cases, silicon RoT chips include an encryption processor or coprocessor and are subject to physical attacks by malicious parties attempting to read information such as encryption keys or instruction codes, or to violate encryption procedures. These physical attacks can be carried out while the encryption coprocessor is “stopped” or while the encryption coprocessor is executing an encryption procedure.

[0012] However, an encryption coprocessor can be designed or built to withstand attacks. Additionally, an encryption processing block or module can be implemented as a compatible component of a security chip (e.g., an encryption co-processing peripheral device). Thus, a silicon RoT chip or other security circuit can include an encryption processor (e.g., a coprocessor or accelerator) that operates as a block or module within a secure system. This processor can be used, for example, to provide asymmetric encryption such as message signing using Rivest-Shamir-Adleman (RSA) or Elliptic Curve Digital Signature Algorithm (ECDSA). In some implementations, the encryption processor can be realized as a general-purpose processor with “special” instructions and functional units for asymmetric encryption. For example, functions adapted for encryption operations can include a wide (e.g., 256-bit) register file, an arithmetic logic unit (ALU), and a multiply-accumulate (MAC) unit. These circuits can provide high-speed processing of wide integers used in some forms of asymmetric encryption. Simplifying the design of the encryption processor can reduce the area subject to attack while achieving performance targets. The encryption processor can also be used for, or instead of, symmetric encryption operations.

[0013] To protect an encryption coprocessor within a silicon RoT chip or other security circuit, the information stored in the encryption coprocessor can be encrypted. Encryption of information is an example of a more general term used here and means "protecting information from unauthorized access." Other examples of "protection of information from unauthorized access" include making the encrypted information inaccessible by deleting the encryption key, efficiently providing multiple bits randomized according to two or more levels of randomization quality to an encryption operation, and / or facilitating verification of executable code. This information can correspond to data, instruction code, intermediate values in status registers, etc. In this document, a technique for securely and quickly "erasing" such stored information by changing the encryption key will be described. In some encryption procedures, one or more random numbers are used to perform the encryption operation. This document describes techniques for providing random numbers with two different levels of "randomness quality" (also referred to herein as "randomness quality") suitable for different types of procedures. The randomness quality may be a numerical randomness value (e.g., an entropy value) derived from the distribution of the random numbers. In the case of a sequence of random numbers (including bits), the randomness quality indicates the difficulty of predicting consecutive random numbers (including bits) when some or all of the previous random numbers (including bits) of the sequence are given. Further, the encryption coprocessor can include two registers that store bits randomized according to two different randomness quality levels for fast access during the encryption operation. Additional implementation examples of a secure encryption coprocessor relate to verification of the content or usage of the instruction code executed to perform the encryption operation. These and other described techniques can be implemented to make the encryption coprocessor more secure against attacks.

[0014] The apparatus and techniques of a secure encryption coprocessor will be described with reference to the following drawings. Throughout the drawings, the same numbers are used to refer to like features and components.

Brief Description of the Drawings

[0015]

Figure 1

Figure 2

Figure 3-1

Figure 3-2

Figure 3-3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

[0016] Detailed Description Overview Electronic devices make important contributions to modern society, such as in communication, security, and manufacturing. Each electronic device relies on an integrated circuit (IC) with processing capabilities to provide some function. Since many of these functions have important properties, an electronic device may include an IC with a security circuit that provides protection. The security circuit reduces the possibility that information is inadvertently disclosed or that some functions are used in harmful or unauthorized ways. The security circuit can be implemented in various forms, one of which includes the trusted root (RoT) paradigm.

[0017] In RoT silicon, a hardware-based mechanism ensures the security of computations from the perspectives of preventing inappropriate access to information and blocking unauthorized use of devices. The principle of silicon RoT can help ensure that both the hardware infrastructure and the software running on it are maintained in an intended and trustworthy state. To this end, silicon RoT can use approved and verifiable code to confirm that important system components start up securely. Thus, it can be guaranteed that a server or another electronic device boots with the correct firmware and that the firmware is not infected with low-level malware. Silicon RoT can provide additional or alternative security benefits. For example, it can provide a cryptographically unique machine ID. This unique ID allows the operator to confirm that the electronic device is legitimate. Furthermore, since encryption keys and other information can be maintained in a tamper-resistant silo, even those with physical access to the device are unable to obtain the information, or at least are deterred. The RoT service fixed to the hardware can also provide reliable anti-tampering audit records and other runtime security services.

[0018] Chip designers can incorporate silicon Root of Trust (RoT) technology into individual IC chips that prioritize the provision of security features. Alternatively, RoT silicon can also be integrated with other circuits, including central processing unit (CPU) chips or packages, graphics processing unit (GPU) chips or cards, system-on-chip (SoC), memory storage devices, and so on. Generally, security circuits can operate on, for example, server motherboards, network cards, client devices (such as laptops and smartphones), consumer routers, Internet of Things (IoT) devices, fixed and portable storage devices. By fixing RoT in silicon, security for calculations is enhanced across all levels of hardware, firmware, and software, regardless of the application or electronic device. Silicon RoT also enhances security between various devices that communicate with each other directly or via a network. In this document, a silicon or hardware RoT environment is used to explain some of the principles of security and circuit design, but this is done as an example only, as the principles described are applicable to security circuits in general.

[0019] In today's computing environment, malicious actors can attack electronic devices at numerous levels using a multitude of attack vectors. For example, an attack could be carried out using malware transmitted via the Internet to obtain information that a user wants to protect stored on a laptop. Also, during the transportation of electronic devices such as Wi-Fi (registered trademark) routers or IoT devices, or during operation in a location where they are not visible to people, malware can be inserted into the firmware used to start up the electronic device. As another example, a malicious actor may steal an electronic device, and there may be sufficient time to perform a direct physical attack on the device. Such direct physical attacks can include cutting wires, investigating voltages, inserting obstacles with a laser, and repeatedly executing code for trend observation or information speculation.

[0020] Therefore, the security circuit can be responsible for implementing a diverse set of functional suites to counter various attacks on the electronic device. However, existing approaches to security circuits employ hardware architectures designed on an ad-hoc basis. Different circuit parts of the security circuit can also be designed relatively separately from each other. As a result, circuit parts designed to counter different security threats may not interoperate as intended, leading to a decrease in the security of the hardware. Furthermore, insufficient communication between components creates new attack paths for would-be malicious actors. Additionally, this ad-hoc approach makes the design and testing phases of the security circuit more difficult, longer, and costlier. This can cause some security threats to be overlooked or inadequately addressed during the development of the security architecture. Therefore, it becomes even more difficult to protect the electronic device from a wide variety of security threats with these ad-hoc architectures.

[0021] However, this document describes an approach that provides an adaptable and flexible framework or platform capable of generating resilient programmable security hardware to counter various forms of attacks on the electronic device. In some implementations of the security circuit, different types of circuits, or circuit parts providing different security-related functions, communicate using an extended protocol that generates reliable and consistent signaling despite this. This communication protocol enables circuits providing different security-related functions to interact seamlessly according to a specified design framework.

[0022] Design frameworks and communication protocols produce "compatible" components suitable for consistent deployment with stable, predictable interactions, even for circuit components designed separately from each other. For example, communication and other forms of interaction (e.g., sharing of resources such as buses, interfaces, or memory) can be at least partially standardized to provide measures of predictability and interoperability. As used herein, "compatible components" include components designed to conform to a common framework so that the components are suitable for use together. In some cases, compatibility provides a degree of plug-and-play functionality between two or more security-related components of an integrated circuit chip.

[0023] In some implementations, the security circuit includes a plurality of peripheral devices in addition to a "centralized" processor and interconnections. Each of the plurality of peripheral devices performs some function that contributes to the security or proper functioning of the security circuit. Thus, each peripheral device can provide a core security-related function or a supporting security-related function. This function supports the overall purpose of the security circuit, including providing functions that enable secure computing by other circuits and / or ICs of the electronic device, such as controlling access to data and performing cryptographic operations. For predictability and interoperability, each peripheral device can be implemented as a compatible component.

[0024] Examples of circuit components that can be implemented as interchangeable components and / or as peripheral devices are encryption processors (including encryption coprocessors), blocks, or modules. The encryption processor can be coupled to a system bus or interconnect to provide encryption functions such as mathematical calculations to another part of the security circuit or integrated circuit. The encryption processor can be implemented as an encryption coprocessor that supports or operates in cooperation with a "main" processor, a "central" processor, or a "host" processor. The encryption coprocessor can be used, for example, for asymmetric encryption (such as Rivest-Shamir-Adleman (RSA) encryption and / or Elliptic Curve Digital Signature Algorithm (ECDSA) encryption).

[0025] In some implementations, the encryption coprocessor can be enhanced to detect or repel fault injection attacks. For example, the coprocessor can use a (39,32) Hsiao error correction code (ECC) for integrity protection. The ECC can be used in error detection mode by eliminating correctability, such as providing 3-bit error detection as opposed to 2-bit detection and 1-bit correction. Also, the coprocessor can use an inversion single error correction and double error detection (SEC-DED) Hsiao ECC code that selectively inverts specific bits to make all-zero words and all-one words invalid codewords. This enables detection of attacks that set all bits to 0 or all bits to 1. Additionally, the coprocessor can include data and / or instruction memory integrity protection that functions, for example, with 32-bit and 256-bit reads and / or writes (or other bit widths).

[0026] In some cases, a memory integrity protection scheme can be implemented that avoids (if possible) recalculation of integrity bits through one or more component transitions. For example, a coprocessor can include a path that is fully protected for integrity from the data memory to the register file. To do so, a transmission path (including, e.g., wires and buffers) for propagating data between the data memory and the register file can include sufficient capacity (e.g., an appropriate bit width) to transmit data bits and associated protection bits (e.g., ECC bits). Also, an integrity protection scheme that consumes integrity-protected data (e.g., data + ECC bits) can be incorporated into the coprocessor. For example, the integrity protection scheme can be extended from the system bus through the data memory to the register file of the coprocessor without re-encoding the data. Combining memory scrambling and ECC can be applied to the memory of an encryption coprocessor to spread inserted faults. In other examples, the decoding and / or control logic can be replicated. Such replication can cause one copy to produce an inverted version of the generated output. Fault detection can be achieved by checking that one output matches the inversion of the other output. Further, the integrity of instructions from the instruction memory to the functional unit can be provided by combining the above (e.g., replication of decoding logic) with ECC bits for checking from the instruction memory. Thus, ECC can protect the path to the decoding device, and the replicated decoding device can protect the path to the functional unit. For example, a processor with a replicated instruction decoder can provide resistance to fault injection attacks.

[0027] In other implementations, the encryption coprocessor can be hardened against side-channel leakage by using one or more techniques either individually or in any combination. First, many, most, or all instructions can have a timing that is independent of data, such as one cycle per instruction. In general, each particular instruction can take one, two, three, or more cycles, but the number of cycles to execute a particular instruction is the same each time the particular instruction is executed, regardless of the target data. Second, most or all of the states maintained within a processing block can be randomly and securely cleared. Third, the information in the data and instruction memories (such as SRAM) can be cleared by changing at least one memory scramble key. Changing the key makes it impossible to access all of the data and instruction codes within a single cycle without leaking the data or instruction codes. Fourth, the regions to erase the information can be selected individually or separately.

[0028] These regions can include most or all of the internal states that can be stored in the instruction memory, data memory, and registers. Changing this scramble key enables rapid protection and / or targeted protection of the information stored in various memories. If the instruction memory is saved across calls to the coprocessor, performance can be improved by repeatedly (e.g., more than once) executing the same encryption algorithm using different data. To manually trigger data clearing, it may be necessary for the host software to first be able to read the data before the data is cleared.

[0029] In an additional or alternative implementation, the encryption coprocessor can provide different qualities of randomness to software (e.g., the instruction code that executes the coprocessor and / or the instruction code that executes on the coprocessor). Examples of the quality of randomness can include low-quality randomness and relatively high-quality randomness. Relatively low-quality randomness can be used, for example, for blind / masking or randomizing the control flow of an application. Since standards are published for some public encryption algorithms, relatively high-quality randomness can be used, for example, to meet the common criteria certification requirements for encryption use cases. Random values generated according to different qualities of randomness can be stored in separate registers and / or prefetched, or determined in advance so that they can be prepared when random bits are used. Random bits associated with a higher randomization quality may require more energy or time to obtain, so by utilizing two different levels of randomness quality, the encryption coprocessor can balance power efficiency or execution speed with an appropriate level of security according to the encryption operation.

[0030] The encryption coprocessor can provide other implementations with different and / or complementary security features. For example, the coprocessor can provide the host processor with a checksum calculated for all instruction codes (or a specified portion of instruction data) written to or being written to, for example, the instruction memory. Thereby, the host can verify the content of the instruction code. Alternatively, or a checksum can be calculated for data stored in the data memory, which is another or combined function for verifying the content of the data. Additionally or alternatively, the coprocessor can provide the host processor with the amount or number of instructions executed to verify the execution of the instruction code. In certain implementations, it is also possible to execute symmetric operations using an encryption coprocessor capable of executing asymmetric operations (e.g., by implementing an algorithm such as a symmetric block cipher like AES-256, or by implementing an algorithm such as a secure hash algorithm (SHA) like SHA2-512 or a keyed hash algorithm like HMAC-SHA-512).

[0031] In these ways, the security circuit can be incorporated into the silicon RoT chip and / or SoC. Such a security circuit includes a plurality of peripheral devices including an encryption coprocessor. Some aspects of secure encryption processing and / or a secure encryption coprocessor are described in the context of a security circuit environment and / or a portable design, but the disclosed concept of a secure encryption coprocessor is applicable to other circuit environments and other design paradigms. Furthermore, some aspects of secure encryption processing and / or a secure encryption processor are described with respect to a coprocessor or a coprocessing environment, but the disclosed concepts of a secure encryption coprocessor and co-processing are generally applicable to encryption processors and / or encryption co-processing environments.

[0032] This document describes a secure and / or enhanced encryption coprocessor. However, in this document, an example of a security environment will first be described with reference to FIGS. 1 to 2. Next, examples of a peripheral device interface and design code analysis including "compatible components" will be described with reference to FIGS. 3-1 to 3-3. Next, this document describes aspects and implementations of a secure encryption coprocessor with reference to FIGS. 4 to 8. An example of an electronic device will be described with reference to FIG. 9. Each of the environments, aspects, circuits, techniques, and implementations described in this specification can be used individually or in any combination.

[0033] Therefore, an implementation example of a secure encryption coprocessor will be described below at various levels of detail with reference to the associated drawings. In the following description, an example of an operating environment will first be shown, and then examples of hardware, methods, and techniques will be described. The exemplary methods will then be described with reference to flowcharts or diagrams. Finally, an example of a computing device will be described.

[0034] Example of an Operating Environment of a Secure Encryption Coprocessor FIG. 1 generally shows an exemplary device 102 having an integrated circuit 104 (IC104) including a security circuit 106 at 100. The device 102, the integrated circuit 104, and / or the security circuit 106 can implement the secure encryption coprocessor 118 described in this document. In this example, the device 102 is shown as a smartphone. However, the device 102 may be implemented as any suitable computing or electronic device.

[0035] Examples of the device 102 include mobile electronic devices or mobile devices, mobile communication devices, modems, cellular or mobile phones, mobile stations, game devices, navigation devices, media or entertainment devices (e.g., media streamers and game controllers), laptop computers, desktop computers, tablet computers, smart appliances, vehicle-based electronic systems, wearable computing devices (e.g., clothing, watches, or augmented reality glasses), Internet of Things (IoT) devices, sensors, inventory management devices, electronic parts of machines or electronic components of equipment (e.g., vehicles and robots), memory storage devices (e.g., solid state drives (SSDs)), server computers or parts thereof (e.g., server blades or racks, or other parts of a data center), etc. Illustrated examples of the device 102 include a tablet device 102-1, a smart TV 102-2, a desktop computer 102-3, a server computer 102-4, a smart watch 102-5, a smartphone (or document reader) 102-6, and intelligent glasses 102-7.

[0036] In an implementation example, the device 102 includes at least one integrated circuit 104. The integrated circuit 104 can be attached to a module, a card, or a printed circuit board (PCB) (not shown). Examples of the PCB include flexible PCBs, rigid PCBs, single-layer or multi-layer PCBs, surface-mounted or through-hole PCBs, combinations thereof, etc. Each integrated circuit 104 can be implemented as a general-purpose processor, a system-on-chip (SoC), a security-oriented IC (e.g., a RoT IC chip), a memory chip, a communication IC (e.g., a modem and a radio frequency IC), a graphics processor, an artificial intelligence (AI) accelerator, combinations thereof, etc. The integrated circuit 104 can be packaged alone or together with other IC chips.

[0037] As shown, integrated circuit 104 includes security circuit 106. Security circuit 106 can include various components including a plurality of circuit components 108-1…108-C (where C represents a positive integer) and interconnects 110. Examples of circuit components 108 include processors and a plurality of peripheral devices in addition to interconnects 110. These are shown in FIG. 2 and described below. Although not explicitly shown in FIG. 1, integrated circuit 104 may include other portions other than security circuit 106. The plurality of circuit components 108-1…108-C and interconnects 110 may be integrally integrated on a single IC as shown, or the components may be distributed across two or more ICs. Security circuit 106 can be implemented, for example, as a protected enclave, a trusted chip platform, a hardware-based root of trust (RoT) chip (e.g., silicon RoT), etc. Regardless of how or where security circuit 106 is incorporated into an electronic device, security circuit 106 can counter many different types of attacks.

[0038] In an operation example, when an attack, or a potential attack, or an abnormality occurs is detected, an alert 112 or an interrupt 114 is generated by some component. For example, the circuit component 108 can generate the alert 112 and send the alert 112 to the alert handler described later. Additionally or alternatively, another circuit component 108 can generate the interrupt 114 for processing by the processor. The alert 112, the interrupt 114, and other signals are communicated between two or more components 108 according to a common framework for interaction between the processor of the security circuit 106 and / or peripheral devices. In the common framework, the interface and signaling of each peripheral device can be specified to facilitate interoperability and the use of a consistent communication protocol across multiple peripheral devices. Thus, although some aspects of compatibility are shown with respect to the security circuit, the compatibility of peripheral devices can also be adopted for other types of circuits. Exemplary frameworks, as well as exemplary communication interfaces and interface specifications, will be described below with reference to FIGS. 3-1 through 3-3.

[0039] In some implementations, circuit component 108 is implemented as an encryption coprocessor 118 (or encryption co - processing block 118). The encryption coprocessor 118 can be incorporated into the security circuit 106 as a peripheral device, a portable component, a combination thereof, etc. For example, the security circuit 106 can utilize the encryption coprocessor 118 for high - speed and / or efficient encryption operations, including cryptographic - related mathematical calculations involving many digits. Thus, the encryption coprocessor 118 can execute the encryption process 116. The operations and / or circuitry of the encryption process 116 and the encryption coprocessor 118 can be protected against many forms of attacks, including physical attacks, using the methods and techniques described herein. These methods and techniques include, for example, leveraging randomness of various qualities or erasing information by securely changing the scramble key associated with the information. These and other aspects of a secure encryption coprocessor are described below with reference to FIGS. 4 through 8. However, referring to FIG. 2, an example architecture of the security circuit 106 is next described.

[0040] FIG. 2 shows an exemplary security circuit 106 that includes a plurality of circuit components, including a plurality of exemplary peripheral devices 250 that can be implemented interchangeably. As shown, the security circuit 106 includes a processor 202 coupled to an interconnect 110. The interconnect 110 can be implemented using, for example, a bus, a switching fabric, or a bus network that enables communication among various circuit components. The plurality of circuit components 108 - 1…108 - C (of FIG. 1) can include a plurality of memories and a plurality of peripheral devices in addition to the interconnect 110 and / or the processor 202. Each of the processor 202, the plurality of memories, and the plurality of other peripheral devices 250 is directly or indirectly coupled to the interconnect 110. As shown in FIG. 2 and as described herein, the encryption coprocessor 118 can be implemented as a peripheral device 250 of the security circuit 106. However, the encryption coprocessor 118 may be implemented in another environment.

[0041] In an implementation example, the plurality of memories can include a read-only memory 206 (ROM 206), a static random access memory 208 (SRAM 208), and a flash memory 210. The plurality of peripheral devices 250 can include an alert handler 204, an Advanced Encryption Standard (AES) engine 212 (AES engine 212), a hash-based message authentication code (HMAC) engine 214 (HMAC engine 214), a serial peripheral interface (SPI) device 230 (SPI device 230), and a flash controller 216. The plurality of peripheral devices 250 can also include a universal asynchronous receiver / transmitter (UART) device 218 (UART device 218), a general-purpose input / output (GPIO) interface 220 (GPIO interface 220), a pin multiplexer 222 (pin multiplexer 222), and a pad controller 224. The plurality of peripheral devices 250 can further include a random number generator 232 (RNG 232) and a timer 234. Further, as shown in FIG. 2, the peripheral device 250 can include any memory. Specific examples of the memory and other peripheral devices 250 are shown in FIG. 2 or described herein, but a particular implementation of the security circuit 106 may include more, fewer, and / or different instances of processors, controllers, memories, modules, or peripheral devices (including duplicates thereof).

[0042] The illustrated circuit components can operate synchronously based on one or more clock signals. Although not shown in FIG. 2, the security circuit 106 may include at least one clock generator for generating a clock signal, or may include a reset circuit for resetting one or more individual components independently of each other, a plurality of components together, or the entire IC chip. Alternatively, the security circuit 106 may receive at least one clock signal or reset signal from a source external to the security circuit 106, and that source may or may not be on a separate chip. One or more separate peripheral devices 250 can operate in their respective individual clock domains. For example, input / output (I / O) peripheral devices can be synchronized to a clock local to each I / O device or channel. Peripheral devices within different clock domains can operate or communicate asynchronously with each other.

[0043] An implementation example of the illustrated components will be described below. Processor 202 may be implemented as the "main", "central", or "core" processor of security circuit 106. As just one example, processor 202 may be implemented as a 32-bit in-order reduced instruction set computing (RISC) core with a multi-stage pipeline. For example, using the RISC-V capabilities, the processor can implement M (machine) mode and U (user) mode. When the reset pin (not shown) is activated (e.g., through de-assertion of an active-low reset pin), processor 202 ends the reset and starts executing code at its reset vector. The reset vector can start within ROM 206 and check the code within that embedded flash (e-flash) before jumping to the emulated embedded flash (e-flash). In other words, the code is expected to be instantiated in the e-flash before the reset is released. In some cases, the reset of the entire security circuit 106 can be asynchronous active-low according to a compatibility specification to support interoperability between various circuit components. The reset may be generated by a watchdog timer or the like by alert handler 204 as a security measure. The reset signal may be sent to other circuit components such as one of the memories or one of the other peripheral devices 250.

[0044] The processor 202 has a debug module 226 (DM226) and an interrupt controller 228 (ItC228) coupled thereto, both of which can be made interchangeable. The debug module 226 provides debug access to the processor 202. By interfacing with specific pins of the IC, the logic of the debug module 226 enables the processor 202 to enter the debug mode and provides the function of inserting code into the device (e.g., by emulating instructions) or memory. The interrupt controller 228 can be placed (e.g., positioned or arranged) near the processor 202. The interrupt controller 228 can receive the vector of interrupt sources from within the security circuit 106. The interrupt controller 228 can also equalize and assign priorities to the interrupts before transferring them to the processing of the processor 202.

[0045] The processor 202 can provide any desired level of performance or can include any internal circuit components. For example, the processor 202 can include at least one arithmetic logic unit (ALU) (e.g., including an "additional" ALU that calculates branch targets to remove latency cycles in taken conditional branches) and a plurality of pipeline stages. Using the plurality of pipeline stages, the pipeline can perform register write-back to reduce the latency cycles due to loads and stores and prevent pipeline stalls where the response to a load or store becomes available in cycles after the request. The processor 202 can implement a single-cycle multiplier or can generate an inaccurate exception on an error response to a store, whereby the processor can continue execution past the store without waiting for a response. Although not shown, in particular, the processor 202 or generally the security circuit 106 can include an instruction cache that provides a single-cycle access time to instructions.

[0046] In the illustrated example, the security circuit 106 includes three memory address spaces for instructions and data. The ROM 206 is targeted by the processor 202 after reset release. The ROM 206 includes hard-coded instructions for performing a subset of the platform check before checking the next stage of the code. The next stage of the code (e.g., the boot loader stored in the e-flash memory) can be the first code portion that is not hard-coded in the device's silicon. Thus, at this next stage of the code, a signature check for integrity is performed to enhance security. The ROM 206 can perform this signature check by implementing the Rivest-Shamir-Adleman (RSA) check algorithm on the complete contents of the boot loader.

[0047] The flash memory 210 can be implemented as an e-flash memory for code storage. In addition to the above boot loader, this e-flash can accommodate the operating system and applications in the layers thereon. The SPI device 230 can be used to bulk load the e-flash memory. The debug module 226 can also be used for code loading. The SRAM 208 can operate as a scratchpad SRAM available for data storage (e.g., stack and heap information) by the processor 202. The SRAM 208 can also store code.

[0048] The security circuit 106 can include a suite of "peripheral devices" or "peripheral equipment". These peripheral devices 250 can be slave execution devices coupled to the processor 202 via the interconnect 110. Each of these peripheral devices 250 can conform to an interface framework that guarantees compatibility with each other and with the processor 202. The compatibility scheme can specify how the processor 202 communicates with a particular peripheral device (e.g., using the interconnect 110), how the peripheral device communicates with the chip I / O (e.g., via fixed or multiplexable I / O), how the peripheral device communicates with the processor 202 (e.g., using interrupts), how the peripheral device communicates security events (e.g., using alert indications) to other circuit components such as the alert handler 204, how the peripheral device communicates with other peripheral devices (e.g., synchronously or asynchronously via at least one register), or combinations thereof. The illustrated peripheral devices 250 can include peripheral devices related to the processor 202, related to one or more memories, related to the chip I / O, etc., related to the alert-related functions provided by the alert handler 204. Thus, the memory can also include peripheral devices 250 related to each other or related to other illustrated circuit components.

[0049] The circuit or chip I / O peripheral devices include a pin multiplexer 222 and a pad controller 224. The pin multiplexer 222 provides a signaling route between at least a portion of the peripheral device 250 and the available multiplexable I / O nodes of the security circuit 106 (e.g., the pins of a chip in which various components are integrated, or the interface to other parts of the SoC). The pad controller 224 manages control or pad attributes such as the drive strength, technology, pull-up versus pull-down of the external I / O of each circuit (e.g., chip). The pin multiplexer 222 and the pad controller 224 are themselves peripheral devices on the interconnect 110. Thus, each can have or be associated with a set of at least one register that provides software configurability.

[0050] The UART device 218 can implement UART functions such as a single-lane dual UART function. Its output and input can be configured to connect to any circuit I / O via the pin multiplexer 222. The GPIO interface 220 creates bidirectional communication of G bits to an external circuit via the pin multiplexer 222, where G is a positive integer such as 16, 32, or 64. With respect to memory I / O, the SPI device 230 can implement a firmware mode. Here, the firmware mode can enable a function that provides the ability for an external driver to send firmware upgrade code to a bank of the flash memory 210 for in-field firmware updates. The firmware mode can include addressing of memory using SPI transactions. Although not shown, the security circuit 106 can include an inter-integrated circuit (I2C) host to enable commands for I2C devices. Such commands for I2C devices can include standard mode, full mode, and high-speed mode.

[0051] Several "core security" peripheral devices are also shown, including an encryption engine and an alert handler 204. The AES engine 212 can provide symmetric encryption and decryption using one or more protocols and various key sizes such as 128b, 192b, or 256b. This component can select to encrypt or decrypt data arriving in, for example, 16-byte units and can encrypt or decrypt using different block encryption modes of operation. The AES engine 212 can support, for example, the electronic codebook (ECB) mode, the cipher block chaining (CBC) mode, the cipher feedback (CFB) mode, the output feedback (OFB) mode, the counter (CTR) mode, etc. Data transfer can be made available to the processor. For example, the key and data material can be passed to the encryption engine via register writes. Alternatively, a private channel for transferring the key and data material can be included to reduce exposure to the activities of a potentially untrusted processor.

[0052] The HMAC engine 214 can utilize, for example, the secure hash algorithm (SHA) SHA-256 as the hash algorithm. SHA-256 is a member of the SHA-2 family of hash algorithms, and the length of the digest (or hash output) is 256 bits regardless of the data size of the input being hashed. Data is sent to the HMAC peripheral device after declaring the start of a hash request. This zeros the internal state to the initial state (e.g., 32 bits at a time). When data is sent by a component client, the client can indicate the completion of the hash request (using any partial word final write). According to an example of a portability interface scheme, the HMAC engine 214 generates a hash result and makes it available for register reads by the requesting client. Data transfer can be made available to the processor or can be made private to reduce exposure to the activities of a potentially untrusted processor.

[0053] HMAC is a message authentication protocol layered on top of a hash function (e.g., SHA-256), and HMAC mixes a secret key for encryption purposes. HMAC is a specific application that adds a secret key in a predetermined way (such as twice) around the hash of a message (via SHA-256). To provide this functionality, a 256-bit key can be programmed into the circuit components before the message hash is initiated. The timing of authentication completion can vary and the latency can be longer than when using native SHA-256. Here too, the hash information or the secret key can be made available to the processor for convenience or processing efficiency, or can be made non-public in some way to enhance security.

[0054] The alert handler 204 is responsible for processing alerts that include alerts provided by other peripheral devices 250 and responding to the alerts. The alerts can be considered security-sensitive interrupts that are processed in a timely manner to address recognized security threats. Unlike "standard" interrupts, alerts are not processed only by software running on the processor 202. Alerts can trigger a first-stage request to be processed as a "normal" interrupt by software. However, if the software cannot appropriately repair in response to an interrupt triggered by an alert, the alert handler 204 triggers a second-stage response. The second-stage response can include taking security measures such as terminating the process, erasing or otherwise deleting data, powering off a circuit portion, or resetting the IC chip or a part thereof. This ensures that underlying problems, i.e., recognized security threats, are addressed even if the processor 202 is busy, under interference, or under attack.

[0055] Accordingly, alert 112 (e.g., FIG. 1) can be implemented as a high-priority interrupt type signal or alert indication received by alert handler 204 from other peripheral devices and indicating a potential security threat. During operation, alert handler 204 can collect alerts from other circuit components 108 of security circuit 106 and convert them into interrupts that processor 202 can handle. However, if processor 202 does not clear the interrupt, alert handler 204 provides a hardware response to address the potential security threat.

[0056] In some inter-device communications, alert handler 204 receives synchronous or asynchronous alert indications notified by a differential signal from a peripheral device source. Peripheral device 250 can generate an alert based on the function, knowledge, or sensed parameters of peripheral device 250. In other inter-device communications, alert handler 204 performs a ping test of the alert source as a robust heartbeat mechanism. A ping monitor (not explicitly shown) of alert handler 204 requests periodic alert responses from each alert source to ensure that the communication channel with the alert source is functioning.

[0057] The alert handler 204 can also generate hardware alerts supplied locally based on communication failures. The first local source alert is generated when differential signaling or another predetermined communication protocol with the alert source or escalation handler fails (e.g., when a signal integrity check fails). The alert handler 204 generates such a second alert when the alert source or escalation handler does not respond to a ping request. Generally, the alert handler 204 receives incoming alerts from the entire system, classifies the alerts, issues interrupts based on the classified alerts, and can escalate the interrupts to a hardware-based response if the processor 202 does not clear the issued interrupts. Thus, if the processor cannot or does not process a security alert, the alert handler 204 can function, for example, as a surrogate for a security response.

[0058] In some architectures, security alerts are intended to be rare events, at least compared to "standard" interrupts. Thus, at the design stage, events that can occur can be designated as alert events if they potentially impact security within the range where it is expected that the event will not occur frequently. Examples of such events include parity errors (which may indicate an attack), unauthorized actions on cryptographic or security-related components, sensed values from physical sensors indicating a change in the environment (such as voltage or temperature), etc. The system routes alerts via the alert handler 204, and the processor 202 converts the alerts into interrupts for potential handling. In some implementations, it is fundamentally expected that a secure operating system has a protocol for handling such interrupts generated by alerts in software. If so, the secure operating system can typically resolve the interrupt and then use the alert handler 204 to clear the interrupt. Each peripheral device 250 can present a list of individual alerts representing each potential threat to be addressed. The peripheral device can use a specific encoding mechanism to send the alerts as alert instructions to the alert handler 204.

[0059] The security circuit 106 can also include an RNG 232. Generally, randomness can contribute to security functions by providing variations in execution so that an attacker cannot predict the appropriate timing to start an attack. For example, random numbers can provide confidential materials used for purposes such as IDs and encryption. The RNG 232 can be seeded into algorithm calculations to obfuscate confidential data values. Generally, the RNG 232 provides better performance in a range where its number generation becomes more truly random and can be strengthened against attacks. The RNG 232 can be implemented as a "true" RNG (TRNG), which can include designs having an analog portion for utilizing some non-deterministic physical event or process. Examples of TRNG designs rely on metastability, electronic noise, timing variations, thermal noise, quantum fluctuations, etc. The TRNG filters the resulting variables and then sends them to an entropy pool where the device can sample at a specific time for the current randomization function. In some cases, the interface to the entropy pool can include a request to read available random bits. The TRNG interface indicates the number of bits available, and the requesting peripheral device or software can read from this pool up to the range of available bits. Attempting to read non-available entropy bits can trigger an interrupt or alert.

[0060] The other two peripheral devices 250 include a timer 234 and a flash controller 216, and the latter will be described in the following paragraph. The timer 234 can support, for example, the accurate performance by the processor 202. The timer 234 is formed from a plurality of bits (e.g., 64 bits) and operates as a free-running timer having a frequency guaranteed within a certain percentage. Another timer (not explicitly shown) can function as a watchdog timer that backs up the processor 202 when the processor stops responding. Failure to respond can be due to interference from development code, security attacks, etc.

[0061] The flash controller 216 controls the flash memory 210 available for code and data storage. The main primary read path for this data can be in the standard memory address space. However, since flash is not written in a standard way, writes to that address space can be ignored. Instead, to write to the flash memory 210, software interacts with the flash controller 216. The flash functions can include three primary commands: read, erase, and program. The read command can be standardized and the address space of the chip memory can be used. The erase command is executed at the page level and the page size can be parameterized by the flash controller 216. When an erase request is received, the flash controller 216 erases the contents of the target page and sets the data to the "1" state (e.g., 0xFFFFFFFF per word). Thereafter, software can program individual words to any value. Since the flash bits do not return to the "1" state unless erased again, future contents are effectively changed by the AND of the current contents and the written value. The erase and program commands are relatively slow. Typical erase times are measured in milliseconds and program times are in the microsecond range. Security is also a concern since sensitive data can be stored in the flash memory 210. Thus, a certain degree of memory protection can be provided by the flash controller 216.

[0062] Security circuit 106 is shown in FIG. 2 along with a particular set of circuit components. However, a particular security circuit 106 can have more, fewer, or different circuit components. The circuit components can also be interconnected in different ways or operate in ways other than the exemplary ways described above. Further, some circuit components can be omitted while others can be implemented in multiple instances. For example, alert handler 204 may be replicated or distributed, or multiple AES encryption engines 212 may be present within some security circuits 106. Further, for an IC chip in which security circuit 106 forms only one of dozens of cores, GPIO interface 220 can be omitted from among the peripheral devices 250 of security circuit 106.

[0063] Compatible Paradigm Approaches, Technologies, Hardware Examples of Secure Encryption Coprocessing Peripheral Devices Security circuit 106 (e.g., of FIGS. 1 and 2) can include compatible circuit components including peripheral devices 250 such as encryption coprocessor 118. In this section, example approaches for making peripheral devices compatible are described. Each peripheral device 250 can conform to the compatibility specifications of security circuit 106. By conforming to a compatibility specification that defines at least one interface scheme or communication protocol, peripheral device 250 is implemented with at least one interface that produces a consistent and predictable interaction between peripheral device 250 and other peripheral devices. This improves the predictability and certainty of communication and reduces the time required for the design and testing of security circuits.

[0064] FIG. 3-1 shows an exemplary peripheral device 250 including at least one interface 302 to support compatibility with other circuit components at 300-1. More generally, FIG. 3-1 includes an interconnect 110, a processor 202 coupled to the interconnect 110, and a plurality of peripheral devices coupled to the interconnect 110. Thus, the plurality of peripheral devices can be coupled to the processor 202 at least via the interconnect 110. However, each peripheral device 250 may be coupled to the processor 202 directly or via a mechanism corresponding to, for example, interface 302, register interface 310, or at least one inter-device communication 316 without using the interconnect 110, which will be described below. FIG. 3-1 explicitly shows P peripheral devices 250-1, 250-2, …, 250-P, where P represents a positive integer.

[0065] In an implementation example, each peripheral device 250 includes at least one interface 302 that enables the peripheral device 250 to conform to a communication framework that provides certainty for the interoperability of peripheral devices. For example, interface 302, or communication interface 302, can enable the peripheral device 250 to implement at least one communication protocol 320. Interface 302 includes at least one interconnect interface 304, at least one inter-device interface 306, and at least one other interface 308. These interfaces will be described below. As shown, peripheral device 250 typically also includes at least one register interface 310 and at least one security function module 312. Generally, interface 302 enables the peripheral device 250 to conform to a common framework for interacting with the processor 202 and other peripheral devices among the plurality of peripheral devices 250-1…250-P.

[0066] The register interface 310 includes one or more registers or register entries. Each register entry can be used, for example, for communication to or from the peripheral device 250 (e.g., communication to or from). For example, the processor 202 or another peripheral device can set or clear a register entry, or load a value into the register entry for communication with the peripheral device 250. Conversely, the peripheral device 250 can change the value of the register entry for communication with the processor 202 or another peripheral device. To enable this communication, the peripheral device 250 can expose at least a portion of the register interface 310 to the processor 202 or another peripheral device. For example, the peripheral device 250 can provide processor access to clear an interrupt status indication.

[0067] Generally, the register block can be used to communicate with the rest of the peripheral logic, for example, to manage configuration and status communication with software. In some cases, the register interface 310 can be implemented using control and status registers (CSRs). The CSRs provide a set of registers within the peripheral device 250 that can be addressed, at least by the local host processor 202, via the address map of the entire circuit or chip. Standardizing the CSRs improves software uniformity and promotes circuit reuse and document consistency. Exemplary aspects of the register interface 310 are described below with reference to FIG. 3-3.

[0068] The security function module 312 implements security-related functions of the peripheral device 250. The security-related functions include core or primary security functions and support or secondary security functions. The core security functions may include, for example, alert processing, encryption operations including encryption and decryption, random number generation, and secure data storage including storage and access of confidential data (e.g., key management). The security functions to support may include functions that enable or facilitate the performance of the core functions. Examples of the security functions to support include memory storage, memory control, timing, circuit and chip I / O control, environmental sensors, bus hosting, and the like.

[0069] Generally, either the interface 302 or a specific exemplary interface (e.g., the interconnect interface 304, the inter-device interface 306, or the other interface 308) can establish at least one register with respect to the register interface 310 to enable their respective interface communication capabilities or functions. Regarding the interconnect interface 304, the interconnect interface 304 implements a communication interface coupled to the interconnect 110 to enable connection between the peripheral device 250 and the processor 202 that complies with, for example, a common framework. By the peripheral device 250 and the processor 202 conforming to the same common framework, two-way device-processor communication can be standardized and predictable. The interconnect interface 304 can operate throughout the interconnect 110, can use at least one register of the register interface 310, and can use a separate bus or independent wires, combinations thereof, and the like. During operation, the peripheral device 250 can participate in at least one interconnect communication 314 using the interconnect interface 304. Additionally or alternatively, the peripheral device 250 can communicate with another peripheral device via the interconnect 110 using the interconnect interface 304.

[0070] The inter-device interface 306 implements a communication interface between the peripheral device 250 and one or more other peripheral devices that conform to a common framework. By having the peripheral device 250 and each of the other peripheral devices conform to the same common framework, two-way inter-device communication can be standardized and made predictable. The inter-device interface 306 can use at least one register of the register interface 310, can use a bus dedicated to the peripheral device, can use one or more independent wires extending between two peripheral devices, some combination thereof, and the like.

[0071] During operation, the peripheral device 250 can participate in at least one inter-device communication 316 using the inter-device interface 306. In some implementations, the peripheral device 250 can communicate "directly" with other peripheral devices by bypassing the interconnect 110 to communicate with another peripheral device. Additionally, by establishing and conforming to an inter-device communication scheme, the consistency and reliability of communication between two or more devices are promoted. Thus, instead of spending time and resources tracking and double-checking a large number of in-situ communication regimes, the designer can focus on achieving the intended security-related functions of the security function module 312.

[0072] Another interface 308 implements a communication interface between the peripheral device 250 and another circuit component that conforms to a common framework. By having the peripheral device 250 and other circuit components conform to the same common framework, two-way peripheral device signaling can be standardized and made predictable. An example of the other interface 308 is a chip I / O interface for communicating information with the outside. Another example of the other interface 308 is an interrupt interface in cases where interrupts are not fully communicated via the interconnect 110. Yet another example of the other interface 308 is a clock interface. In some cases, the security circuit 106 (not shown separately in FIG. 3) includes a primary system clock and one or more secondary system clocks. The clock interface can utilize the primary system clock and at least a selected portion of the secondary system clocks for communication timing and general functionality. The clock interface can operate according to the clocking scheme of the security circuit 106, and the design code of the peripheral device 250 can specify the clocks relevant to the peripheral device 250. During operation, the peripheral device 250 can use the other interface 308 to participate in at least one other communication 318 with another circuit component such as an I / O circuit or a clock tree.

[0073] FIG. 3-2 shows an exemplary approach 300-2 for analyzing the design of a peripheral device so that the compatibility objective is reliably met. In an implementation example, approach 300-2 uses an interface specification 332 that can include an interconnect method 334, an inter-device method 336, or other method 338 (each including the respective method). Interface specification 332 corresponds to interface 302 (of FIG. 3-1). Interconnect method 334 corresponds to interconnect interface 304, inter-device method 336 corresponds to inter-device interface 306, and other method 338 corresponds to other interface 308. These methods can additionally or alternatively include local or chip-level I / O methods, interrupt methods, clock methods, etc.

[0074] Accordingly, interface specification 332 can establish the rules, protocols, attributes, options, functions, etc. of interface 302. Similarly, each of interconnect method 334, inter-device method 336, and other method 338 can establish the rules, protocols, attributes, options, functions, etc. of interconnect interface 304, inter-device interface 306, and other interface 308, respectively. At design time, the designer develops each peripheral device 250 to comply with each relevant method of interface specification 332. For example, inter-device method 336 can establish a format for defining inter-device signaling that bypasses the interconnect 110 of security circuit 106. By doing so, compatible peripheral devices 250 can be manufactured that enhance interoperability and reduce design and development time, as well as test and debug effort. For example, peripheral device 250 can communicate a signal (e.g., an inter-device signal) to another peripheral device using a circuit derived from the attributes specified by the design code of the peripheral device.

[0075] In an exemplary approach, the compatibility analysis module 340 can perform an analysis 344 of the design code to check compatibility. The designer creates the peripheral device design code 342 with reference to the interface specification 332. Thus, the peripheral device design code 342 meets the compatibility goal by complying with the interface specification 332. The peripheral device design code 342 can be at least partially implemented using, for example, a configuration file. The peripheral device design code 342 can include one or more instructions for processor device signaling 348 (e.g., defining the manner of the interconnection communication 314 between the peripheral device 250 and the processor 202), one or more instructions for inter-device signaling 350 (e.g., defining the manner of the inter-device communication 316 between the peripheral device 250 and another peripheral device), and the like. One or more instructions for inter-device signaling 350 can be related to signals exchanged between two or more peripheral devices, including, for example, the case where the interconnection 110 of the security circuit 106 is not used. These instructions can follow rules and guidelines regarding the registers of these signals, signal naming, data type, timing, and the like.

[0076] The description within the peripheral device design code 342 results in circuit components within the security circuit 106. For example, with respect to the device - to - device interface 306 of each peripheral device 250 (e.g., of FIG. 3 - 1), based on the attributes included in the design code 342, the device - to - device interface 306 can be coupled to at least one wire that extends to another peripheral device to enable device - to - device signaling. By specifying device - to - device signaling 350 within the design code 342, interoperability and communication reliability are improved. The interface specification 332 or the configuration file of the design code 342 can indicate (for a particular specification or design in this instance of the present disclosure) the peripheral functions that are essential and the peripheral functions that are optional within a particular compatibility framework. Thus, the compliant design code may include essential parts and optional parts depending on the situation. Generally, the design code 342 can be formatted according to any IC design or configuration platform. Examples include Verilog, Python, Hjson, etc.

[0077] During operation, the compatibility analysis module 340 receives the peripheral device design code 342. Referencing the interface specification 332, the compatibility analysis module 340 performs an analysis 344 to check whether the peripheral device design code 342 complies with the specified common framework. The compatibility analysis module 340 can check whether the code meets the respective specifications by comparing the peripheral device design code 342 with one or more of the interconnection method 334, the device - to - device method 336, or other method 338. These methods may include specifications regarding interrupts, register usage, etc. Based on the analysis 344, the compatibility analysis module 340 generates a compatibility report 346.

[0078] The compatibility report 346 indicates whether the peripheral device design code 342 passes the analysis 344 by meeting the criteria of the interface specification 332. If not, the compatibility analysis module 340 can include a list of "violations" in the compatibility report 346. Each violation can include a reference to the code portion that caused the fault indication or to the portion of the interface specification 332 that was violated. The interface specification 332, the compatibility analysis module 340, and the peripheral device design code 342 can be described with respect to an exemplary security circuit environment, but the interface specification 332, the compatibility analysis module 340, or the peripheral device design code 342 may be implemented in other environments. Thus, the compatibility report 346 can cover the analysis of general circuit designs.

[0079] FIG. 3-3 shows an exemplary peripheral device 250 including a register interface 310 and exemplary communication signals at 300-3. In FIG. 3-3, generally but by way of example only, the essential communication channels or signals are shown in solid lines (in this example of the present disclosure), and the optional communication channels or signals are shown in dashed lines. However, in other cases, different channels or signals can be essential or optional. Further, the solid or dashed lines in other figures do not necessarily indicate requirements or the lack of requirements under a given interface specification.

[0080] In an implementation example, various signals can be specified as part of a framework for compatibility that peripheral device 250 should comply with. Starting from the upper left, a bidirectional signaling 362-1 using interconnect 110 is shown together with a peripheral device 250 that functions as a device (e.g., functions as a follower) with respect to interconnect 110. Below that, peripheral device 250 is shown as receiving at least one clock signal 364 and at least one development mode signal 365. The development mode signal 365 indicates to peripheral device 250 which mode the security circuit 106 or the overall SOC is currently operating in. In other words, multiple operating modes may exist. In two example modes, the multiple modes may include a development mode and a production mode. The mode indication can determine, for example, how to handle software errors. In other modes, a security function that conveys the status of the full life cycle mode to the peripheral device may be enabled.

[0081] Peripheral device 250 can also generate or output at least one interrupt signal 366 or at least one alert signal 368. Further, a bidirectional signaling 362-2 using interconnect 110 is shown together with a peripheral device 250 that functions as a host (e.g., functions as a leader) with respect to interconnect 110. Peripheral device 250 can further participate in bidirectional signaling 367 with GPIO interface 220 or other chip I / O circuits. Regarding register interface 310, at least one output signal 369-1 is labeled as a signal from the register to hardware (Reg2Hw). On the other hand, at least one input signal 369-2 is labeled as a signal from hardware to the register (Hw2Reg). Generally, in some implementations, certain functions are considered essential while other functions are considered optional. However, these essential and optional categories can vary from implementation to implementation. In a compatible design, these two categories can be assigned to each function so that each peripheral device 250 can properly interoperate with other peripheral devices.

[0082] We have described in general terms the methods, techniques, and hardware for peripheral devices in a compatible paradigm, including examples of encryption co - processing peripheral devices having a secure encryption coprocessor. Here, the description moves on to the methods, techniques, and hardware of the secure encryption coprocessor.

[0083] Examples of methods, techniques, and hardware of a secure encryption coprocessor In this section, examples of encryption coprocessors that can be included in the security circuit 106 (e.g., of FIGS. 1 and 2) will be described. The encryption co - processing block or module can be connected as a peripheral device to the interconnect 110 (e.g., a system bus) in accordance with, for example, the compatibility principles described above. Additionally or alternatively, the encryption coprocessor 118 can have "direct" or exclusive bus access to or from one or more other components such as the peripheral device 250 or the processor 202 (e.g., of FIG. 2).

[0084] FIG. 4 shows an exemplary schematic diagram 400 according to an implementation of a particular encryption coprocessor. As shown in the schematic diagram 400, the exemplary encryption coprocessor 118 can include an instruction memory 402, a data memory 404, a controller 406, a plurality of registers 408 for storing random bits, and a decoder 410. The instruction memory 402 can store instruction codes 412, and the data memory 404 can store data 414. With regard to examples of register storage, the encryption coprocessor 118 can include one or more register sets such as general - purpose registers (GPRs) 416 and / or wide data registers (WDRs) 418.

[0085] With respect to an exemplary computing device, the encryption coprocessor 118 can include an incrementer 420, a base ALU 422, a big number (``bignum'') ALU 424, and a multiply-accumulate (MAC) device 426. Only certain components are shown in FIG. 4 and are described herein as part of the encryption coprocessor 118, but this is merely an example. More, fewer, replicated components, and / or different components can be included. For example, the encryption coprocessor 118 can also include a load and store unit (LSU) (or load store unit) that couples the data memory 404 to other components. The LSU can function as a bidirectional interface for data access such as reading and writing. Further, the encryption coprocessor 118 can include one or more other registers described herein, such as the CSR of the register interface 310 (of FIG. 3-3).

[0086] In an exemplary implementation, the various components shown can be coupled together as shown in FIG. 4. For example, the plurality of random bit registers 408 can be coupled to two sets of registers, namely, the GPR 416 and the WDR 418. The controller 406 and the decoder 410 can be coupled to the instruction memory 402. The two sets of registers can be coupled to the computing device (e.g., bidirectionally). Further, the data memory 404 can be coupled to the registers and / or the computing device via an LSU (not shown), for example. The illustrated connections between components are shown in FIG. 4 as merely an example. More, fewer, doubled connections, and / or different connections can exist. For example, the controller 406 can be coupled to any computing device and / or the random bit register 408.

[0087] In an exemplary operation scenario, decoder 410 can obtain one or more instructions of instruction code 412 from instruction memory 402. After decoding by decoder 410, controller 406 can execute the instructions based on the current program counter (PC) (not shown). Decoder 410 and controller 406 can provide control flow support by conditional branch and unconditional jump instructions, hardware loops, and hardware managed call / return stacks. Controller 406 can execute instructions based on the decoding using one or more computing devices such as base ALU 422 or big num ALU 424. As part of the execution of instruction code 412, controller 406 can store "working data" and other states in registers.

[0088] Registers may have different widths. For example, the banks of GPR416 may be 32-bit wide to store 32-bit words per register or register entry. GPR416 can supply and / or receive results from incrementer 420 and base ALU 422. In contrast, big-num ALU 424 can operate on larger data such as 128, 256, or 512 bits. Operating on wider data to perform wide integer arithmetic facilitates the execution of many cryptographic operations. The register bank of WDR418 can store this wider data, such as 256-bit data items. MAC426 can operate on wider 256-bit data and can also store information in an accumulator (ACC) register (not shown). As shown in FIG. 4, a wider computing device such as big-num ALU 424 can also receive narrower data, such as eight occurrences of 32-bit data values from GPR416 or incrementer 420, to obtain 256-bit data items. Also, specific bit widths (e.g., 32, 64, 128, 256, and 512) for registers, words, data paths, computing devices, etc. are described herein, but these are provided by way of example only. Instead, it is also possible to implement narrower or wider bit widths, different combinations of bit widths, etc.

[0089] In some implementations, the encryption coprocessor 118 can support a processor such as processor 202 (of FIG. 2) by performing encryption operations efficiently and / or quickly. The processor 202 first determines the encryption operation 430 to be performed. Examples of encryption operations 430 include asymmetric encryption operations such as RSA and elliptic curve cryptography for high-security public key schemes, and symmetric encryption operations (e.g., for SHA2-512, HMAC-SHA-512, and AES-256), which may be associated with less secure encryption operations. The processor 202 sends a request to perform the encryption operation 430. The request can be sent, for example, via an interconnect (e.g., interconnect 110 of FIGS. 1 and 2) or via a dedicated path between the processor 202 and the encryption coprocessor 118. In some cases, sending may include loading the operation code and / or data into one or more registers of the encryption coprocessor 118.

[0090] Accordingly, the encryption coprocessor 118 receives a request from the processor 202 to perform the encryption operation 430. The encryption coprocessor 118 uses the instruction code 412 and the intermediate value 428 to perform the encryption operation 430 on the data 414 and obtains the result 432. The intermediate value 428 is an example of a state (also referred to herein as "state information") maintained by the encryption coprocessor 118, including during the execution of the encryption operation 430, which refers to any data such as variable data existing within the encryption coprocessor. Examples of intermediate values can include instances of the data 414 that are copied or moved to a register while performing an encryption operation that does not represent a final result, the output of a computing device, the contents of a register "within" the computing device, and generated values.

[0091] Each intermediate value 428 can be stored, for example, in at least one register. Such registers may include GPR 416, WDR 418, the ACC of MAC 426, etc. Thus, although the intermediate value 428 is shown for WDR 418, the status information including at least one intermediate value 428 can be stored elsewhere in the encryption coprocessor 118. In addition to other registers, other locations for such status information can include the decoder 410, the base ALU 422, the big number ALU 424, etc. The status information may also include one or more flags of these or other components. The encryption coprocessor 118 protects at least one of the data 414, the intermediate value 428, or the instruction code 412 from unauthorized access.

[0092] Thus, information (e.g., processor state such as data 414, instruction code 412, or intermediate value 428) is protected by the encryption coprocessor 118 using one or more techniques described herein. The protection can exist during the time the encryption operation 430 is being executed and / or can be performed before and / or after that period. This protection can extend across all components of the encryption coprocessor 118, including at least the interface or communication-related registers of the encryption coprocessor 118. After determining the result 432 of the encryption operation 430, the encryption coprocessor 118 provides the result 432 to the processor 202. The encryption coprocessor 118 can, for example, publish the result 432 to the processor 202 using the registers of the encryption coprocessor 118, drive the result 432 on the interconnect 110 or a private / dedicated bus, etc. As another example, the encryption coprocessor 118 can write the result 432 to the data memory 404. In response to the encryption coprocessor 118 notifying the processor 202 that the encryption operation 430 has been completed, the processor 202 can read the result 432 from the data memory 404.

[0093] Figure 5 shows an example method 500 for securely erasing information in an encryption coprocessor. As shown, the encryption coprocessor includes at least one register 506 in addition to an instruction memory 402 and a data memory 404. The register 506 stores a state 508 such as at least one intermediate value 428. The register 506 can be arranged in or be part of any of the components shown in FIG. 4, for example. The encryption coprocessor 118 also includes one or more scramble keys such as a code scramble key 502 and a data scramble key 504. The scramble keys can be stored separately or together in one or more registers that are coupled to or accessible by a controller 406 or other logic that can apply the scramble keys to information and / or can securely erase the scramble keys.

[0094] In an exemplary implementation, the controller 406 uses the code scramble key 502 to scramble or encrypt the instruction code 412. The controller 406 uses the data scramble key 504 to scramble or encrypt the data 414. To protect information stored in at least one memory, the encryption coprocessor changes at least one scramble key used to scramble that information. Here, the memory may include not only the instruction memory 402 and the data memory 404, but also the register 506. Changing the corresponding scramble key is a fast and efficient approach for protecting the scrambled contents of the memory when suspicious activity is detected or when access to the encryption coprocessor 118 is transferred between two untrusted applications running on the processor 202.

[0095] Regarding the data memory 404, an encryption coprocessor (e.g., the controller 406 or other logic) can modify (e.g., change or replace) the data scramble key 504 to render the data 414 meaningless. Regarding the instruction memory 402, the encryption coprocessor can modify the code scramble key 502 to render the instruction code 412 meaningless. This modification can be completed in just 1 cycle. In some cases, to modify the scramble key, it may be necessary to overwrite at least one register storing the scramble key with random bits. This logic can further overwrite the random bits in at least one register with zero or other constant values such as a random netlist constant at compile time.

[0096] The encryption coprocessor can also protect the state 508 including the intermediate value 428 by overwriting at least one register 506 with randomness such as one or more random bits. In some cases, protecting the state 508 may require overwriting at least one register 506 storing the intermediate value 428 with random bits. The logic can further overwrite the random bits in at least one register 506 with zero. This two-step process can prevent some attacks based on observing the power signature.

[0097] Secure erasure can be triggered in many ways. First, software operating on the processor 202 can "manually" trigger secure erasure. Second, secure erasure can be triggered in response to an alert that may be internal to the encryption coprocessor 118 or from an external component. Third, the encryption coprocessor 118 can automatically trigger secure erasure for internal cleansing operations. Additional and alternative implementation examples for protecting information including instruction code, data, and state information are described herein.

[0098] FIG. 6 shows an example method 600 for efficiently providing randomized bits to support the secure operation of an encryption coprocessor. As shown, a plurality of registers 408 having randomized bits can include at least a first register 408-1 and a second register 408-2. The first register 408-1 can store a plurality of first bits 602-1 randomized according to a first randomness quality 604-1, and the second register 408-2 can store a plurality of second bits 602-2 randomized according to a second randomness quality 604-2 different from the first randomness quality 604-1. Thus, the encryption coprocessor 118 can access the randomized bits in at least two registers at different levels or with varying randomness qualities.

[0099] In an exemplary implementation, generally, the random bit register 408 can include two or more registers. Each respective register 408-X can store a respective set of a plurality of bits 602-X associated with a respective randomness quality 604-X, where "X" represents a positive integer greater than 1. The plurality of registers 408-1 and 408-2 enable fast access to the plurality of random bits 602-1 and 602-2 with respective multiple levels of randomness qualities 604-1 and 604-2. As will be described next, using random bits with different levels of randomness quality can efficiently balance "cost" and quality.

[0100] Some encryption operations and / or standards involve or specify a particular quality level of randomized bits. However, in certain situations, the higher the quality of the randomized bits, the higher the cost of obtaining the randomized bits. The cost can be related to power or time. In other words, the higher the quality of the randomization, the more power consumption may be required, and / or it may take longer to generate the randomized bits. By using a plurality of registers 408, the encryption coprocessor can quickly access multiple qualities of randomness while balancing their respective relative costs. In other words, if an encryption operation or another operation supporting the function of the encryption coprocessor 118 can use lower-quality randomness associated with a lower cost, the controller 406 can select bits associated with the lower quality of randomness.

[0101] In some implementations, the first register 408-1 stores a plurality of first bits 602-1 corresponding to a first quality of randomness 604-1. The second register 408-2 stores a plurality of second bits 602-2 corresponding to a second quality of randomness 604-2. In an example operation, the controller 406 can selectively retrieve the plurality of first bits 602-1 from the first register 408-1 or the plurality of second bits 602-2 from the second register 408-2 based on the quality of randomness 604 associated with the encryption operation 430 (e.g., of FIG. 4), including its "sub-operations".

[0102] Due to the relative quality of randomness, for example, the first randomness quality 604-1 can be higher than the second randomness quality 604-2. In such a case, the plurality of first bits 602-1 can correspond to a non-deterministic source of random numbers (e.g., an unpredictable bit source such as an analog-based entropy source of random numbers). The plurality of second bits 602-2 can correspond to a deterministic source of random numbers (e.g., a digital-based source that may require some predictability of future values based on past values of random numbers). To ensure that the encryption coprocessor 118 does not need to stop while waiting for, for example, high-quality randomization bits, the controller 406 can prefetch the plurality of first bits 602-1 into the first register 408-1 before the plurality of first bits 602-1 are used.

[0103] The first (relatively high) quality of randomness 604-1 can comply with, for example, one or more random number generation and / or cryptographic-related standards (e.g., Class PTG.2 specification or Class PTG.3 specification compliant with AIS31). The plurality of first bits 602-1 can have guaranteed entropy with forward and backward confidentiality. The randomization bits of this quality can be used, for example, for key generation. These randomization bits can be realized as at least one register and can be obtained from an entropy dispersion network (EDN) via a single-entry cache with protected integrity. The cache can potentially hold more bits than the controller 406 can extract at one time, regardless of the number of entries. When a read is performed when the cache is empty, the encryption coprocessor can stop until a new random number is fetched from the EDN, but such a stop can be avoided by appropriately prefetching bits into the cache before the read. This first higher quality of randomness 604-1 can correspond to the following description of RND.

[0104] The second (relatively low) quality randomness 604-2 can be generated faster and / or with lower power consumption. The plurality of second bits 602-2 may correspond to random numbers without guaranteed confidentiality characteristics or specific statistical characteristics. Such bits can be used, for example, in masking and blinding schemes or to randomize the control flow of an application. The randomized bits can be supplied from a local pseudo-random number generator (PRNG) including a lightweight PRNG. Examples of PRNGs include the xohiro PRNG and PRNGs that digitally generate additional randomization bits using one or more linear feedback shift registers (LFSRs). The LFSR can be implemented as a Galois type LFSR with an output shuffled by an SBOX. Since the generation is fast enough, the encryption coprocessor does not need to stop without prefetching. This second, lower quality randomness 604-2 can correspond to the following URND description. Additional and alternative implementation examples for generating, storing, or accessing randomized bits with different qualities of randomness are described herein.

[0105] Figure 7 shows an example method 700 for verifying the secure execution of instruction code by an encryption coprocessor. As shown, the encryption coprocessor 118 can include a plurality of registers for protecting the execution of instruction code 412. In the implementation described, two registers are shown, but one or more than two registers can be used instead. One register 702 can store the instruction count 706. Another register 704 can store the checksum 708.

[0106] In some implementations, the controller 406 can track the number of instructions of the instruction code 412 that have been executed as an instruction count 706 in the register 702. The register 702 can be implemented as an instruction counter or function as an instruction counter. Thus, the value of the instruction count 706 can represent the amount of instructions executed to perform an operation such as the encryption operation 430 (e.g., of FIG. 4). The encryption coprocessor 118 can provide the processor 202 with the amount of instructions executed as the instruction count 706.

[0107] The instruction count 706 can be provided by exposing the value in the register 702 or another register to the processor 202 (as described above with reference to FIGS. 3-1 through 3-3, for example). Additionally or alternatively, the encryption coprocessor 118 can transmit the value of the instruction count 706 to the processor 202 via the interconnect 110 or a dedicated communication path. The processor 202 can confirm that the instruction count 706 matches the expected number of instructions to be executed for a particular operation. Otherwise, the processor 202 can generate an alert.

[0108] In other implementations, the controller 406 can perform a check on the instruction code 412 to generate a checksum 708. This check can be performed, for example, using a hash operation to generate the checksum 708. If the instruction code 412 has been modified, the checksum 708 will not match the checksum known to the processor 202. The checksum 708 can be derived from all or part of the instruction code 412 currently stored in or loaded into the instruction memory 402. The checksum 708 can be generated, for example, using a cumulative CRC checksum (e.g., a 32-bit CRC-32-IEEE checksum) that is updated each time the instruction memory 402 is written to. The encryption coprocessor 118 can provide the checksum 708 to the processor 202. In some embodiments, the controller 406 can also generate a checksum 708 for the data 414 stored in the data memory 404 (e.g., of FIGS. 4 and 5). Thus, the checksum 708 can be used to jointly verify the integrity of the instruction code 412 in combination with the data 414. Alternatively, the controller 406 can generate a checksum for the data 414 separately from the instruction code 412 so that the integrity of the data 414 can be verified independently.

[0109] Checksum 708 can be provided by exposing the value in register 704 or another register to processor 202 (e.g., as described above with reference to FIGS. 3-1 through 3-3). Additionally or alternatively, encryption coprocessor 118 can send the value of checksum 708 to processor 202 via interconnect 110 or a dedicated communication path. Processor 202 can verify that checksum 708 matches the expected checksum value for a particular portion of instruction code 412. Otherwise, processor 202 can generate an alert. The security schemes of instruction count and checksum can be used separately or together. Additional and alternative implementations of instruction count and checksum security schemes are described herein.

[0110] Next, the multiply-accumulate (MAC) component will be described, followed by a description of several security-related functions. The several security-related functions include some functions that extend and / or further explain the functions described above with respect to FIGS. 4 through 7. In one example of a multiply-accumulate (MAC) device (e.g., MAC device 426 of FIG. 4), a wide integer multiplier is used to meet performance targets. However, a wide multiplication device can consume significant silicon area and can affect the operating frequency (e.g., when relatively low pipelining is employed in a particular design to reduce design complexity and / or the area targeted for attack).

[0111] The encryption coprocessor 118 can include, for example, a 64-bit wide multiplication circuit as a balance between cycle reduction and achieving frequency targets. (Depending on the use case, for example, in the case of a 128-bit wide multiplication device, it may be too slow or too costly in terms of area.) Adding a 256-bit accumulator to the encryption coprocessor 118 can reduce the operations required to perform a wider range of multiplications. The multiply-accumulate operation can be executed in one cycle. When using long multiplication, this means that the MAC device can generate and accumulate one intermediate product per cycle without the need for separate add instructions. For example, a 128-bit multiplication can be completed in 4 cycles, and a 256-bit multiplication can be completed in 16 cycles.

[0112] Various examples of security-related functions are described below. Each function described may include specific implementations listed only as examples, not limitations. Some of the security functions described are designed to counter specific threats and attack means. Therefore, each security function may include an explanation of the appropriate countermeasures. Nineteen security-related functions of the encryption coprocessor 118 are described below.

[0113] First, an integrity protection code can be implemented. To provide comprehensive integrity protection for information (e.g., data and instructions) without periodically re-encoding the information (which could be potential fault insertion points), the same integrity protection code can be used in various parts of the coprocessor, including all parts of the coprocessor. This protection can be applied, for example, to 32-bit data words, generating 39-bit encoded data that includes a 7-bit error correction code (ECC). In some cases, the protection code can be an inverted (39,32) HsiaoSEC-DEDECC. This has a minimum Hamming distance of 4 and can detect up to three errors within the 39-bit encoded word. The protection code in this example can be used to detect errors of up to three inverted bits. In such a case, error correction is not performed. In contrast to the original Hsiao code, this version can generate a code where the output (or at least a part of its bits) is inverted such that a word of all zeros (32’h0) and a word of all ones (32’h1) are not valid code words. This enables detection of attacks that set all bits to 0 or all bits to 1.

[0114] Second, an information scrambling mechanism can be implemented. To protect information, scrambling can be performed using any of a variety of scrambling algorithms. For example, a reduced-round PRINCE cipher can be used to encrypt information in an encryption coprocessor or other components of a security circuit. For example, the architecture can use a reduced-round PRINCE cipher primitive in CTR mode to encrypt data written to a memory macro (e.g., relatively weakly). In plain CTR mode, since the keystream can be "merely" XORed, the data may not be diffused. Therefore, byte-level diffusion can be performed using one or more (e.g., relatively shallow) substitution / permutation network (S&P network) layers to provide an avalanche effect within the byte. Further, to break the linear addressing space, a bijective scrambling function constructed using a (e.g., relatively shallow) substitution / permutation network and a nonce can be passed to the address. Due to the nonce, the address mapping may not be statically specified by register transfer level (RTL) encoding, and thus the address remapping can also be changed at runtime.

[0115] Third, integrity protection can be applied to one or more register files. For example, 32-bit GPRs and 256-bit WDRs can store ECC in addition to the data to detect glitches in the stored data. Detected errors (e.g., any detected error) can trigger a fatal alert. Each 32-bit data word can be protected with its respective integrity protection code. Thus, in a 256-bit WDR, each ECC can be applied individually to each 32-bit word. In some cases, the data and corresponding integrity bits can be consumed or output from the register file. If the incoming data does not have ECC added, the ECC is calculated after verifying the integrity of the incoming data and before writing the data to the register file.

[0116] Regarding the register file, corresponding ECC bits can be passed for the data read from the register file and / or the data written to the register file. Alternatively, the ECC bits can be omitted from deletion and / or data transmission to specific internal devices such as the ALU when reading from the register file. In the case of data generated by the ALU, ECC bits for the generated data can be calculated for storage (or transmission) in the register file together with the generated data.

[0117] Fourthly, integrity protection can be applied to the data memory. The width of the data memory of the encryption processor is 256 bits, but 32-bit word access aligned to 32 bits is possible in the data memory. The integrity of the data memory can be protected by an error detection code. Each 32-bit data word (aligned to 32 bits) can be protected by its respective integrity protection code. Detected errors (e.g., any detected error) can cause a fatal alert. In some cases, for example, by propagating the ECC bits and the corresponding data to various devices, components, and other circuits of the coprocessor, re-encoding of the data can be avoided.

[0118] Regarding the data memory, there is no need to re-encode the data consumed within the coprocessor. However, the integrity bits can be stored, for example, by a coprocessor that uses a load-store unit (LSU) that interfaces with the data memory. When the system bus propagates or provides the same type of ECC data, there is no need to re-encode the data accessed for reading or writing via the system bus. Here, the system bus can enable data transfer between other peripheral devices or the main processor as part of the interconnection.

[0119] Fifthly, the data memory can be scrambled, for example, using a scrambling key. The data memory of the encryption coprocessor can be scrambled to enhance anti-tampering. Also, data scrambling can make it easier to detect glitch attacks because a single-bit glitch can result in an unpredictable output due to the scrambling. The scrambling key can be changed (e.g., rotated, substituted, or modified) periodically, such as whenever at least a secure clear operation is initiated. Optionally, the encryption coprocessor can operate to reverse the scrambling operation, for example, when it receives a request for (unscrambled) data or when it is instructed to execute an operation on (unscrambled) data.

[0120] Sixthly, integrity protection can be applied to the instruction memory. The integrity of the instruction memory can be protected by an error detection code. For example, each 32-bit "data" word (aligned in 32 bits) can be protected by an integrity protection code. An error detected within the instruction code stored in the instruction memory (e.g., any detected error) can trigger a fatal alert. As described above for the data stored in the data memory, re-encoding of the instructions for regenerating the integrity code can be avoided in many situations by propagating and / or restoring the ECC bits.

[0121] Regarding the instruction memory, when the system bus does not utilize the same type of ECC data, the instruction code accessed in a read or write operation via the system bus can be re-encoded. Otherwise, the existing ECC data can be further propagated to or from the system bus. Generally, the instructions read by the decoder can perform an integrity check before use, but then the integrity data can be discarded.

[0122] Seventhly, for example, the instruction memory can be scrambled using a scrambling key to scramble the instruction codes stored in the instruction memory. Scrambling the instruction memory of the encryption coprocessor can enhance tamper resistance. Also, since a single-bit glitch can result in an unpredictable output, scrambling makes it easier to detect a glitch attack. The scrambling key can be changed (e.g., rotated, substituted, or modified) periodically, such as each time at least a secure clear operation is initiated. Optionally, the encryption coprocessor can operate to reverse the scrambling operation, for example, when receiving an instruction or command to execute an operation specified by the instruction code.

[0123] Eighthly, different levels or qualities of random number generation (RNG) can be implemented. The encryption coprocessor can utilize a source of random numbers for various purposes. Since the RNG can be used as at least part of a software enhancement scheme, a reliable and timely source of random bits can contribute to a secure processing environment. The random bits can be obtained, for example, via reading at least one register such as a control and status register (CSR) and / or a wide special-purpose register (WSR).

[0124] In some cases, two different qualities of randomness can be provided to two sources of random bits. For example, the first quality can be represented as "RND" for random bits. This RND represents relatively high-quality bits that may meet the authentication "requirements" for cryptographically strong randomness compliant with one or more standards. These RND bits can be used for key generation, etc., and can be obtained "directly" from the EDN request. The second quality can be represented as "URND" for "unrestricted" random bits. (These bits may not actually be unrestricted, but can be generated fast enough to appear as a source of substantially unrestricted random bits from the perspective of the coprocessor.) This URND represents relatively low-quality bits. These low-quality bits can be obtained, for example, from a local pseudo-random number generator (PRNG). In some cases, the PRNG may include at least one linear feedback shift register (LFSR) that is periodically reseeded from the EDN request.

[0125] In an exemplary implementation, the RND bits can be provided via a 256-bit cache. When a read to RND occurs while this cache is empty, an EDN request to fill it can be initiated quickly, but the encryption coprocessor may stop until the RND bits become available. Reading from RND can empty the cache. However, prefetching can be performed by reading from a special CSR that initiates an EDN request to fill the RND cache. If a read to RND occurs after an appropriate time after the prefetch request, the encryption coprocessor does not need to stop. Generally, due to the speed at which the randomized bits can be refilled, reading from URND does not block the encryption coprocessor.

[0126] In general, the RNG method can include one or more of several different modes. For example, it is possible to provide a separate 32-bit random number source for the base ISA, or to use a 256-bit random number source by discarding the extra bits. The LFSR can be reseeded by software executed under or on the control of the main processor or the encryption coprocessor. The reseeding can be done, for example, at periodic time intervals or URND access intervals. In some cases, software may control the refill and / or flush of the RND cache. Alternatively or additionally, the RND cache may be flushed and / or refilled in response to the start or reset of the encryption coprocessor.

[0127] Ninthly, the state of the encryption coprocessor (e.g., stored "operation" information) can be hardened against attacks. If state machines or other state values that affect or can affect the execution of the encryption coprocessor are held in registers, these locations can be hardened against glitches. The following table (Table 1) identifies examples of the state of the encryption coprocessor and corresponding hardening strategies applicable to various implementations to protect the corresponding state information.

[0128]

Table 1

[0129] Tenthly, the encryption coprocessor can be made able to clear its information (e.g., state). In relation to or as part of state hardening, the encryption coprocessor can provide a mechanism to securely clear the information it stores (e.g., the state it stores), including the instruction memory and the data memory. This mechanism can be implemented as a superset of other "secure clear" mechanisms that may include clearing the data memory, clearing the instruction memory, clearing the internal memory, combinations thereof, etc.

[0130] A secure clear mechanism can be triggered by host software via, for example, a bus interface. This mechanism can be automatically initiated in certain situations where it is determined that the information stored by the encryption coprocessor may be, or has been, compromised. For example, the encryption coprocessor can initiate a secure clear, such as a full secure clear, in the following situations. One is that the life cycle controller can request a secure clear through an escalation signal. The second is that a fatal alert can be issued. In the latter case, a secure clear can be executed as a local repair action. In other situations, software can trigger an information clear by writing to registers, such as writing "3'b111" to the relevant registers and setting individual information clear bits, as described below.

[0131] Eleventh, the encryption coprocessor can enable the safe clearing of the data memory. The data memory of the encryption coprocessor can be used to store confidential data during operation or to exchange such data with the host processor. As described herein, a mechanism can be provided to safely clear the data memory upon request. Clearing of the data memory can be performed by safely replacing the scramble key of the data memory. This renders the scrambled data stored in the data memory unusable.

[0132] As an example, key exchange can be implemented as a two - part process. In the first part, the encryption coprocessor overwrites a scramble key (e.g., 128 bits) of a data memory scramble primitive with randomness such as bits from a local LFSR. This action is time - critical and can be completed in just one cycle. In the second part, the encryption coprocessor requests one or more new scramble parameters from a module that provides the scramble variable or key. This request may take multiple cycles to complete. In some cases, software can initiate a secure data clear operation by writing to a register, such as writing a "1" to a clear data memory register field.

[0133] Twelfthly, the encryption coprocessor can be made to securely clear the instruction memory. The instruction memory within the encryption coprocessor can contain application code or instruction code. Since the code may contain secrets, these can also be regarded as assets that can be protected. Thus, a mechanism can be provided to securely clear the instruction memory upon request. Clearing of the instruction memory can be performed by securely exchanging an instruction memory scramble key or a code scramble key that makes the scrambled instruction code stored in the instruction memory unusable.

[0134] As an example, key exchange can be implemented as a two-part process. In the first part, the encryption coprocessor overwrites a scramble key (e.g., 128 bits) of an instruction memory scramble primitive with randomness such as bits from a local LFSR. This action is time-critical and can be completed in just one cycle. In the second part, the encryption coprocessor requests one or more new scramble parameters from a module that provides a scramble variable or key. This request can take multiple cycles to complete. In some cases, software can initiate a secure instruction code clear operation by writing to a register, such as writing a "1" to a clear instruction memory register field.

[0135] Thirteenthly, the encryption coprocessor can be made to securely clear its state. The encryption coprocessor can provide a mechanism for securely erasing its general internal state. This can exclude the target state erase instructions and data memory. The erase can target part of the state or "all" of the internal state. The next state can be erased with random data such as data from a local LFSR. The state can include register files such as GPRs and WDRs (e.g., general-purpose registers and wide data registers). The state can also include an accumulator register, which may be accessible through the ACC WSR. The state can further include special-purpose registers writable by software, such as flag registers and mode registers.

[0136] Furthermore, as part of clearing the internal state, loop and / or call stack pointers can be reset. In some cases, it may take multiple cycles to securely erase all of the internal state. Software can initiate a data-protected erase of the state information by writing to a register corresponding to the clearing of the internal state. The state can be cleared in response to the completion of one or more operations (e.g., a state clear trigger is issued).

[0137] Fourteenth, unused data paths and / or control paths can be made "blank". Blanketing, which may also be referred to as "scrubbing", can be used to prevent power or electromagnetic signatures from leaking due to data unrelated to the instructions being executed. Using this technique, the encryption coprocessor can blank signals such as unused register file addresses and unused data paths to a constant or fixed / static value that can be zero or a non-zero value via a functional device. This blanketing can prevent, or at least reduce the likelihood of, power or electromagnetic signatures from data unrelated to the instructions being executed from being detectable. This technique can be implemented with a slight reduction in area cost and timing impact. Blanketing can be selectively applied to different data and / or control paths.

[0138] Fifteenth, a checksum can be used to protect executable instructions based on the instruction code loaded into the instruction memory. The encryption coprocessor can calculate a checksum for the instruction code written to the instruction memory. The encryption coprocessor can also make this checksum available to the host software via a bus-accessible CSR or the like. In this way, the checksum can be made available within a register specified for host processor search. Thus, this checksum can be used by the host processor as a relatively lightweight integrity check to confirm that the instruction code written to the encryption coprocessor has been correctly received and stored.

[0139] The checksum can be calculated in any of a plurality of different ways. For example, a 32-bit cyclic redundancy check (CRC) (CRC32) or another checksum can be calculated on the fly when the instruction code is written to the instruction memory. Thus, the checksum may depend on the order of the received instruction code data. Additionally or alternatively, the instruction code can be read sequentially in response to a checksum request, but this process takes more time to provide the checksum and / or may result in processing delays.

[0140] Regarding implementations that provide a checksum for the instruction code, exemplary aspects can include a read-back of data from the main processor. Aspects can also include loading a relatively simple checksum (e.g., CRC32) calculated based on an instruction written by the main processor into a CSR. The main processor can read the checksum from a register and compare it to the checksum calculated by the main processor or a checksum known to the main processor. The encryption coprocessor can additionally or alternatively calculate a checksum of the data stored in the data memory. Thus, the encryption coprocessor can generate two individual checksums or a combined checksum. Aspects can further include incorporating ROM code into the encryption coprocessor to enable the execution of stronger integrity checks.

[0141] Sixteenth, the executed instruction count can be provided to the host software. The encryption coprocessor can count the number or amount of instructions executed since operation began. The encryption coprocessor can also provide the count to the host software via a designated register or the like. The host software can use the number of instructions executed to detect some forms of unexpected execution of an application being run by the encryption coprocessor, such as early termination of execution. The host software may have the responsibility of interpreting this numerical value appropriately. Some algorithms executed on the encryption coprocessor can execute a normal or constant amount of instructions (e.g., many encryption and decryption algorithms). However, in other algorithms, the execution time or the number of instructions executed can be more variable (such as RSA key generation).

[0142] Seventeenth, the instruction decoder can be replicated. The encryption coprocessor can include a replicated decoding logic and at least a partial replication of the control logic. One of the replicated logic blocks can output an inverted signal. In some cases, the signal inversion is achieved using multiple NOT gates at the output of the replicated blocks such that the logical implementation of each block is different. When a control signal reaches the execution block, the circuit can check and confirm that the replicated signals are inverted with respect to each other. Otherwise, the check circuit can issue an alert.

[0143] The replication of the decoder block can strengthen the encryption coprocessor against fault insertion attacks on the decoding logic and / or control logic when ECC protection for the instruction word is discarded. A fault inserted into one of the replicated blocks will become apparent or detectable due to a mismatch in the resulting control signals that are not inverse versions of each other. Since the logical implementation of each block can be different, two separate inserted faults are required to change the control signal without triggering a confirmation alert.

[0144] Eighteenth, the computing resources can be duplicated. The encryption coprocessor can have a duplicated arithmetic unit, and the circuit can check that both outputs match for each calculation. This can form a countermeasure against glitch attacks. However, the duplicated ALU can consume a significant amount of area and power by duplicating the multiply-accumulate (MAC) unit. Alternatively, software can also assist in detecting attacks by repeating more important calculations instead and checking that the results match.

[0145] Nineteenth, the integrity of the instruction flow can be implemented. The integrity of the instruction flow can ensure that instructions are executed as intended by the software creator. The integrity of the instruction flow includes control flow integrity (CFI) as a special case, but the integrity of the instruction flow also includes instructions within a basic block.

[0146] Although the methods, techniques, and hardware for a secure encryption coprocessor have been described in general, the description here moves on to an exemplary method.

[0147] Example methods of a secure encryption coprocessor The exemplary method will be described below with reference to the flowcharts of FIGS. 8-13. FIG. 8 is a flowchart 800 showing an exemplary process of an apparatus for providing security to an encryption coprocessor. Flowchart 800 includes six blocks 802-812. The operations of the exemplary process can be executed by a security circuit 106 (e.g., of FIGS. 1 and 2). For example, these operations can be executed by a processor 202 and an encryption coprocessor 118 (e.g., of FIGS. 1 and 2).

[0148] In block 802, the processor determines the encryption operation to be executed. For example, the processor 202 can determine the encryption operation 430 to be executed. The encryption operation 430 can include, for example, a symmetric or asymmetric encryption operation that enables or supports any of the security-related functions of the security circuit 106 described herein.

[0149] In block 804, the processor sends a request to execute an encryption operation to the encryption coprocessor. For example, the processor 202 can send a request to execute the encryption operation 430 to the encryption coprocessor 118. In some cases, the processor 202 can load instruction codes into at least one register that is part of or associated with the encryption coprocessor 118. If the encryption operation 430 uses inputs, the processor 202 can also load one or more inputs into one or more registers. Examples of register-based communication are described herein with reference to FIGS. 3-1 through 3-3. Additionally or alternatively, the processor 202 can drive signaling on the interconnect 110 or a communication path dedicated to processor-encryption coprocessor communication to send a request to execute the encryption operation 430.

[0150] In block 806, the encryption coprocessor receives a request to execute an encryption operation. For example, the encryption coprocessor 118 can receive a request to execute the encryption operation 430. The reception of the request can be implemented by a receiving-side operation corresponding to any of the transmission options described above with reference to block 804. For example, the controller 406 of the encryption coprocessor 118 can detect that a new operation code has been loaded into a register.

[0151] In block 808, the encryption coprocessor executes an encryption operation on the data using the instruction code and intermediate values and obtains a result. For example, the encryption coprocessor 118 can execute the encryption operation 430 on the data 414 using the instruction code 412 and the intermediate value 428 and obtain the result 432. Here, the controller 406 can execute the instruction code 412 based on the data 414 that generates at least one intermediate value 428 while calculating the result 432. The result 432 can be a numerical value (e.g., a key) and / or a positive or negative indication.

[0152] In block 810, the encryption coprocessor protects at least one of data, intermediate values, or instruction codes from unauthorized access. For example, the encryption coprocessor 118 can protect at least one of data 414, intermediate value 428, or instruction code 412 from unauthorized access. Thus, the encryption coprocessor 118 can implement any one or more of the methods described herein with reference to FIGS. 5-7 and / or any one or more of the 19 techniques described herein, including the techniques described above as security-related functions in the subsection entitled "Examples of Methods, Techniques, and Hardware for Secure Encryption Coprocessors". Examples of methods can include securely erasing information (e.g., as described with reference to FIG. 5), using randomized bits with different qualities of randomness via two or more registers to support security-related operations (e.g., as described with reference to FIG. 6), and protecting the execution of instruction codes using at least one of an instruction count or checksum generated for the instruction codes (e.g., as described with reference to FIG. 7). These methods and techniques can be used individually or in combination in any combination.

[0153] In block 812, the encryption coprocessor provides the result to the processor. For example, the encryption coprocessor 118 can provide the result 432 to the processor 202. This can be accomplished by storing the result 432 in a register readable by the processor 202, driving the result 432 onto the interconnect 110 or a dedicated bus, or notifying by positive or negative indications, combinations thereof, etc.

[0154] FIG. 9 is a flowchart 900 showing an exemplary process for an encryption coprocessor to protect a stored state such as digital information. Flowchart 900 includes four blocks 902-908. The operations of the exemplary process can be performed by a security circuit 106 (e.g., of FIGS. 1 and 2). For example, the operations can be at least partially performed by a controller 406 (e.g., of FIGS. 4 and 5) of an encryption coprocessor 118 (e.g., of FIGS. 1, 2, and 4).

[0155] In block 902, the encryption coprocessor obtains digital information. For example, encryption coprocessor 118 can obtain digital information by receiving digital information from another component or by generating it internally. The digital information can include, for example, instruction code 412, data 414, or at least one intermediate value 428 (or other state information).

[0156] In block 904, the encryption coprocessor scrambles the digital information using at least one scramble key to generate scrambled digital information. For example, encryption coprocessor 118 can scramble the digital information using at least one scramble key 502 or 504 to generate scrambled digital information. Thus, the scrambled digital information can include a scrambled version of instruction code 412 and / or a scrambled version of data 414.

[0157] At block 906, the encryption coprocessor stores the scrambled digital information in at least one memory. For example, the encryption coprocessor 118 can store the scrambled digital information in at least one memory such as the instruction memory 402 or the data memory 404. In some cases, the controller 406 can store the scrambled digital information when it is received or internally generated. In other cases, the controller 406 can read the digital information from the memory, scramble the digital information to generate the scrambled digital information, and then write the scrambled digital information back to the same memory.

[0158] At block 908, the encryption coprocessor prevents access to the digital information by changing at least one scrambling key. For example, the encryption coprocessor 118 can prevent access to digital information (such as instruction code 412 or data 414) by changing at least one scrambling key (such as the code scrambling key 502 or the data scrambling key 504 respectively). To do so, the controller 406 can replace at least a part of the scrambling key with random bits. Although an attacker may still be able to read the scrambled digital information from at least one memory, since the scrambling key is effectively deleted by changing the bits in the register where the scrambling key is stored, access to the "original" unscrampled digital information is not possible.

[0159] FIG. 10 is a flowchart 1000 showing an example of a process in which an encryption coprocessor uses random values having different levels of randomness quality to efficiently protect the security of related encryption operations. The flowchart 1000 includes three blocks 1002-1006. The operations of the exemplary process can be performed by a security circuit 106 (e.g., of FIGS. 1 and 2). For example, the operations can be at least partially performed by a controller 406 (e.g., of FIGS. 4 and 6) of an encryption coprocessor 118 (e.g., of FIGS. 1, 2, and 4).

[0160] In block 1002, the encryption coprocessor stores a plurality of first bits corresponding to a first randomness quality in a first register. For example, the encryption coprocessor 118 can store a plurality of first bits 602-1 corresponding to a first randomness quality 604-1 in a first register 408-1. For example, the controller 406 can obtain a plurality of first bits 602-1 from a non-deterministic source of random numbers and load the plurality of first bits 602-1 into the first register 408-1. In some cases, such a source can use an analog-based mechanism that uses random or unpredictable physical characteristics to generate the randomized bits of the first register 408-1.

[0161] In block 1004, the encryption coprocessor stores a plurality of second bits corresponding to a second randomness quality different from the first randomness quality in a second register. For example, the encryption coprocessor 118 can store a plurality of second bits 602-2 corresponding to a second randomness quality 604-2 different from the first randomness quality 604-1 in the second register 408-2. Here, the controller 406 can obtain a plurality of second bits 602-2 from a deterministic source of random numbers. In some cases, such a source may use a digital-based mechanism, and the local pseudo-random number generator (PRNG) can have one or more linear feedback shift registers (LFSRs) for digitally generating additional randomization bits and is used to generate the randomization bits of the second register 408-2.

[0162] In block 1006, the encryption coprocessor selectively retrieves a plurality of first bits from the first register or a plurality of second bits from the second register based on at least one encryption operation. For example, the encryption coprocessor can selectively retrieve a plurality of first bits 602-1 from the first register 408-1 or a plurality of second bits 602-2 from the second register 408-2 based on at least one encryption operation. As described herein, relatively more confidential encryption operations can be associated with a higher randomness quality (e.g., to meet asymmetric key generation or encryption standards), and relatively less confidential encryption operations can be associated with a lower randomness quality. Thus, the controller 406 can retrieve the randomized bits from the selected register 408 based on the confidentiality of the corresponding encryption operation being performed.

[0163] FIG. 11 is a flowchart 1100 showing an exemplary process for an encryption coprocessor to protect an encryption operation by enabling verification of instruction codes. Flowchart 1100 includes three blocks 1102-1106. The operations of the exemplary process can be performed by the security circuit 106 (e.g., of FIGS. 1 and 2). For example, the operations can be at least partially performed by the controller 406 (e.g., of FIGS. 4 and 7) of the encryption coprocessor 118 (e.g., of FIGS. 1, 2, and 4).

[0164] In block 1102, the encryption coprocessor obtains an instruction code. For example, the encryption coprocessor 118 can obtain the instruction code 412. In some cases, the encryption coprocessor 118 can receive the instruction code 412 from the host processor 202 via the interconnect 110 or a dedicated path, along with a request to perform an encryption operation. In other cases, the controller 406 can retrieve the instruction code 412 from a memory such as the instruction memory 402 of the encryption coprocessor 118.

[0165] In block 1104, the encryption coprocessor generates at least one parameter based on the instruction code. For example, the encryption coprocessor 118 can generate at least one parameter (e.g., a numerical value such as the instruction count 706 or the checksum 708) based on the instruction code 412. An implementation example for generating the checksum 708 is described below with reference to FIG. 12, and an implementation example for generating the instruction count 706 is described below with reference to FIG. 13.

[0166] In block 1106, the encryption coprocessor provides at least one parameter to another component so that the other component can verify the instruction code for the encryption coprocessor. For example, the encryption coprocessor 118 can provide at least one parameter to another component (e.g., the processor 202 or another peripheral device 250 if the encryption coprocessor 118 is implemented as part of the security circuit 106 shown in FIG. 2). By providing access to at least one parameter to another component, the encryption coprocessor 118 can enable the other component to verify the instruction code 412 for the encryption coprocessor 118. This can be achieved by the encryption coprocessor 118 transmitting at least one parameter to another component (e.g., via a shared interconnect or other bus, or via a dedicated path) or by storing at least one parameter in at least one register that is exposed to another component.

[0167] Another component such as the processor 202 can receive or retrieve at least one parameter and perform a verification operation by comparing the at least one parameter from the encryption coprocessor 118 with another value determined by the other component or obtained by the other component from a source other than the encryption coprocessor 118. For example, since at least one parameter indicates the nexus between the instruction code 412 and the encryption coprocessor 118, the verification may be performed on the encryption coprocessor 118. The nexus may be related to which instructions are stored as the instruction code 412 in the instruction memory 402 of the encryption coprocessor 118, which instructions of the instruction code 412 are executed by the encryption coprocessor 118, etc. Verification may include comparing a parameter from the encryption coprocessor 118 with another parameter and generating an alert and / or taking another protective measure if the two parameter values do not match.

[0168] FIG. 12 is a flowchart 1200 showing an exemplary process for an encryption coprocessor to protect an encryption operation by enabling verification of the integrity of an instruction code. The flowchart 1200 includes three blocks 1202-1206. The operations of the exemplary process can be performed by a security circuit 106 (e.g., of FIGS. 1 and 2). For example, these operations can be performed by a controller 406 (e.g., of FIGS. 4 and 7) of an encryption coprocessor 118 (e.g., of FIGS. 1, 2, and 4).

[0169] In block 1202, the encryption coprocessor obtains an instruction code. For example, the encryption coprocessor 118 can obtain an instruction code 412. An exemplary approach for obtaining the instruction code 412 was described above with reference to block 1102 of FIG. 11.

[0170] In block 1204, the encryption coprocessor calculates a checksum for the instruction code. For example, the encryption coprocessor 118 can calculate a checksum 708 for the instruction code 412. For example, the controller 406 can apply a hash function to the instruction code 412 to calculate the checksum 708 while receiving the instruction code 412 or by reading the instruction code 412 from the instruction memory 402. The calculation can further or alternatively include calculating a checksum for data 414 stored in the data memory 404. In some such cases, the calculation can generate first and second checksums corresponding to the instruction code 412 and the data 414, respectively. In other such cases, the calculation can generate a combined or cumulative checksum that is calculated for the data 414 and the instruction code 412 together.

[0171] In block 1206, the encryption coprocessor provides a checksum to another component so that the other component can use the checksum to verify the integrity of the instruction code in the encryption coprocessor. For example, the encryption coprocessor 118 can provide the checksum 708 to another component (e.g., the processor 202) so that the other component can use the checksum 708 to verify the integrity of the instruction code 412 located in the encryption coprocessor 118. An exemplary approach for providing the checksum 708 to another component was described above with reference to block 1106 of FIG. 11. To perform the integrity check, the other component can compare the checksum 708 from the encryption coprocessor 118 with a checksum calculated by the other component or obtained independently from the encryption coprocessor 118. The provided and compared checksum 708 can be related to the instruction code 412 (individually), the data 414 (individually), or the instruction code 412 and the data 414 (together).

[0172] FIG. 13 is a flowchart 1300 showing an exemplary process for an encryption coprocessor to protect an encryption operation by enabling verification of the execution of instruction code. The flowchart 1300 includes three blocks 1302-1306. The operations of the exemplary process can be performed by a security circuit 106 (e.g., of FIGS. 1 and 2). For example, these operations may be performed by a controller 406 (e.g., of FIGS. 4 and 7) of the encryption coprocessor 118 (e.g., of FIGS. 1, 2, and 4).

[0173] In block 1302, the encryption coprocessor obtains an instruction code. For example, the encryption coprocessor 118 can obtain the instruction code 412. An exemplary approach for obtaining the instruction code 412 was described above with reference to block 1102 of FIG. 11.

[0174] In block 1304, the encryption coprocessor tracks the amount of instructions of the executed instruction code and generates an instruction count. For example, the encryption coprocessor 118 can track the amount of instructions of the instruction code 412 that are executed and generate an instruction count 706. For example, the controller 406 can increment the value in the instruction count register 702 in response to each instruction of the instruction code 412 that is executed to perform the requested encryption operation.

[0175] In block 1306, the encryption coprocessor provides the instruction count to another component so that the other component can use the instruction count to verify the execution of the instruction code by the encryption coprocessor. For example, the encryption coprocessor 118 can provide the instruction count 706 to another component (e.g., the processor 202) so that the other component can use the instruction count 706 to verify the execution of the instruction code 412 by the encryption coprocessor 118. An exemplary approach for providing the instruction count 706 to another component has been described above with reference to block 1106 of FIG. 11. To perform the execution verification, the other component can compare the instruction count 706 from the encryption coprocessor 118 with an instruction count that the other component determines (e.g., has knowledge of) or otherwise obtains independently from the encryption coprocessor 118. If the two counts do not match, the other component can take measures such as invalidating the current encryption operation and / or making all states within the encryption coprocessor 118 unreadable.

[0176] Aspects of these methods can be implemented, for example, in hardware (such as fixed logic circuitry, a controller, a finite state machine, or a processor in conjunction with memory), firmware, software, or some combination thereof. This method can be realized using one or more of the devices or components shown in FIGS. 1 through 7 and 14. These components can be further divided or combined. The devices and components in these figures generally represent hardware, firmware, software, or some combination thereof, such as electronic devices, PCBs, packaged modules, IC chips, components, or circuits. Thus, these figures show some of the many possible systems or devices that can implement the described methods.

[0177] With respect to the methods and associated flowcharts described herein, the order in which operations are shown and / or described is not intended to be construed as limiting. Instead, any number or combination of the described method operations can be combined in any order, such as combining operations from different flowcharts into one or more methods, to implement a particular method or alternative method. Operations can be omitted from or added to the described methods. Further, the described operations can be implemented fully or partially in overlapping fashion.

[0178] Aspects and Implementation Examples of a Secure Encryption Coprocessor Some exemplary aspects and implementations will be described below.

[0179] Exemplary Aspect 1: An apparatus for secure encryption co - processing, comprising an interconnect and a processor coupled to the interconnect, the processor being configured to determine an encryption operation to be executed and transmit a request to execute the encryption operation, the apparatus further comprising an encryption coprocessor coupled to the interconnect, the encryption coprocessor being configured to receive a request to execute an encryption operation from the processor and use an instruction code (for example, the instruction code may already exist in the encryption coprocessor at the time of receiving the request or is loaded after and / or in response to the request) and an intermediate value (the intermediate value may be, for example, a value calculated by the encryption processor before receiving the request and / or as part of processing the request and may not have been previously output by the encryption processor) to execute the encryption operation using data (for example, data received by the encryption processor from the processor (for example, as part of the request) or data previously generated within the encryption processor), obtain a result, protect at least one of the data, the intermediate value, or the instruction code from unauthorized access, and provide the result to the processor.

[0180] Exemplary Aspect 2: The apparatus of Exemplary Aspect 1, wherein the encryption coprocessor is configured to protect information stored in at least one memory by changing at least one scrambling key used to scramble the information stored in the at least one memory.

[0181] Exemplary Aspect 3: The apparatus of Exemplary Aspect 1 or Exemplary Aspect 2, wherein the at least one memory includes a data memory and the at least one scrambling key includes a data scrambling key used to scramble data stored in the data memory. This may be at least part of the protection of the instruction memory specified by Exemplary Aspect 1.

[0182] Exemplary Aspect 4: An apparatus according to any one of the foregoing exemplary aspects, wherein at least one memory comprises an instruction memory and at least one scrambling key includes a code scrambling key used to scramble instruction codes stored in the instruction memory. This can also be at least part of the protection of the instruction memory specified by Exemplary Aspect 1.

[0183] Exemplary Aspect 5: An apparatus according to any one of the foregoing exemplary aspects, wherein the encryption coprocessor is configured to protect an intermediate value by overwriting at least one register with random bits, and the intermediate value corresponds to state information. This can further be at least part of the protection of the instruction memory specified by Exemplary Aspect 1.

[0184] Exemplary Aspect 6: The encryption coprocessor is configured to perform secure erasure by overwriting at least one register with random bits and overwriting the random bits in at least one register with a constant (e.g., a fixed or static value such as zero or a non-zero value including one from a random constant stored in the RTL netlist of the design). This can also be at least part of the protection referred to by Exemplary Aspect 1 when the register stores at least one of data, intermediate values, or instruction codes. Thus, the protection of at least one of the data, intermediate values, or instruction codes referred to in Exemplary Aspect 1 is, for at least one of the data, intermediate values, or instruction codes, (i) generating a scramble key and using the generated scramble key to scramble at least one of the data, intermediate values, or instruction codes stored in the encryption coprocessor (e.g., data if stored in the data memory of the encryption coprocessor and / or instruction code if stored in the instruction memory of the encryption processor), or (ii) performing at least one action selected from the group consisting of overwriting at least one of the data, intermediate values, or instruction codes.

[0185] Exemplary Aspect 7: The encryption coprocessor includes a first register configured to store a plurality of first bits corresponding to a first quality of randomness and a second register configured to store a plurality of second bits corresponding to a second quality of randomness, of any one of the foregoing exemplary aspects.

[0186] Exemplary Aspect 8: The encryption coprocessor is configured to selectively retrieve a plurality of first bits from the first register or selectively retrieve a plurality of second bits from the second register based on a quality of randomness (or "randomness quality") associated with the encryption operation, of any one of the foregoing exemplary aspects.

[0187] Exemplary Aspect 9: An apparatus according to any one of the foregoing exemplary aspects, wherein a first randomness quality is higher than a second randomness quality, a plurality of first bits correspond to a non-deterministic source of random numbers, and a plurality of second bits correspond to a deterministic source of random numbers.

[0188] Exemplary Aspect 10: An apparatus according to any one of the foregoing exemplary aspects, wherein the encryption coprocessor is configured to prefetch a plurality of first bits into a first register before the plurality of first bits are to be used.

[0189] Exemplary Aspect 11: An apparatus according to any one of the foregoing exemplary aspects, wherein the encryption coprocessor is configured to generate a checksum for instruction code associated with an instruction memory and provide the checksum to the processor.

[0190] Exemplary Aspect 12: An apparatus according to any one of the foregoing exemplary aspects, wherein the encryption coprocessor includes an instruction counter, and the encryption coprocessor is configured to track an amount of executed instructions of the instruction code via the instruction counter and provide the amount of executed instructions to the processor.

[0191] Exemplary Aspect 13: An apparatus according to any one of the foregoing exemplary aspects, wherein the apparatus includes a mobile device (e.g., a device selected from the group consisting of a tablet computer, a mobile phone, and a laptop computer), and the mobile device includes an integrated circuit including an interconnect, a processor, and an encryption coprocessor.

[0192] Exemplary Aspect 14: A method for an apparatus for providing secure encryption co - processing, the apparatus including a processor coupled to an encryption coprocessor via an interconnect, the method including the processor determining an encryption operation to be executed, the processor sending a request to execute the encryption operation to the encryption coprocessor, the encryption coprocessor receiving the request to execute the encryption operation, the encryption coprocessor using instruction code (e.g., the instruction code may already exist in the encryption coprocessor when the request is received or is loaded after and / or in response to the request) and intermediate values (the intermediate values may be values calculated by the encryption processor, for example, before receiving the request and / or as part of processing the request, and may not have been previously output by the encryption processor) to perform the encryption operation on data (e.g., data received by the encryption processor from a processor etc. (e.g., as part of the request) or data previously generated within the encryption processor) to obtain a result, the encryption coprocessor protecting at least one of the data, intermediate values, or instruction code from unauthorized access, and the encryption coprocessor providing the result to the processor.

[0193] Exemplary Aspect 15: A method implemented by the method of Exemplary Aspect 14 or any one of the exemplary aspects of the aforementioned apparatus, further including the encryption coprocessor protecting information stored in at least one memory by changing at least one scrambling key used to scramble the information stored in the at least one memory.

[0194] Exemplary Aspect 16: A method implemented by any one of Exemplary Aspect 14, Exemplary Aspect 15, or the exemplary aspects of the aforementioned apparatus, further including the encryption coprocessor selectively retrieving a plurality of first bits from a first register or a plurality of second bits from a second register based on a quality of randomness (or "randomness quality") associated with the encryption operation.

[0195] Exemplary Embodiment 17: A method for an encryption coprocessor, comprising obtaining digital information in the encryption coprocessor, generating scrambled digital information by the encryption coprocessor scrambling the digital information using at least one scrambling key, storing the scrambled digital information in at least one memory by the encryption coprocessor, and preventing access to the digital information by the encryption coprocessor changing at least one scrambling key.

[0196] Exemplary Embodiment 18: The method of Exemplary Embodiment 17, wherein the digital information includes data, the at least one scrambling key includes a data scrambling key, the scrambled digital information includes scrambled data, and the at least one memory includes a data memory.

[0197] Exemplary Embodiment 19: The method of Exemplary Embodiment 17 or Exemplary Embodiment 18, wherein the digital information includes instruction codes, the at least one scrambling key includes a code scrambling key, the scrambled digital information includes scrambled instruction codes, and the at least one memory includes an instruction memory.

[0198] Exemplary Embodiment 20: The method of any one of Exemplary Embodiments 17 to 19, wherein the at least one scrambling key is stored in at least one key register, and preventing access includes overwriting the at least one key register with random bits.

[0199] Exemplary Embodiment 21: The method of any one of Exemplary Embodiments 17 to 20, further comprising preventing access to an intermediate value stored in at least one register by overwriting the at least one register with random bits.

[0200] Exemplary Aspect 22: The method according to Exemplary Aspect 20 or Exemplary Aspect 21, further comprising performing secure erasure by overwriting random bits in at least one key register or at least one register with a constant value.

[0201] Exemplary Aspect 23: Obtaining includes receiving digital information from a host processor, and the host processor and the encryption coprocessor include at least a part of a security circuit for at least one integrated circuit, the method according to any one of Exemplary Aspects 17 to 22.

[0202] Exemplary Aspect 24: A method for an encryption coprocessor, the encryption coprocessor storing a plurality of first bits corresponding to a first randomness quality in a first register, the encryption coprocessor storing a plurality of second bits corresponding to a second randomness quality different from the first randomness quality in a second register, and the encryption coprocessor selectively retrieving a plurality of first bits from the first register or a plurality of second bits from the second register based on at least one encryption operation.

[0203] Exemplary Aspect 25: Selectively retrieving includes selectively retrieving a plurality of first bits from the first register or selectively retrieving a plurality of second bits from the second register based on a randomness quality associated with at least one encryption operation, the method according to Exemplary Aspect 24.

[0204] Exemplary Aspect 26: The first randomness quality is higher than the second randomness quality, and the method further includes obtaining a plurality of first bits from a non-deterministic source of random numbers and obtaining a plurality of second bits from a deterministic source of random numbers, the method according to Exemplary Aspect 24 or Exemplary Aspect 25.

[0205] Exemplary Aspect 27: The method of Exemplary Aspect 26, wherein the non-deterministic source of random numbers includes an analog-based source, and the deterministic source of random numbers includes a digital-based source including a pseudo-random number generator.

[0206] Exemplary Aspect 28: The method of any one of Exemplary Aspects 24 to 27, further including prefetching a plurality of first bits into a first register before the plurality of first bits are used.

[0207] Exemplary Aspect 29: A method for an encryption coprocessor, including obtaining instruction code in the encryption coprocessor, the encryption coprocessor generating at least one parameter based on the instruction code, and the encryption coprocessor providing the at least one parameter to another component so that the other component can verify the instruction code against the encryption coprocessor.

[0208] Exemplary Aspect 30: The method of Exemplary Aspect 29, wherein the at least one parameter includes a checksum, generating includes calculating a checksum for the instruction code, and providing includes providing the checksum to another component so that the other component can use the checksum to verify the integrity of the instruction code in the encryption coprocessor. Generating can further (or alternatively) include calculating a checksum of data stored in a data memory. Thus, generating may include generating first and second checksums corresponding to the instruction code and the data respectively, or generating may include generating a combined or cumulative checksum calculated together for the data and the instruction code.

[0209] Exemplary Aspect 31: At least one parameter includes an instruction count, and generating includes generating the instruction count by tracking the amount of executed instructions of the instruction code, and providing includes providing the instruction count to other components so that the other components can use the instruction count to verify the execution of the instruction code by the encryption coprocessor, the method of Exemplary Aspect 29 or Exemplary Aspect 30.

[0210] Exemplary Aspect 32: Providing includes exposing at least one parameter in a register accessible by other components including a host processor, and the host processor and the encryption coprocessor include at least a part of the security circuit of the integrated circuit, the method of any one of Exemplary Aspects 29 to 31.

[0211] Exemplary Aspect 33: An apparatus comprising an encryption coprocessor configured to execute the method of any one of Exemplary Aspects 17 to 32.

[0212] Examples of Electronic Devices for Secure Encryption Coprocessors FIG. 14 shows various components of an exemplary electronic device 1400 that can implement a secure encryption coprocessor 118 in accordance with one or more of the described aspects. The electronic device 1400 can be implemented in any form of a consumer, computer, portable, user, server, communication, telephone, navigation, game, audio, camera, messaging, media playback, and / or other type of electronic device 1400 such as the smartphone shown in FIG. 1 as device 102, as any one or combination of fixed, mobile, stand-alone, or embedded devices. One or more of the illustrated components can be realized as individual components or as integrated components on at least one integrated circuit of the electronic device 1400.

[0213] The electronic device 1400 can include one or more communication transceivers 1402 that enable wired and / or wireless communication of device data 1404 such as received data, transmitted data, or other information identified above. Exemplary communication transceivers 1402 include a Near Field Communication (NFC) transceiver, wireless Personal Area Network (PAN) (WPAN) wireless compliant with various IEEE802.15 (Bluetooth (R)) standards, wireless Local Area Network (LAN) (WLAN) wireless compliant with any of various IEEE802.11 (WiFi (R)) standards, wireless Wide Area Network (WAN) (WWAN) wireless for mobile phones (e.g., compliant with 3GPP (R) standards), wireless Metropolitan Area Network (MAN) (WMAN) wireless compliant with various IEEE802.16 (WiMAX (R)) standards, an infrared (IR) transceiver compliant with the Infrared Data Association (IrDA) protocol, and a wired Local Area Network (LAN) (WLAN) Ethernet (R) transceiver.

[0214] The electronic device 1400 may also include one or more data input ports 1406 that can receive any type of data, media content, and / or other inputs, such as, for example, user-selectable inputs, messages, applications, music, television content, recorded video content, and other types of audio, video, and / or image data received from content and / or data sources, including sensors such as microphones and cameras. The data input ports 1406 can include USB ports, coaxial cable ports, optical fiber interconnects or optical fiber ports for cable wiring, and other serial or parallel connectors (including internal connectors) for flash memory, DVDs, CDs, etc. These data input ports 1406 can be used to couple the electronic device to components, peripherals, or accessories such as keyboards, microphones, cameras, or other sensors.

[0215] The electronic device 1400 in this example includes at least one processor 1408 (e.g., any one or more of an application processor, a microprocessor, a digital signal processor (DSP), a controller, etc.), which can include a system combining a processor and a memory (e.g., implemented as part of a system-on-chip (SoC)) that processes (e.g., executes) computer-executable instructions to control the operation of the device. The processor 1408 can be implemented as an application processor, an embedded controller, a microcontroller, a security processor, an artificial intelligence (AI) accelerator, etc. Generally, the processor or processing system can be implemented at least partially in hardware, which can include integrated circuits or on-chip systems, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), and other components of other implementations in silicon and / or other materials.

[0216] Alternatively or additionally, the electronic device 1400 can be implemented in any one or combination of electronic circuits, which can include software, hardware, firmware, or fixed logic circuits implemented in relation to processing and control circuits, generally shown as 1410 (as electronic circuit 1410). This electronic circuit 1410 can implement executable modules or hardware-based modules (not shown in FIG. 14), e.g., through processing / computer-executable instructions stored in a computer-readable medium, through logic circuits and / or hardware (e.g., an FPGA, etc.).

[0217] Although not shown, electronic device 1400 can include a system bus, an interconnect, a crossbar, a data transfer system, or other switch fabric that couples the various components within the device. The system bus or interconnect can include any one or combination of different bus structures, such as a memory bus and memory controller, a peripheral bus, a universal serial bus, and / or a processor and local bus that utilize any of various bus architectures.

[0218] Electronic device 1400 also includes one or more memory devices 1412 that enable data storage, examples of which include random access memory (RAM), non-volatile memory (e.g., read-only memory (ROM), flash memory, EPROM, EEPROM), and disk storage devices. Thus, memory devices 1412 can be distributed across different logical memory levels of the system and across different physical components. Memory devices 1412 provide a data storage mechanism for storing device data 1404, other types of code and / or data, and various device applications 1420 (e.g., software applications or programs). For example, operating system 1414 can be maintained as software instructions within memory device 1412 and executed by processor 1408.

[0219] In some embodiments, the electronic device 1400 also includes an audio and / or video processing system 1416, which processes audio data and / or passes audio data and video data to an audio system 1418 and / or a display system 1422 (e.g., the video buffer or screen of a smartphone or camera). The audio system 1418 and / or the display system 1422 can include any device that processes, displays, and / or renders audio, video, display, and / or image data. The display data and the audio signal can be communicated to the audio components and / or the display components via other similar communication links such as an RF (radio frequency) link, an S-video link, an HDMI (High-Definition Multimedia Interface), a composite video link, a component video link, a DVI (Digital Video Interface), an analog audio connection, a video bus, or a media data port 1424. In some implementations, the audio system 1418 and / or the display system 1422 are external components or separate components of the electronic device 1400. Alternatively, the display system 1422 can be an integrated component of the exemplary electronic device 1400, such as part of an integrated touch interface, for example.

[0220] The electronic device 1400 of FIG. 14 is an implementation example of the device 102 of FIG. 1, an implementation example of a device capable of implementing the analysis 344 of FIG. 3-2, and an implementation example of a device capable of implementing the method of FIG. 8. Therefore, the electronic device 1400 can include a security circuit 106, and the security circuit 106 may be a separate IC chip, or may be included as part of another IC chip or device such as a processor 1408, an electronic circuit 1410, or a memory device 1412. Therefore, one or more of the illustrated components may be integrated on the same IC chip such as a SoC, or at least on a single PCB. Further, a peripheral device 250 (e.g., of FIG. 2) may be able to communicate with the processor 202 of the security circuit 106 and / or a processor 1408 that may be separate from the security circuit 106.

[0221] As shown, the electronic device 1400 may additionally or alternatively include a compatibility analysis module 340. For example, the memory device 1412 can store the compatibility analysis module 340, and the processor 1408 can execute the compatibility analysis module 340. Therefore, the memory device 1412 can also store peripheral device design code 342, interface specifications 332, etc. The electronic device 1400 may further or alternatively implement the process of FIG. 8. Further, the encryption coprocessor 118 can include any of the components of FIGS. 4-7, for example, as part of the security circuit 106. Further, the encryption coprocessor 118 can be implemented in any of the components of the electronic device 1400 described above, either as part of the security circuit 106 or separately from the security circuit 106. For example, the processor 1408 can operate as a host processor supported by the encryption coprocessor 118. Therefore, the principles of the secure encryption coprocessor described herein can be implemented by or in relation to the electronic device 1400 of FIG. 14.

[0222] Unless the context indicates otherwise, the use of the word "or" in this specification can be considered to be the use of a term that permits the inclusion or application of one or more items linked by "or" in an inclusive sense (e.g., the phrase "A or B" can be interpreted as permitting only "A", only "B", or both "A" and "B"). Also, as used herein, the phrase referring to "at least one" of a list of items refers to any combination of those items that includes a single member. For example, "at least one of a, b, or c" includes not only a, b, c, a - b, a - c, b - c, and a - b - c, but also multiple combinations of the same elements (e.g., a - a, a - a - a, a - a - b, a - a - c, a - b - b, a - c - c, b - b, b - b - b, b - b - c, c - c, c - c - c, or other orders of a, b, and c). Further, the items represented in the accompanying figures and the terms discussed herein may indicate one or more items or terms, and thus, in this specification, items and terms in single or plural forms can be referred to interchangeably. The implementation of a secure encryption coprocessor is described in a language specific to certain features and / or methods, but the subject matter of the appended claims is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as examples of the implementation of a secure encryption coprocessor and / or secure encryption co - processing.

Claims

1. A method for an encryption coprocessor, comprising: acquiring digital information with the encryption coprocessor; generating scrambled digital information by the encryption coprocessor scrambling the digital information using at least one scrambling key; storing the scrambled digital information in at least one memory by the encryption coprocessor; preventing access to the digital information by the encryption coprocessor changing the at least one scrambling key, wherein the at least one scrambling key is stored in at least one key register, and the preventing includes overwriting the at least one key register with random bits; the method further comprising: performing secure erasure by overwriting the random bits in the at least one key register with a constant value.

2. The digital information includes data; the at least one scrambling key includes a data scrambling key; the scrambled digital information includes scrambled data; the method according to claim 1, wherein the at least one memory includes a data memory.

3. The digital information includes instruction codes; the at least one scrambling key includes a code scrambling key; the scrambled digital information includes scrambled instruction codes; the method according to claim 1, wherein the at least one memory includes an instruction memory.

4. The method according to any one of claims 1 to 3, further comprising preventing access to an intermediate value stored in the at least one register by overwriting the at least one register with random bits.

5. The acquiring includes receiving the digital information from a host processor; the security circuit for at least one integrated circuit includes the host processor and the encryption coprocessor, the method according to any one of claims 1 to 3.

6. the encryption coprocessor storing a plurality of first bits corresponding to a first randomness quality in a first register; The encryption coprocessor stores a plurality of second bits corresponding to a second randomness quality different from the first randomness quality in a second register; The method according to claim 1, further comprising: the encryption coprocessor selectively retrieving the plurality of first bits from the first register or the plurality of second bits from the second register based on at least one encryption operation.

7. The selectively retrieving The method according to claim 6, wherein the selectively retrieving comprises selectively retrieving the plurality of first bits from the first register or the plurality of second bits from the second register based on a randomness quality associated with the at least one encryption operation.

8. The first randomness quality is higher than the second randomness quality; The method further comprises: obtaining the plurality of first bits from a non-deterministic source of random numbers; and obtaining the plurality of second bits from a deterministic source of random numbers. The method according to claim 6 or claim 7.

9. The non-deterministic source of random numbers includes an analog-based source; The method according to claim 8, wherein the deterministic source of random numbers includes a digital-based source including a pseudo-random number generator.

10. The method according to claim 6 or claim 7, further comprising prefetching the plurality of first bits into the first register before the plurality of first bits are used.

11. obtaining an instruction code in the encryption coprocessor; the encryption coprocessor generating at least one parameter based on the instruction code; and the encryption coprocessor providing the at least one parameter to another component such that the another component can verify the instruction code against the encryption coprocessor. The method according to claim 1.

12. The at least one parameter includes a checksum; the generating includes calculating the checksum for the instruction code; and the providing includes providing the checksum to the another component such that the another component can use the checksum to verify the integrity of the instruction code in the encryption coprocessor. The method according to claim 11.

13. The at least one parameter includes an instruction count, the generating includes generating the instruction count by tracking an amount of executed instructions of the instruction code, the providing includes providing the instruction count to the another component so that the another component can use the instruction count to verify execution of the instruction code by the encryption coprocessor, the method according to claim 11 or claim 12. **Claim 14** the providing includes exposing the at least one parameter in a register accessible by the another component including a host processor, a security circuit for at least one integrated circuit includes the host processor and the encryption coprocessor, the method according to claim 11 or claim 12. **Claim 15** An apparatus comprising an encryption coprocessor configured to execute the method according to any one of claims 1 to 3, 6, 7, 11, and 12. **Claim 16** The method according to claim 4, further comprising performing secure erasure by overwriting the random bits in the at least one register with a constant value.

Images