Read-Only Memory (ROM) Security

Abstract

Devices with integrated circuit (IC) chips can provide protection against attacks on read-only memories (ROMs) (118), such as boot ROMs for security circuits. An attacker can gain control of the IC by modifying the ROM contents and / or redirecting ROM reads. To counter these attacks, an implementation stores encrypted ROM data (410) in a ROM array (404). A ROM controller (402) is used to cryptographically bind the address (414) of each ROM line to the corresponding encrypted ROM data (412). To access the encrypted ROM data, an encryption circuit (408) decrypts the encrypted ROM data using a key generated based on the corresponding ROM address (414). As part of an integrity check procedure, a digest can be calculated based on the encrypted ROM data. To further thwart attacks, the ROM address can be adjusted (e.g., scrambled) before the controller uses the adjusted address to read the encrypted data from the ROM array.

Description

[Background technology]

[0001] background Electronic devices play an essential role in manufacturing, communications, transportation, healthcare, commerce, social interaction, and entertainment. For example, electronic devices power server farms that provide cloud-based, distributed computing capabilities for commerce and communications. Electronic devices are also embedded in many types of modern equipment, ranging from medical devices to appliances, and from vehicles to industrial tools. Personal electronic devices enable portable video viewing and convenient access to smart digital assistants. Furthermore, smartphones, one of the most versatile electronic devices, have become a virtual necessity within reach. As electronic devices become more prevalent and integral to many aspects of modern life, device security becomes essential.

[0002] Many people are familiar with malware, sometimes collectively referred to as "computer viruses." Some malware is designed to gain unauthorized access to information stored on electronic devices or to compromise electronic devices. Several strategies can help combat certain types of malware and keep users' devices and information safe from security threats. These strategies include adopting and regularly updating resilient operating systems, practicing safe computing, and installing anti-malware programs. Unfortunately, these strategies do not make electronic devices invulnerable to all malware attacks.

[0003] Furthermore, electronic devices may be vulnerable to other types of attacks besides those performed by software-based malware. For example, the secure and reliable operation of electronic devices and the security of information stored on such devices may be compromised by physical attacks on hardware and radio frequency attacks on wireless communications. In other words, some forms of attack may circumvent or undermine the strategies listed above, allowing malicious actors to compromise electronic devices and potentially access accounts used on those devices.

[0004] Electronic devices contain at least one integrated circuit (IC) that provides intelligence that enables a variety of functions. These functions facilitate commerce, streamline access to healthcare, provide entertainment, support social media interactions, and enable other services identified above. Electronic devices may also store or utilize information that must be protected. To support these functions and promote secure operation, some electronic devices include hardware-based protection in the form of security circuitry that is part of the IC. Unfortunately, existing approaches to security circuitry are inadequate to counter the various software, hardware, and wireless attacks launched against electronic devices today. Summary of the Invention [Problem 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 critical services accessed using one or more accounts, such as financial services, air travel, and official government documents. The link between an electronic device and an account may allow a compromised electronic device to grant unwanted access to services linked to the account or unauthorized access to the account itself. Furthermore, to provide services associated with such accounts, these electronic devices may store account-related information that should be protected, such as financial data, usernames, passwords, and secret encryption keys. Unfortunately, anti-malware programs cannot block all avenues of attack against electronic devices. For example, anti-malware programs may not provide protection against direct physical attacks that use small probes to detect voltage levels on integrated circuit (IC) chips. Therefore, it is beneficial to incorporate hardware-based countermeasures into electronic devices that can identify, block, repel, or thwart attacks against electronic devices, including countering physical attacks.

[0006] Thus, electronic devices may include security circuits to resist attacks from malicious actors. In some cases, the security circuits detect inappropriate or suspicious activity and take protective measures. Security circuits can be implemented in a variety of ways. For example, computer engineers can fabricate security circuits as standalone IC chips or as part of another chip, such as a system-on-chip (SoC). In either case, the security circuit may 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 an electronic device, computer engineers can design it to resist many different types of attacks, as described below.

[0007] Attacks against 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, or direct physical probes of circuitry. Security circuits perform multiple functions to counter one or more of these attacks. For example, security circuits can protect encryption keys during use, transport, or storage. To do so, they can use dedicated memory and private data buses. Security circuits can also generate high-quality pseudorandom numbers or operate cryptographic engines in an area isolated from applications that might act as malware. Additionally, security circuits can ensure that hardware boots using a valid, unaltered, bootable basic input / output system (BIOS).

[0008] Thus, a security circuit can be responsible for implementing a diverse suite of functions to counter a wide variety of attacks against an electronic device. However, existing approaches to security circuits employ ad hoc hardware architectures. Different circuit portions of a security circuit can also be designed in relative isolation from one another. As a result, circuit portions designed to counter various security threats may not interoperate as intended, reducing the security of the hardware. Furthermore, insufficient communication between components creates new attack vectors for malicious actors. Furthermore, this ad hoc approach makes the design and testing phases of the security circuit more difficult, lengthy, and costly. This may result in some security threats being ignored or inappropriately addressed during the development of the security architecture. Therefore, these ad hoc architectures make it 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, in some examples, provides an adaptable and flexible framework or platform capable of producing resilient programmable security hardware to counter various forms of attacks on electronic devices. In some implementations of security circuits, different types of circuits, or circuit portions providing different security-related functions, communicate using an extended protocol that nevertheless produces reliable and consistent signaling. This communication protocol allows circuits providing different security-related functions to seamlessly interoperate according to a specified design framework. The design framework and communication protocol produce compatible components suitable for consistent deployment with stable and predictable interactions, even for circuit components designed independently of one another. As used herein, "compatible components" includes those components designed to conform to a common framework such that the components are suitable for use together. In some cases, compatibility provides a degree of plug-and-play capability between two or more security-related components on an integrated circuit chip.

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

[0011] Computing and other electronic devices are generally subject to attacks, including physical attacks, that can destroy or steal data. A hardware Root of Trust (RoT) scheme can resist many attacks, including physical attacks. RoT silicon can be realized with integrated circuits that provide security functions. In some cases, silicon RoT chips contain read-only memory (ROM) and are subject to physical attacks by malicious actors attempting to read or modify lines of the ROM. These physical attacks can generally be performed on ROM entries (e.g., ROM command lines) or while ROM data is being read and / or executed.

[0012] However, ROM can be designed or constructed to withstand attacks. Furthermore, ROM blocks or modules can be implemented as compatible components (e.g., ROM peripheral devices) of security chips. To protect ROM within a silicon Root of Trust chip or other security circuit, the ROM can be encrypted. This document further describes using cryptography to link ROM addresses to ROM data. For example, a ROM controller can use the corresponding ROM address to generate a key for decrypting ROM data (e.g., a data item stored in ROM memory, such as some or all of the data stored at a particular ROM address). By cryptographically linking each ROM address to associated ROM data stored in a ROM array, a fault attack on the ROM's (e.g., relatively narrow) address bus cannot be used to easily redirect reads to other ROM entries. These reads of the ROM array can involve executing code, obtaining data, or performing integrity checks on the ROM entries. This cryptographic linking of the ROM contents to the ROM addresses that access the contents (e.g., the addresses in ROM memory where the addresses of the corresponding ROM data are stored) allows the ROM to be protected even when the decryption key is known to an adversary.

[0013] To protect ROMs in a Silicon Root of Trust environment from being unknowingly modified, ROM data can be associated with an expected digest (or "digest value") that is derived using a hashing algorithm and stored in the ROM. During boot, the ROM can check whether the stored expected digest value matches another digest value calculated simultaneously on the current ROM data. A potential vulnerability of this protection approach is that an attacker could attempt to conceal a fault attack on the address bus by temporarily redirecting the ROM integrity checker to another ROM entry with the same data bits set.

[0014] First, to protect the integrity of the ROM with the ROM controller and ROM array, the ROM data stored in the ROM array can be encrypted. As described above, the ROM data can also be encrypted in a manner that ties each ROM address to each ROM data. Additionally, the ROM controller can adjust the addresses (e.g., scramble them, such as by using a substitution and / or permutation algorithm based on a key or cipher) to generate adjusted addresses used to access the ROM array. This address adjustment can further mitigate the risk of a modified ROM going undetected if an attacker attempts to redirect the address bus during a ROM integrity check.

[0015] To at least further reduce the risk of redirection-based attacks, this document describes selecting an encryption algorithm and / or encryption key to reduce the amount of duplicate instances of ROM data stored in a ROM array. By repeatedly changing the encryption algorithm and / or encryption key and checking the resulting ROM entries, duplicate ROM entries may be avoided or eliminated entirely. This may at least limit or eliminate the potential effectiveness of redirection attacks that target alternate ROM entries during ROM integrity checker operation. Thus, a ROM array can store ROM entries that are unique from one another, and a ROM controller can securely apply a hash algorithm to calculate a digest value that accurately reflects the current contents of the ROM.

[0016] Apparatus and techniques for ROM security are described with reference to the following drawings, in which the same numbers are used to reference like features and components throughout. [Brief explanation of the drawings]

[0017] [Figure 1] 1 illustrates an exemplary device with an integrated circuit (IC) that includes security circuitry capable of implementing ROM security. [Figure 2] 1 illustrates an exemplary security circuit that includes multiple circuit components, including multiple exemplary peripheral devices that may be interchangeably implemented, such as ROM blocks. [Figure 3-1] 1 illustrates an exemplary peripheral device that includes at least one interface to support compatibility with other circuit components. [Figure 3-2] It provides an example approach to analyzing peripheral device designs to ensure compatibility objectives are met. [Figure 3-3] 1 illustrates an example peripheral device including an example register interface and communication signals. [Figure 4]FIG. 1 illustrates an exemplary ROM including a ROM controller and a ROM array with respect to accessing encrypted ROM data in the ROM array. [Figure 5] 1 illustrates an exemplary ROM including a ROM controller and a ROM array in the context of checking the integrity of encrypted ROM data in the ROM array. [Figure 6] 1 illustrates an example of a ROM that may be implemented as a ROM peripheral device of a security circuit with encrypted ROM data. [Figure 7] 7 illustrates an exemplary timing diagram including various signals for accessing the ROM array of the ROM of FIG. 6. [Figure 8] An example of a method followed to implement a resilient ROM integrity checking procedure is given below. [Figure 9] This shows an example of how a device can check the integrity of its ROM at startup, reset, etc. [Figure 10] 1 illustrates an exemplary method for following a resilient ROM integrity checking procedure. [Figure 11] 1 illustrates an exemplary method for a device implementing ROM encryption, such as for accessing encrypted ROM data through decryption. [Figure 12] 10 is a flow diagram illustrating an exemplary process for accessing a ROM array containing encrypted ROM data. [Figure 13] 10 is a flow diagram illustrating an exemplary process for checking the integrity of a ROM array containing encrypted ROM data. [Figure 14] 1 illustrates various components of an exemplary electronic device that can implement ROM security in accordance with one or more described aspects. DETAILED DESCRIPTION OF THE INVENTION

[0018] Detailed Description overview Electronic devices make important contributions to modern society, including communication, security, and manufacturing. Each electronic device relies on integrated circuits (ICs) with processing power to provide some functionality. Due to the critical nature of many of these functions, electronic devices may include ICs with security circuits that provide protection. Security circuits mitigate the possibility that information will be inadvertently disclosed or that some functionality will be used in a harmful or unauthorized manner. Security circuits can be realized in various forms, one of which involves the Root of Trust (RoT) paradigm.

[0019] Silicon Root of Trust (Root of Trust) provides hardware-based mechanisms for securing computations, preventing inappropriate access to information and thwarting unauthorized use of devices. Silicon Root of Trust principles can help ensure that both the hardware infrastructure and the software running on it are maintained in their intended, trusted state. To do so, a silicon Root of Trust can ensure that critical system components boot securely using authorized, verifiable code. Thus, it can ensure that a server or another electronic device boots with the correct firmware and that the firmware is not infected with low-level malware. Silicon Root of Trust (Root of Trust) can provide additional or alternative security benefits. For example, it can provide a cryptographically unique machine ID. This unique ID allows operators to verify the authenticity of an electronic device. Furthermore, cryptographic keys and other information can be maintained in tamper-resistant silos, preventing or at least deterring those with physical access to the device from retrieving the information. Hardware-anchored Root of Trust services can also provide trusted, tamper-proof audit records and other runtime security services.

[0020] Chip designers can incorporate silicon Root of Trust technology into individual IC chips focused on providing security features. Alternatively, Root of Trust silicon can be integrated with other circuits, including central processing unit (CPU) chips or packages, graphics processing unit (GPU) chips or cards, systems-on-chips (SoCs), and memory storage devices. Security circuits can typically operate on server motherboards, network cards, client devices (e.g., laptops and smartphones), consumer routers, Internet of Things (IoT) devices, and fixed and portable storage devices, to name just a few. Anchoring the Root of Trust in silicon enhances computational security across the hardware, firmware, and software levels, regardless of the application or electronic device. Silicon Root of Trust also enhances security between various devices that communicate with each other, either directly or over a network. While this document uses a silicon or hardware Root of Trust environment to illustrate some of the security and circuit design principles, this is done solely as an example, as the principles discussed are applicable to security circuits generally.

[0021] In today's computing environment, malicious actors can attack electronic devices on a myriad of levels using numerous attack vectors. For example, attacks can be carried out using malware transmitted over the internet to attempt to obtain information stored on a laptop that a user wants to protect. Attacks can also involve injecting malware into the firmware used to power an electronic device, such as a Wi-Fi router or IoT device, while the device is in transit or operating in a private location. As another example, a malicious actor may steal an electronic device and wait long enough to launch a direct physical attack on the device. Such direct physical attacks can include cutting wires, probing voltages, inserting laser faults, or repeatedly executing code to observe trends or infer information.

[0022] Thus, a security circuit can be responsible for implementing a diverse suite of functions to counter a wide variety of attacks against an electronic device. However, existing approaches to security circuits employ ad hoc hardware architectures. Different circuit portions of a security circuit may be designed in relative isolation from one another. As a result, circuit portions designed to counter various security threats may not interoperate as intended, reducing the security of the hardware. Furthermore, insufficient communication between components creates new attack vectors for malicious actors. Furthermore, this ad hoc approach makes the design and testing phases of the security circuit more difficult, lengthy, and costly. This may result in some security threats being ignored or inappropriately addressed during the development of the security architecture. Therefore, these ad hoc architectures make it even more difficult to protect electronic devices from a wide variety of security threats.

[0023] However, this document describes an approach that provides an adaptable and flexible framework or platform that can produce resilient programmable security hardware to counter various forms of attacks on electronic devices. In some implementations of security circuits, different types of circuits, or circuit portions that provide different security-related functions, communicate using an extensible protocol that nevertheless produces reliable and consistent signaling. This communication protocol allows circuits that provide different security-related functions to seamlessly interact according to a specified design framework.

[0024] Design frameworks and communication protocols produce "compatible" components suitable for consistent deployment with stable and predictable interactions, even for circuit components designed independently of one another. 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 a measure of predictability and interoperability. As used herein, "compatible components" includes components designed to conform to a common framework such that the components are suitable for use together. In some cases, compatibility provides a degree of plug-and-play capability between two or more security-related components of an integrated circuit chip.

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

[0026] One example of a circuit component that can be implemented as a compatible component and / or a peripheral device is a ROM block or module. The ROM block includes a ROM array and a ROM controller. The ROM array can include boot-level instructions used to initialize the electronic device from a reboot or power-on scenario. To protect the ROM block, the data in the ROM array can be encrypted and the ROM controller can provide gated access to the ROM.

[0027] Additionally, the ROM block can use encryption to link ROM addresses with associated ROM data. Here, "link" can also mean "associate." In particular, the ROM block can link ROM addresses with associated ROM data by using the ROM addresses as parameters in an algorithm for encrypting the ROM data. For example, a masked ROM (e.g., a ROM having a grid of word lines and bit lines, where the word lines typically provide address inputs and the ROM memory outputs data on the bit lines) can be scrambled using a cipher such as the PRINCE cipher. Each ROM address can be used to scramble each associated ROM data in one of several ways to link the address and data. For example, each address can be used to decrypt each ROM data. In some implementations, the descrambled ROM addresses are used to generate at least one key, such as a keystream value, which is applied to a version of the corresponding ROM data to generate the decrypted ROM data. A block cipher such as PRINCE can be used, for example, in "Counter (CTR) mode." Each ROM data, such as a ROM entry or a ROM line, includes bits corresponding to the ROM (e.g., ROM bits that encode user data or program instructions that define a process to be performed by the security circuitry, e.g., ROM bits that define an algorithm) and bits corresponding to an error correcting code (ECC) value for the ROM bits of that data.

[0028] This "encryption" of the ROM can therefore be used to link ROM addresses with ROM data, for example, by using the respective ROM addresses as part of the decryption procedure for the respective ROM data. This address-based encryption approach ensures that fault attacks on the address bus cannot easily be used to redirect reads of the ROM array. By cryptographically linking the ROM addresses with the data, attacks that redirect normal ROM accesses (for example, allowing an attacker to skip fetched instructions in boot code by turning them into no-operations (NOPs)) can be thwarted. This protects operations by "external circuitry" (e.g., the main processor) that require the ROM data.

[0029] Scrambling ROM also makes it more difficult for an attacker to modify the stored ROM code and compromise the device. For example, assume an attacker wants to make a one-bit change to the original, unencrypted ROM data. This one-bit change allows the attacker to change the instructions while avoiding the problem that would normally cause an integrity check to fail. On the other hand, in the case of encrypted (e.g., scrambled) ROM data, if an attacker were to modify the scrambled data, such a change to the encrypted ROM data could take the expected 19 bits (e.g., about half of a 39-bit word). Thus, scrambling mask ROM provides resilience against mask ROM edits and makes fault injection attacks at ROM macro boundaries more difficult.

[0030] In an example implementation, ROM data in a ROM block of the security circuit is encrypted. The encryption is used to associate a ROM address with the associated ROM data. The ROM address and / or the associated ROM data can be scrambled. In some cases, the ROM address is used to descramble the ROM data. The ROM data can be jointly scrambled using a corresponding security value (e.g., ECC bits). In such cases, a per-ROM-line security value can be used and stored together as the ROM line. To descramble the ROM data using the ROM address, the ROM address is used to generate a key that descrambles the associated ROM data. The unscrambled ROM address can also be translated into an adjusted or scrambled ROM address to read an entry in the ROM, further complicating and frustrating an attacker's efforts to modify the ROM and cause the device to boot with the modified ROM.

[0031] In another implementation, the ROM block includes a ROM array and a ROM controller with a ROM checker circuit for verifying the integrity of the ROM data. An attacker may make changes to the ROM array (e.g., mask ROM) and then attempt to conceal such changes by disrupting or controlling communication between the ROM checker and the ROM array at startup. For example, an attacker may manipulate the data bus between the ROM checker circuit and the ROM array to conceal changes to the ROM data. Similarly, an attacker may attempt to control the low-order bits of the address bus, thereby subverting ROM checking by redirecting ROM accesses to skip modified words and point to unmodified copies.

[0032] These potential attacks can be at least partially thwarted by scrambling the ROM with a fixed key and performing a hash on the scrambled data for integrity checking. Attacks on the data bus are therefore made more difficult by the spreading nature of the scrambling scheme. For example, to make a single-bit change to the unscrambled data, an attacker would need to change many bits in the ROM array and then control those same bits on the data bus to hide the change. Attacks on the address bus can also be defeated by the way the scramble incorporates addresses into the data scrambling scheme.

[0033] In an additional implementation, the ROM data is encrypted and the ROM integrity checker operates on the encrypted ROM data. The ROM integrity checker circuit can verify that the ROM data has not been altered at each power-up or reset. The ROM integrity checker circuit can operate on a line-by-line basis. For example, the integrity checker circuit can apply a hash algorithm to each line of the ROM while the ROM data is still encrypted to calculate a digest value. As described below, after the encrypted ROM data is fed to a circuit that performs the hash algorithm, the expected digest value obtainable from the ROM can be compared to the calculated digest value. The integrity checker circuit generates an alarm if the digest values ​​do not match.

[0034] A ROM block or module can include a ROM array and a ROM controller. Typically, the contents of a ROM array, such as mask ROM, can be scrambled as part of a suite of security strategies. At startup, the ROM controller reads from the ROM array and sends the extracted scrambled content to at least one digest check module, such as a digest calculation circuit capable of applying a hash algorithm. The digest calculation circuit calculates a digest of the content using a hash algorithm, such as Secure Hash Algorithm 3 (SHA-3). The digest can also be calculated using a customizable, arbitrary message-length version of SHA3, such as cSHAKE, which allows the circuit to prefix the ROM data with a ROM checker-specific function string to make the hash function unique for a particular application. ROM data lines may not be aligned with the block size of the digest calculation circuit, in which case the lines can be padded (e.g., with zeros) to the block length. The ROM controller can compare the digest obtained from the digest calculation circuit with an expected digest to control access to the ROM array. The ROM array can store the expected digest at one or more ROM address locations. The ROM controller may also provide the calculated digest value to circuitry external to the ROM, such as a host processor. The ROM controller may, for example, expose the calculated digest value via an interface register in the ROM that other components can access, allowing one or more other components to verify that the ROM data has not been tampered with.

[0035] In an example implementation, a fixed scrambling key can be chosen to ensure that at least most, and possibly all, ROM lines are distinct or different from each other. This means that a fault attack on the address bus cannot hide the change by temporarily redirecting the ROM controller that communicates with the digest calculation circuit to a different line that stores the same ROM instructions.

[0036] Furthermore, hashing scrambled data is more fault-tolerant than hashing unscrambled data. An attacker attempting to make a small change to the unscrambled ROM data would have to make a relatively large change to the scrambled ROM data. Because the hash is calculated on the scrambled data, an attacker would need to cause a fault or control many bits to hide their changes. Therefore, the encryption of the ROM data, combined with the selection of the encryption key, significantly reduces the likelihood of a successful attack on the ROM data itself and the address bus.

[0037] In another implementation, in connection with generating at least one digest for multiple lines of ROM, the process may involve selecting an encryption algorithm and / or encryption key that reduces duplicate instruction lines stored in the ROM. Additionally, an encryption algorithm and / or encryption key may be selected that eliminates duplicately stored instruction lines. Thus, a scrambling algorithm and / or scrambling key may be selected based on the content of the ROM data to at least increase, if not maximize, the variability of the resulting encrypted bits stored in the ROM array. This variability (e.g., uniqueness) makes it difficult, if not impossible, for an attacker to redirect an integrity checker from one ROM entry to be checked against another ROM entry with the same word, since few, if any, entries have the same stored ROM value. Using these techniques, a hash algorithm may be applied to the scrambled data in the ROM. In other words, at least one digest of the stored ROM data may be calculated using scrambled lines of ROM data instead of unscrambled lines of ROM data, thereby increasing the variability of the values ​​on which the hash algorithm operates.

[0038] In these ways, security circuits can be incorporated into silicon Root of Trust chips (RoT) chips and / or SoCs. Such security circuits can include multiple peripheral devices, including ROM blocks. While some aspects of ROM security are described in the context of a security circuit environment and / or compatible design, the disclosed ROM security concepts are applicable to other circuit environments and other design paradigms.

[0039] This document first describes an example security environment with reference to Figures 1 and 2. Next, an example peripheral device interface and design code analysis is described with reference to Figures 3-1 through 3-3. Next, this document describes ROM security aspects and implementations with reference to Figures 4 through 13. An example electronic device is described with reference to Figure 14. Each of the environments, aspects, and implementations described herein can be used individually or in any combination.

[0040] Accordingly, example implementations at various levels of detail are described below with reference to associated figures. The following description first presents an example operating environment, followed by a description of example hardware, methods, and techniques. Exemplary methods are then described with reference to flowcharts or diagrams. Finally, example computing devices are described.

[0041] ROM security operating environment example 1 illustrates an exemplary device 102 generally at 100 having an integrated circuit 104 (IC 104) that includes security circuitry 106. The device 102, the integrated circuit 104, and / or the security circuitry 106 may implement ROM security as described herein. 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.

[0042] Examples of devices 102 include mobile electronic devices or mobile devices, mobile communication devices, modems, cellular or mobile telephones, mobile stations, gaming devices, navigation devices, media or entertainment devices (e.g., media streamers or game controllers), laptop computers, desktop computers, tablet computers, smart appliances, vehicle-based electronic systems, wearable computing devices (e.g., clothing, watches, or reality-altering glasses), Internet of Things (IoT) devices, sensors, inventory control devices, electronic portions of machines or electronic components of equipment (e.g., vehicles or robots), memory storage devices (e.g., solid-state drives (SSDs)), server computers or portions thereof (e.g., server blades or racks, or other portions of a data center), etc. Illustrated examples of devices 102 include tablet devices 102-1, smart televisions 102-2, desktop computers 102-3, server computers 102-4, smartwatches 102-5, smartphones (or document readers) 102-6, and intelligent glasses 102-7.

[0043] In an example implementation, the device 102 includes at least one integrated circuit 104. The integrated circuit 104 may be mounted on a module, card, or printed circuit board (PCB) (not shown). Examples of PCBs include flexible PCBs, rigid PCBs, single-layer or multi-layer PCBs, surface-mount or through-hole PCBs, combinations thereof, etc. Each integrated circuit 104 may 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 communications IC (e.g., a modem or radio frequency IC), a graphics processor, an artificial intelligence (AI) accelerator, combinations thereof, etc. The integrated circuit 104 may be packaged alone or together with other IC chips.

[0044] As shown, the integrated circuit 104 includes a security circuit 106. The security circuit 106 can include various components, including multiple circuit components 108-1...108-C (where C represents a positive integer) and an interconnect 110. Examples of the circuit components 108 include a processor and multiple peripheral devices, in addition to the interconnect 110. These are shown in FIG. 2 and described below. Although not explicitly shown in FIG. 1, the integrated circuit 104 may include other portions besides the security circuit 106. The multiple circuit components 108-1...108-C and the interconnect 110 may be monolithically integrated on a single IC as shown, or alternatively, the components may be distributed across two or more ICs. The 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., a silicon RoT), etc. Regardless of how or where the security circuit 106 is incorporated into an electronic device, the security circuit 106 can resist many different types of attacks.

[0045] In an example operation, when an attack, potential attack, or abnormal occurrence is detected, an alert 112 or interrupt 114 is generated by some component. For example, a circuit component 108 can generate an alert 112 and send the alert 112 to an alert handler, described below. Additionally or alternatively, another circuit component 108 can generate an interrupt 114 for processing by a processor. The alerts 112, interrupts 114, and other signals are communicated between two or more components 108 according to a common framework for interaction between processors of the security circuit 106 and / or peripheral devices. The common framework can specify the interface and signaling of each peripheral device to promote interoperability and the use of consistent communication protocols across multiple peripheral devices. Thus, although some aspects of compatibility are illustrated with respect to security circuits, peripheral device compatibility can also be employed with other types of circuits. An example framework, as well as example communication interfaces and interface specifications, are described below with reference to Figures 3-1 through 3-3.

[0046] In some implementations, the circuit component 108 is realized as a ROM 118 or a ROM block 118. The ROM 118 can be incorporated into the security circuit 106 as a peripheral device, a compatible component, a combination thereof, or the like. For example, the security circuit 106 can access the ROM 118 as part of a reboot to initialize the security circuit 106 or the IC 104. The ROM 118 can be accessed for other purposes other than, or instead of, the power-up operation. This ROM access 116 can be gated by the ROM 118 as part of the security paradigm described herein in connection with ROM data integrity checking. The ROM access 116 can also be secured by binding the ROM data to the ROM address used to access the ROM data in the ROM 118. These and other aspects of ROM security are described below with reference to Figures 4 through 13. However, with reference to Figure 2, an example architecture for the security circuit 106 will now be described.

[0047] FIG. 2 illustrates an exemplary security circuit 106 including multiple circuit components, including multiple exemplary peripheral devices 250, which may be interchangeably implemented. As illustrated, the security circuit 106 includes a processor 202 coupled to an interconnect 110. The interconnect 110 may be implemented using, for example, a bus, a switching fabric, or a bus network that enables communication among the various circuit components. The multiple circuit components 108-1...108-C (of FIG. 1) may include multiple memories and multiple peripheral devices in addition to the interconnect 110 and / or the processor 202. Each of the processor 202, multiple memories, and multiple other peripheral devices 250 is directly or indirectly coupled to the interconnect 110. As described herein, the ROM 118 (e.g., of FIGS. 1 and 4 hereafter) may correspond to the ROM 206 of FIG. 2.

[0048] In an example implementation, the memories may include a read-only memory 206 (ROM 206), a static random access memory 208 (SRAM 208), and a flash memory 210. The peripheral devices 250 may 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 peripheral devices 250 may 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 peripheral devices 250 may further include a random number generator 232 (RNG 232) and a timer 234. Additionally, the peripheral devices 250 may include any memory, as shown in Figure 2. While particular examples of memory and other peripheral devices 250 are shown in Figure 2 or described herein, a particular implementation of the security circuit 106 may include more, fewer, and / or different instances of processors, controllers, memory, modules, or peripheral devices (including duplicates thereof).

[0049] 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 clock signals or may include a reset circuit for resetting one or more individual components independently of one another, multiple components together, or the entire IC chip. Alternatively, the security circuit 106 may receive at least one clock or reset signal from a source external to the security circuit 106, which may or may not be on a separate chip. One or more separate peripheral devices 250 can operate in their own separate clock domains. For example, input / output (I / O) peripheral devices can synchronize to a clock local to the respective I / O device or channel. Peripheral devices in different clock domains can operate or communicate asynchronously with one another.

[0050] An example implementation of the illustrated components is described below. The processor 202 may be realized as the “main,” “central,” or “core” processor of the security circuit 106. By way of example only, the processor 202 may be implemented with a 32-bit in-order reduced instruction set computing (RISC) core with a multi-stage pipeline. For example, using the RISC-V instruction set, the processor may implement an M (machine) mode and a U (user) mode. Activating a reset pin (not shown) (e.g., through deassertion of an active-low reset pin) causes the processor 202 to exit reset and begin executing code at its reset vector. The reset vector may start in the ROM 206 and check the code in the embedded flash (e-flash) before jumping to the 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 for the entire security circuit 106 may be an asynchronous active-low according to a compatibility specification to support interoperability between various circuit components. The reset may be generated by the alert handler 204 as a security measure, by a watchdog timer, etc. The reset signal may also be sent to other circuit components, such as one of the memories or one of the other peripheral devices 250.

[0051] Coupled to the processor 202 are a debug module 226 (DM226) and an interrupt controller 228 (ItC228), either of which may be interchangeable. The debug module 226 provides debug access to the processor 202. By interfacing with specific pins of the IC, logic in the debug module 226 allows the processor 202 to enter a debug mode and provides the ability to inject code into a device (e.g., by emulating instructions) or memory. The interrupt controller 228 may be located near the processor 202. The interrupt controller 228 may accept vectors of interrupt sources from within the security circuit 106. The interrupt controller 228 may also assign priority and priority to interrupts before forwarding them to the processor 202 for processing.

[0052] The processor 202 can provide any desired level of performance or include any internal circuit components. For example, the processor 202 can include at least one arithmetic logic unit (ALU) (e.g., including an “extra” ALU to calculate branch targets to eliminate cycles of latency in taken conditional branches) and multiple pipeline stages. Using multiple pipeline stages, the pipeline can perform register writeback to reduce cycles of latency due to loads and stores and prevent pipeline stalls in which the response to a load or store is available the cycle after the request. The processor 202 can implement a single-cycle multiplier or generate an imprecise exception in error response to a store, allowing the processor to continue execution past the store without waiting for the response. While not shown, the processor 202 in particular, or the security circuit 106 in general, can include an instruction cache that provides single-cycle access times for instructions.

[0053] In the illustrated example, the security circuit 106 includes three memory address spaces for instructions and data. The ROM 206 is the target of the processor 202 after it comes out of reset. The ROM 206 contains hard-coded instructions to perform a subset of platform checks before checking the next stage of code. The next stage of code (e.g., a boot loader stored in e-flash memory) may be the first piece of code not hard-coded into the device's silicon. Therefore, this next stage of code is signature-checked for integrity to enhance security. The ROM 206 can perform this signature check by implementing one of many algorithms, such as the Rivest-Shamir-Adleman (RSA) check algorithm or the Elliptic Curve Digital Signature Algorithm (ECDSA), on the complete contents of the boot loader.

[0054] Flash memory 210 can be implemented as embedded flash (e-flash) memory for code storage. This e-flash can house the boot loader described above, as well as the operating system and any applications layered above it. SPI device 230 can be used to bulk load the e-flash memory. Debug module 226 can also be used to load code. SRAM 208 can operate as a scratchpad SRAM available for data storage by processor 202 (e.g., stack and heap information). SRAM 208 can also store code.

[0055] The security circuit 106 may include a suite of “peripherals” or “peripheral devices.” These peripheral devices 250 may be subordinate execution units coupled to the processor 202 via the interconnect 110. Each of these peripheral devices 250 may adhere to an interface framework that ensures compatibility with each other and with the processor 202. The compatibility scheme may specify how the processor 202 communicates with a particular peripheral device (e.g., using the interconnect 110), how the peripheral device communicates with 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., via at least one register, synchronously or asynchronously), or combinations thereof. The illustrated peripheral devices 250 may include peripheral devices associated with alert-related functionality provided by the alert handler 204, associated with the processor 202, associated with one or more memories, associated with the chip I / O, etc. Thus, memories may also comprise peripheral devices 250 associated with each other or with other illustrated circuit components.

[0056] The circuit or chip I / O peripheral devices include a pin multiplexer 222 and a pad controller 224. The pin multiplexer 222 provides signaling routes between at least some of the peripheral devices 250 and available multiplexable I / O nodes of the security circuit 106 (e.g., pins of a chip on which various components are integrated, or interfaces to other parts of an SoC). The pad controller 224 manages control or pad attributes such as drive strength, technology, pull-up vs. pull-down, etc. of each circuit's (e.g., chip's) external I / O. The pin multiplexer 222 and pad controller 224 are themselves peripheral devices on the interconnect 110. As such, each may have or be associated with at least one set of registers that provide software configurability.

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

[0058] Several "core security" peripheral devices are also shown, including the cryptographic engine and 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 16-byte increments, for example, and can encrypt or decrypt using different block cipher modes of operation. The AES engine 212 can support electronic codebook (ECB) mode, cipher block chaining (CBC) mode, cipher feedback (CFB) mode, output feedback (OFB) mode, counter (CTR) mode, etc. Data transfer can be made available to the processor. For example, key and data material can be passed to the cryptographic engine via register writes. Alternatively, a private channel for transferring key and data material can be included to mitigate exposure to potentially untrusted processor activity.

[0059] The HMAC engine 214 can utilize, for example, the Secure Hash Algorithm (SHA) SHA-256 as its hashing algorithm. SHA-256 is a member of the SHA-2 family of hashing algorithms, and the digest (or hash output) is 256 bits long, regardless of the data size of the input being hashed. Data is sent to the HMAC peripheral device after announcing the start of a hash request, which zeroes its internal state to an initial state (e.g., 32 bits at a time). Once the data is sent by the constituent client, the client can indicate completion of the hash request (using any partial word final write). According to an example portable interface scheme, the HMAC engine 214 generates the hash result and makes it available for register read by the requesting client. The data transfer can be made available to the processor or private to reduce exposure to potentially untrusted processor activity.

[0060] HMAC is a message authentication protocol layered on top of a hash function (e.g., SHA-256), where the HMAC mixes in a secret key for encryption purposes. HMAC is a specific application of adding a secret key around a hash of a message (via SHA-256) in a predetermined manner (e.g., twice). To provide this functionality, the 256b key can be programmed into circuitry before the message hashing begins. The timing of authentication completion can vary and may involve longer latency than using native SHA-256. Again, the hash information or secret key can be made available to the processor for convenience or processing efficiency, or can be kept private in some way for increased security.

[0061] The alert handler 204 is responsible for processing and responding to alerts, including those provided by other peripheral devices 250. Alerts can be thought of as security-sensitive interrupts that are handled in a timely manner to address perceived security threats. Unlike “standard” interrupts, alerts are not handled solely by software running on the processor 202. An alert can trigger a first-stage request that is handled by software as a “normal” interrupt. However, if the software is unable to respond to and properly repair the interrupt triggered by the alert, the alert handler 204 triggers a second-stage response. A second-stage response may include taking security measures such as terminating a process, erasing or otherwise deleting data, removing power from a circuit portion, or resetting an IC chip or part thereof. This ensures that the underlying issue—i.e., the perceived security threat—is addressed even if the processor 202 is busy, jammed, or under attack.

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

[0063] In some inter-device communications, the alert handler 204 receives synchronous or asynchronous alert indications signaled by differential signals from peripheral device sources. The peripheral device 250 can generate alerts based on its capabilities, knowledge, or sensed parameters. For other inter-device communications, the alert handler 204 performs ping tests of the alert sources as a robust heartbeat mechanism. A ping monitor (not explicitly shown) in the alert handler 204 requests periodic alert responses from each alert source to ensure that the communication channel with the alert source is functioning.

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

[0065] In some architectures, security alerts are intended to be rare events, at least compared to “standard” interrupts. Thus, during the design phase, a possible event may be designated as an alert event if it has a potential security impact, to the extent that the event is not expected to occur frequently. Examples of such events include parity errors (which may indicate an attack), unauthorized actions on cryptographic or security-related components, and sensed values ​​from physical sensors (such as voltage or temperature) that indicate environmental changes. The system routes alerts through the alert handler 204, which converts the alerts into interrupts for potential action by the processor 202. In some implementations, there is an underlying expectation that a secure operating system will have a protocol for handling such interrupts generated by alerts in software. If so, the secure operating system typically resolves the interrupt and can then clear it using the alert handler 204. Each peripheral device 250 can present a list of individual alerts, each representing a potential threat to be addressed. The peripheral device can send alerts to the alert handler 204 as alert indications using a specific encoding mechanism.

[0066] The security circuit 106 can also include a random number generator (RNG) 232. In general, randomness can contribute to security functions by providing variation in execution so that an attacker cannot predict the appropriate time to launch an attack. For example, random numbers can provide secret material used for identification or cryptographic purposes. The RNG 232 can be used to seed algorithmic calculations to obfuscate sensitive data values. In general, the RNG 232 provides better performance to the extent that its number generation becomes increasingly truly random and hardens against attacks. The RNG 232 can be implemented as a "true" random number generator (TRNG), which may include designs with analog portions to exploit some nondeterministic physical event or process. Examples of TRNG designs rely on metastability, electronic noise, timing fluctuations, thermal noise, quantum fluctuations, etc. The TRNG filters the resulting variables and then sends them to a pool of entropy that the device can sample at specific times for the current randomization function. In some cases, the interface to the entropy pool may include a read request for available random bits. The TRNG interface indicates the number of bits available, and a requesting peripheral device or software can read from this pool up to the range of available bits. An interrupt or alert may be triggered if an attempt is made to read an entropy bit that is not available.

[0067] Two other peripheral devices 250 include a timer 234 and a flash controller 216, the latter of which is described in the next paragraph. The timer 234 can, for example, support accurate performance by the processor 202. The timer 234 is formed from multiple bits (e.g., 64 bits) and operates as a free-running timer with a frequency guaranteed within a certain percentage. Another timer (not explicitly shown) can function as a watchdog timer that backstops the processor 202 if the processor becomes unresponsive. The unresponsiveness can be due to interference with development code, a security attack, etc.

[0068] The flash controller 216 controls the flash memory 210 available for code and data storage. The primary read path for this data can be in a standard memory address space. However, because flash is not written in a standard manner, writes to that address space can be ignored. Instead, to write to the flash memory 210, software interacts with the flash controller 216. Flash functions can include three primary commands: read, erase, and program. Read commands can be standardized and use the address space of the chip memory. Erase commands are performed at the page level, with the page size parameterizable by the flash controller 216. Upon receiving an erase request, the flash controller 216 wipes the contents of the target page, forcing the data to a "1" state (e.g., 0xFFFFFFFF per word). Software can then program individual words to any value. Because flash bits cannot return to a "1" state without being erased again, future contents are effectively changed by ANDing the current contents with the written value. Erase and program commands are relatively slow. Typical erase times are measured in milliseconds, while program times are in the microsecond range. Security is also a concern since sensitive data may be stored in flash memory 210. Therefore, flash controller 216 may provide some degree of memory protection.

[0069] The security circuit 106 is illustrated in FIG. 2 with a specific set of circuit components. However, a particular security circuit 106 may have more, fewer, or different circuit components. The circuit components may also be interconnected differently or operate in ways other than the exemplary manner described above. Furthermore, some circuit components may be omitted, while other circuit components may be implemented in multiple instances. For example, the alert handler 204 may be duplicated or distributed, or multiple AES encryption engines 212 may exist in some security circuits 106. Furthermore, for an integrated circuit chip in which the security circuit 106 forms only one of several dozen cores, the GPIO interface 220 may be omitted from the peripheral devices 250 of the security circuit 106.

[0070] Methods, techniques, and hardware examples of a compatible paradigm for secure ROM peripheral devices The security circuit 106 (e.g., of FIGS. 1 and 2) can include compatible circuit components, including peripheral devices 250, such as ROMs 206 or 118. This section describes example approaches for making peripheral devices compatible. Each peripheral device 250 can conform to a compatibility specification for the security circuit 106. By conforming to a compatibility specification that defines at least one interface method or communication protocol, the peripheral device 250 is implemented with at least one interface that creates consistent and expected interactions between the peripheral device 250 and other peripheral devices. This improves the predictability and reliability of communications and reduces the time required to design and test the security circuit.

[0071] FIG. 3-1 illustrates an exemplary peripheral device 250 at 300-1 that includes at least one interface 302 to support compatibility with other circuit components. More generally, FIG. 3-1 includes an interconnect 110, a processor 202 coupled to the interconnect 110, and multiple peripheral devices coupled to the interconnect 110. Thus, multiple peripheral devices may be coupled to the processor 202 via at least the interconnect 110. However, each peripheral device 250 may also be coupled to the processor 202 directly or in another manner without using the interconnect 110. FIG. 3-1 explicitly illustrates P peripheral devices 250-1, 250-2, ..., 250-P, where P represents a positive integer.

[0072] In an example implementation, 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 interoperation of the peripheral devices. For example, the interface 302, or communication interface 302, may enable the peripheral device 250 to implement at least one communication protocol 320. The interface 302 includes at least one interconnection interface 304, at least one device-to-device interface 306, and at least one other interface 308. These interfaces are described below. As shown, the peripheral device 250 also typically includes at least one register interface 310 and at least one security function module 312. Generally, the 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.

[0073] 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. For example, the processor 202 or another peripheral device can set or clear a register entry or load a value into a register entry to communicate with the peripheral device 250. Conversely, the peripheral device 250 can change the value of a register entry to communicate 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.

[0074] 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 collection of registers within the peripheral device 250 that are addressable by at least the local host processor 202 via a circuit-wide or chip-wide address map. Standardizing the CSRs increases software uniformity, promoting circuit reuse and documentation consistency. An exemplary embodiment of the register interface 310 is described below with reference to FIG. 3-3.

[0075] The security functions module 312 implements security-related functions for the peripheral device 250. Security-related functions include core or primary security functions and supporting or secondary security functions. Core security functions may include, for example, alert handling, cryptographic operations including encryption and decryption, random number generation, secure data storage (e.g., key management), including storage and access of sensitive data, etc. Supporting security functions may include functions that enable or facilitate the performance of core functions. Examples of supporting security functions include memory storage, memory control, timing, circuit and chip I / O control, environmental sensors, bus hosting, etc.

[0076] In general, the interface 302, or any of the specific exemplary interfaces (e.g., the interconnect interface 304, the device-to-device interface 306, or other interfaces 308), can establish at least one register with the register interface 310 to enable the respective interface communication capabilities or functions. With respect to the interconnect interface 304, the interconnect interface 304 implements a communication interface that couples to the interconnect 110 to enable a connection between, for example, a peripheral device 250 and the processor 202 that conform to a common framework. By having the peripheral device 250 and the processor 202 conform to the same common framework, bidirectional device-processor communication can be standardized and predictable. The interconnect interface 304 can operate across the interconnect 110 and can use at least one register of the register interface 310, can use a separate bus or independent wires, a combination thereof, or the like. During operation, the peripheral device 250 can engage in at least one interconnect communication 314 using the interconnect interface 304. Additionally or alternatively, peripheral device 250 may use interconnect interface 304 to communicate with another peripheral device over interconnect 110 .

[0077] The device-to-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, bidirectional inter-device communication can be standardized and predictable. The device-to-device interface 306 can use at least one register in the register interface 310, can use a bus dedicated to the peripheral device, can use one or more independent wires extending between the two peripheral devices, some combination thereof, etc.

[0078] During operation, the peripheral device 250 can engage in at least one inter-device communication 316 using the inter-device interface 306. By bypassing the interconnect 110 to communicate with another peripheral device, in some implementations the peripheral device 250 can communicate "directly" with other peripheral devices. Furthermore, establishing and adhering to an inter-device communication scheme promotes consistency and reliability of communications between two or more devices. Thus, designers can focus on achieving the intended security-related functionality of the security function module 312 instead of spending time and resources tracking and double-checking numerous ad-hoc communication schemes.

[0079] The other 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 the other circuit component conform to the same common framework, bidirectional peripheral device signaling can be standardized and predictable. One example of the other interface 308 is a chip I / O interface for communicating information with the outside world. Another example of the other interface 308 is an interrupt interface when interrupts are not communicated entirely over the interconnect 110. Yet another example of the other interface 308 is a clock interface. In some cases, the security circuit 106 (not separately shown 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 selected portions of the secondary system clock 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 associated with the peripheral device 250. During operation, the peripheral device 250 may use the other interface 308 to engage in at least one other communication 318 with another circuit component, such as an I / O circuit or a clock tree.

[0080] FIG. 3-2 illustrates an exemplary approach 300-2 for analyzing the design of a peripheral device to ensure compatibility objectives are met. In an example implementation, approach 300-2 uses an interface specification 332 that can include an interconnection scheme 334, a device-to-device scheme 336, or other schemes 338 (including each of the schemes). Interface specification 332 corresponds to interface 302 (of FIG. 3-1). Interconnection scheme 334 corresponds to interconnect interface 304, device-to-device scheme 336 corresponds to device-to-device interface 306, and other scheme 338 corresponds to other interface 308. These schemes can additionally or alternatively include local or chip-level I / O schemes, interrupt schemes, clock schemes, etc.

[0081] Thus, the interface specification 332 may establish the rules, protocols, attributes, options, functions, etc. of the interface 302. Similarly, the interconnection scheme 334, the device-to-device scheme 336, and the other scheme 338 may each establish the rules, protocols, attributes, options, functions, etc. of the interconnection interface 304, the device-to-device interface 306, and the other interfaces 308, respectively. During design, a designer develops each peripheral device 250 to conform to each associated scheme in the interface specification 332. For example, the device-to-device scheme 336 may establish a format for defining device-to-device signaling that bypasses the interconnect 110 of the security circuit 106. Doing so may produce compatible peripheral devices 250 that enhance interoperability and reduce design and development time, as well as testing and debugging efforts. For example, a peripheral device 250 may communicate signals (e.g., device-to-device signals) to another peripheral device using circuitry derived from attributes specified by the peripheral device's design code.

[0082] In an exemplary approach, the compatibility analysis module 340 can perform an analysis 344 of the design code to check for compatibility. A designer creates the peripheral device design code 342 with reference to the interface specification 332. Thus, the peripheral device design code 342 meets compatibility goals by conforming to 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 aspects of the interconnect communication 314 between the peripheral device 250 and the processor 202), one or more instructions for device-to-device signaling 350 (e.g., defining aspects of device-to-device communication 316 between the peripheral device 250 and another peripheral device), etc. The one or more instructions for device-to-device signaling 350 can relate to signals exchanged between two or more peripheral devices, including, for example, without using the interconnect 110 of the security circuit 106. These instructions can follow rules and guidelines regarding registers, signal naming, data types, timing, etc. for these signals.

[0083] The descriptions in the peripheral device design code 342 result in circuit components within the security circuit 106. For example, for each peripheral device 250 (e.g., in FIG. 3-1 ), based on attributes included in its design code 342, the device-to-device interface 306 can be coupled to at least one wire extending to another peripheral device to enable device-to-device signaling. Specifying device-to-device signaling 350 in the design code 342 improves interoperability and communication reliability. The interface specification 332 or the design code 342 configuration file can indicate required and optional peripheral functions within a particular compatibility framework. Thus, compliant design code may include required and optional portions, depending on the situation. In general, the design code 342 can be formatted according to any IC design or configuration platform. Examples include Verilog, Python, Hjson, etc.

[0084] During operation, compatibility analysis module 340 accepts peripheral device design code 342. With reference to interface specification 332, compatibility analysis module 340 performs analysis 344 to check whether peripheral device design code 342 conforms to a specified common framework. Compatibility analysis module 340 may compare peripheral device design code 342 with one or more of interconnection schemes 334, inter-device schemes 336, or other schemes 338 to check whether the code meets the respective specifications. These schemes may include specifications regarding interrupts, register usage, etc. Based on analysis 344, compatibility analysis module 340 generates a compatibility report 346.

[0085] 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 portion of the code causing the failure indication or the portion of the interface specification 332 that is violated. Although the interface specification 332, the compatibility analysis module 340, and the peripheral device design code 342 may be described with respect to an exemplary security circuit environment, 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 a general circuit design.

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

[0087] In an example implementation, various signals may be specified as part of a compatibility framework to which peripheral device 250 must adhere. Starting at the top left, bidirectional signaling 362-1 using interconnect 110 is shown with peripheral device 250 acting as a device (e.g., acting as a follower) relative to interconnect 110. Below that, peripheral device 250 is shown receiving at least one clock signal 364 and at least one development mode signal 365. Development mode signal 365 indicates to peripheral device 250 in which mode security circuit 106 or the overall SOC is currently operating. In other words, multiple modes of operation may exist. In the two-mode example, the multiple modes may include a development mode and a production mode. The mode indication may determine, for example, how software errors are handled. Other modes may enable security features that communicate the complete lifecycle mode status to the peripheral device.

[0088] The peripheral device 250 may also generate or output at least one interrupt signal 366 or at least one alert signal 368. Additionally, bidirectional signaling 362-2 using the interconnect 110 is shown with the peripheral device 250 acting as a host (e.g., acting as a reader) for the interconnect 110. The peripheral device 250 may further engage in bidirectional signaling 367 with the GPIO interface 220 or other chip I / O circuitry. With respect to the register interface 310, at least one output signal 369-1 is labeled as a register-to-hardware (Reg2Hw) signal. Meanwhile, at least one input signal 369-2 is labeled as a hardware-to-register (Hw2Reg) signal. Generally, in some implementations, certain features are considered required, while other features are considered optional. However, these required and optional categories may vary from implementation to implementation. In a compatible design, these two categories may be assigned for each feature to enable each peripheral device 250 to properly interoperate with other peripheral devices.

[0089] Having generally described methods, techniques, and hardware for peripheral devices in a compatible paradigm, including examples of ROM peripheral devices that provide ROM security, the description now turns to methods, techniques, and hardware for ROM security.

[0090] Methods, techniques, and hardware examples for ROM security This section describes an exemplary ROM controller that can be included in a ROM block having a ROM array (e.g., storing masked ROM). The ROM block or module can be connected to a system bus as a peripheral device according to the compatibility principles described above. In an example implementation, as part of the ROM block, the ROM controller interfaces between the system bus and the masked ROM. The ROM contains encrypted content. The encryption can involve relatively lightweight or low-cost encryption, such as scrambling. In some cases, the content can be scrambled using a fixed key that can be derived from a global constant. However, the encryption can be implemented using a more complex or costly encryption scheme. Regardless of the encryption scheme or encryption key used, the ROM controller can decrypt (e.g., unscramble) the content it fetches from the ROM array to memory.

[0091] Unlike some SRAM controllers, which can perform equivalent decryption or encryption tasks on SRAM, ROM controllers can also include a ROM checker circuit that can coordinate the calculation of a cryptographic hash of the ROM contents immediately after power-up or reset as part of the initialization process to perform an integrity check. The ROM checker circuit can therefore detect malicious changes made to the masked ROM while the system is shut down.

[0092] The ROM block can provide several functions. For example, the ROM block can include logic for memory and address scrambling and / or descrambling. Second, the ROM block can perform post-boot ROM integrity checks. Additionally, the ROM block can provide or issue control and status register (CSR) alert triggers and / or status information for ROM integrity errors or finite state machine (FSM) glitches. These and other exemplary aspects of the ROM 118 / 206 are described in this section with reference to Figures 4 through 8.

[0093] 4 illustrates an exemplary ROM 118, generally at 400, including a ROM controller 402 and a ROM array 404, with respect to accessing data in the ROM array 404. As shown, the ROM controller 402 may include a ROM access interface 406 and an encryption circuit 408. In an example implementation, the ROM array 404 includes encrypted ROM data 410 stored at a plurality of ROM addresses 418. The ROM controller 402 is coupled to the ROM array 404. Generally, the encryption circuit may perform a decryption operation on the encrypted ROM data 410 based on the plurality of ROM addresses 418.

[0094] The ROM access interface 406 is coupled to the encryption circuit 408 and the ROM array 404. In an exemplary ROM read or data fetch operation, the ROM access interface 406 reads encrypted ROM data 412 from the ROM array 404 based on a ROM address 414 corresponding to the encrypted ROM data 412 (e.g., the ROM address 414 may be the address of where the encrypted ROM data 412 is stored). The ROM access interface 406 also decrypts the encrypted ROM data 412 using the encryption circuit 408 to generate decrypted ROM data 416. The ROM access interface 406 may also transfer the decrypted ROM data 416 to the interconnect 110.

[0095] In some cases, the ROM access interface 406 decrypts the encrypted ROM data 412 and generates decrypted ROM data 416 using a ROM address 414 corresponding to the encrypted ROM data 412. Thus, the encryption circuit 408 can perform a decryption operation on each ROM data 412 of the encrypted ROM data 410 based on each ROM address 414 of the plurality of ROM addresses 418. Each ROM address 414 can identify each ROM data 412 within the ROM array 404, for example, by indicating its memory location. As described below, the ROM address 414 may include a scrambled address that points "directly" to the ROM array 404, or a descrambled address that points "indirectly" to the ROM array 404, such as after the descrambled address is adjusted to generate the scrambled address.

[0096] The ROM access interface 406 may be implemented with at least one finite state machine (FSM) designed and / or programmed to provide access to the encrypted ROM data 410 as decrypted ROM data (e.g., as multiple instances of decrypted ROM data 416) for the security circuit 106 (e.g., of FIG. 1) or for the startup procedure of the electronic device. The FSM, or other implementation of the ROM access interface 406, may direct the operation of the encryption circuit 408.

[0097] The encryption circuit 408 may include a keystream circuit (not shown in FIG. 4) that can generate one or more keys based on the ROM address 418. The encryption circuit 408 may also include a data combining circuit (not shown in FIG. 4) coupled to the keystream circuit. The data combining circuit generates decrypted ROM data 416 based on the encrypted ROM data 412 and at least one key from the plurality of keys. In some cases, the encryption circuit 408 further includes a permutation circuit (not shown in FIG. 4) that permutes the encrypted ROM data 412 to generate permuted encrypted ROM data. The data combining circuit then combines bits of the at least one key with bits of the permuted encrypted ROM data using logical operations to generate the decrypted ROM data 416. An example implementation of the encryption circuit 408 is described below with reference to FIG. 6.

[0098] Each entry of encrypted ROM data 410 may include, for example, a ROM instruction 420 and a check code 422, such as an error correction code (ECC). In such a case, encrypted ROM data 412 may include bits corresponding to the ROM instruction 420 and bits corresponding to the check code 422 of the ROM instruction 420. The bits corresponding to the ROM instruction 420 and the bits corresponding to the check code 422 of the ROM instruction 420 are intermingled, mixed, or "smoothed" together so that their respective bit positions are unknown. In contrast, decrypted ROM data 416 may include the bits corresponding to the ROM instruction 420 and the bits corresponding to the check code 422 of the ROM instruction 420 in a format where the two sets of bits are separated from each other, or at least their relative bit positions are known.

[0099] In some implementations, the decoded ROM instructions and associated check codes may be passed by the ROM 118 to another component via the interconnect 110. In other embodiments, the ROM controller 402 may include a ROM checker circuit (e.g., the ROM checker circuit 616 of FIG. 6). The ROM checker circuit 616 may be coupled to the output of the encryption circuit 408. In exemplary operation, the ROM checker circuit 616 calculates another check code based on the ROM instructions 420 of the decoded ROM data 416. The ROM checker circuit 616 also performs a comparison including the check code 422 of the decoded ROM data 416 and the calculated check code. The ROM checker circuit 616 may further generate an error signal based on the comparison. The error signal may be sent as an alert signal and / or an interrupt signal to an alert handler and / or a processor, respectively.

[0100] 8 and 10, each encrypted ROM data 412 of the encrypted ROM data 410 stored at multiple ROM addresses 418 in the ROM array 404 is distinct (in some implementations) from each other encrypted ROM data 412′ of the encrypted ROM data 410 stored at multiple ROM addresses 418 in the ROM array 404. This distinction (or uniqueness of the encrypted ROM data) is due, at least in part, to the encryption scheme based on the multiple ROM addresses 418. For example, the encryption scheme and / or at least one encryption key used in a particular encryption scheme can be selected such that each original ROM data results in a distinct encrypted ROM data.

[0101] FIG. 5 is now described, illustrating additional and / or alternative aspects of the exemplary ROM 118. Accordingly, it should be understood that aspects of FIG. 4 can be combined with one or more aspects of FIG. 5, and vice versa. For example, the address adjustment circuit 504 of FIG. 5 can be included in the circuitry of FIG. 4. In such a case, the ROM controller 402 can include the address adjustment circuit 504 that adjusts the ROM addresses to generate the adjusted ROM addresses. This may require converting the ROM addresses from unscrambled to scrambled (e.g., from adjusted logical addresses to generate physical addresses). The ROM access interface 406 uses the address adjustment circuit 504 to adjust the ROM addresses to read the encrypted ROM data 410 stored at the plurality of ROM addresses 418. The address adjustment circuit 504 can, for example, permute two or more bits of each ROM address, permute two or more bits of each ROM address, or permute and permute two or more bits of each ROM address of the ROM addresses 418 to generate the adjusted ROM addresses. Another implementation showing the combined aspects of Figures 4 and 5 is shown together in Figure 6 and described below.

[0102] 5 illustrates an exemplary ROM 118 generally at 500, including a ROM controller 402 and a ROM array 404, in connection with checking the integrity of encrypted ROM data 410. As shown, the ROM controller 402 includes an integrity checker circuit 502, an address adjustment circuit 504, and a gating circuit 506. The ROM controller 402 has access to at least a digest calculation circuit 508. In some cases, the digest calculation circuit 508 is implemented as another peripheral device 250 (of FIG. 2) and / or circuit component 108 (of FIG. 1). In other cases, the digest calculation circuit 508 may be implemented as part of the ROM 118, such as part of the ROM controller 402 or separate from the ROM controller 402.

[0103] In an example implementation, the ROM array 404 includes encrypted ROM data 410 stored at a plurality of ROM addresses 418. The ROM array 404 may also include at least one expected digest 510 (or “expected digest value 510”). The ROM controller 402 is coupled to the ROM array 404. In an example operation, the ROM controller 402 reads the encrypted ROM data 412 from the ROM array 404 based on the ROM address 512 or 514 corresponding to the encrypted ROM data 412. The ROM controller 402 also obtains at least one digest value 516 using the encrypted ROM data 412. To perform the obtaining, the integrity checker circuit 502 may use the digest calculation circuit 508. The ROM controller 402 further gates access to the ROM array 404 based on the at least one digest value 516 and the expected digest value 510. The consistency checker circuit 502 can control the gating circuit 506 to allow / authorize or block access to the ROM array 404 .

[0104] An address adjustment circuit 504 of the ROM controller 402 can adjust the ROM address 512 to generate an adjusted ROM address 514. The ROM controller 402 uses the address adjustment circuit 504 to adjust the ROM address 512 to read the encrypted ROM data 410 stored at multiple ROM addresses 418. The address adjustment circuit 504 can adjust the ROM address 512, for example, by shifting, swapping, or otherwise manipulating two or more bits of the ROM address 512 to generate the adjusted ROM address 514. The ROM address 414 in FIG. 4 can correspond to the ROM address 512 or the adjusted ROM address 514.

[0105] The ROM controller 402 is configured to obtain at least one digest value 516 based on applying at least one hash algorithm to the encrypted ROM data 412. Examples of hash algorithms are described herein. In some cases, the ROM array 404 and the ROM controller 402 include a first peripheral device (e.g., a first peripheral device 250-1, such as ROM 206 in FIG. 2). A second peripheral device (e.g., a second peripheral device 250-2, such as HMAC engine 214 in FIG. 2) may implement one or more hash algorithms. The ROM controller 402 may obtain the at least one digest value 516 by communicating with the second peripheral device. Thus, in these cases, the second peripheral device may include the digest calculation circuit 508. In other cases, the ROM 118, including its ROM controller 402, may instead include the digest calculation circuit 508.

[0106] 5 for some implementations, the ROM controller 402 can read the expected digest value 510 from the ROM array 404. In contrast to the encrypted ROM data 410, the expected digest value 510 may be stored in the ROM array 404 in unencrypted form. The expected digest value 510 may be stored at any address and / or location in the ROM array 404, and the expected digest value 510 may span one or more lines and / or addresses in the ROM array 404. For example, the expected digest value 510 may be stored in a predetermined location in the ROM array 404 (e.g., the last six ROM entries) that corresponds to a determinable ROM address (e.g., at least one ROM address 512 or at least one adjusted ROM address 514 that identifies the last six ROM entries).

[0107] The integrity checker circuit 502 can compare the calculated digest value 516 with the expected digest value 510. In response to at least one digest value 516 matching the expected digest value 510, the ROM controller 402 can use the gating circuit 506 to grant access to the ROM array 404, for example, allowing a boot procedure to be performed using the encrypted ROM data 410 or allowing general ROM access. On the other hand, in response to at least one digest value 516 not matching the expected digest value 510, the ROM controller 402 can use the gating circuit 506 to block access to the ROM array 404, for example, preventing a boot procedure from being performed using the untrusted encrypted ROM data 410 or blocking general ROM access. The ROM controller 402 can also send at least one alarm 518 (or “alarm indication 518”). The at least one alarm 518 may correspond to an alert communicated from the ROM 118 via a register and / or an interrupt sent over the interconnect 110 or a dedicated path.

[0108] The security circuitry may additionally or alternatively provide the calculated digest value 516 to one or more other components external to the ROM 118. For example, the ROM controller 402, such as its integrity checker circuit 502, may transmit the digest value 516 to another component, such as the main processor. The ROM controller 402 may also, or instead, expose the digest value 516 via at least one register in the ROM 118. Reading the value in the register allows other components to independently verify the value of the calculated digest value 516. The key derivation mechanism ensures that even if an attacker is able to corrupt the encrypted ROM data 410 and / or the expected digest value 510 (stored in the ROM array 404), the attacker has altered the chip ID in a way that can be detected by other components.

[0109] Each encrypted ROM data 412 in the encrypted ROM data 410 can be established to vary or be heterogeneous, including being unique or different from one another. For example, each respective encrypted ROM data 412 in the encrypted ROM data 410 may be different from each other respective encrypted ROM data 412 in the encrypted ROM data 410 throughout the ROM array 404. In some cases, the encryption key associated with encrypting or decrypting the encrypted ROM data 410 is selected to ensure that each respective encrypted ROM data 412 is different from each other respective encrypted ROM data 412 in the encrypted ROM data 410 throughout the ROM array 404. In other cases, the encryption algorithm associated with generating each encrypted ROM data 412 is selected to ensure that each respective encrypted ROM data 412 is different from each other respective encrypted ROM data 412 in the encrypted ROM data 410 throughout the ROM array 404. Techniques for ensuring that most or each encrypted ROM data 412 is unique are further described with reference to FIG. 8.

[0110] FIG. 6 illustrates an example of a ROM block 600, which may be implemented as ROM 118 (e.g., of FIGS. 1, 4, and 5) and / or ROM peripheral device 206 (e.g., of FIG. 2). FIG. 6 illustrates a high-level block diagram of an example ROM module implementation. Some of the blocks illustrated may be realized by instantiations of multi-use primitives that may also be used or replicated elsewhere on the chip or as part of other components of the security circuitry. ROM block 600 includes ROM array 404, consistency checker circuit 502, and address adjustment circuit 504 from FIGS. 4 and 5.

[0111] As shown, the ROM block 600 also includes an interface 604, at least one register 606, a ROM checker circuit 616, a zero padder circuit 618, a multiplexer 602, and an example of the encryption circuit 408 (e.g., of FIG. 4). The ROM checker circuit 616 may be implemented with an ECC decoder. The encryption circuit 408 can be implemented, for example, using a keystream circuit 608, a manipulation circuit 612, and a data combining circuit 614. The data combining circuit 614 can be implemented with a circuit that performs a logical operation, such as an exclusive-or (XOR) operation. The manipulation circuit 612 can spread one or more bits of the ROM data 626 (which may correspond to the encrypted ROM data 412 of FIGS. 4 and 5). The manipulation circuit 612 can be implemented, for example, using a permutation circuit, a permutation circuit, or a combined permutation and permutation circuit (e.g., a permutation-permutation network), as described further below.

[0112] In general, the top half of the diagram shows the path of a ROM read when the system is operating normally. The bottom half of the diagram shows the use of ROM integrity checker circuit 502. ROM integrity checker circuit 502 can be triggered by the power manager, for example, early in the chip startup sequence, to check the validity of the ROM image. In some cases, integrity checker circuit 502 can be configured to run only once to prevent an attacker from running it multiple times and compromising the system. Integrity checker circuit 502 can release multiplexer 602 and grant access to the ROM array as part of gating circuit 506 (of FIG. 5) once the integrity check procedure completes with a positive result.

[0113] This document describes an example of a ROM access when a security circuit (e.g., a chip) is operating in normal boot mode or after an integrity check has been successfully performed. Once the chip boots, it can request ROM access via an interconnect such as a system bus (e.g., a TL-UL bus). ROM block 600 can receive these requests via interface 604 (e.g., a TL-UL adapter) shown in the upper left of FIG. 6. In normal operation, multiplexer 602 grants access to these bus reads (e.g., TL reads). The address 610 of the read request is adjusted by address adjustment circuit 504. For example, the address adjustment circuit can scramble the address using a permutation and reordering network.

[0114] In parallel with the ROM access, a keystream circuit 608, such as a low-latency reduced-round PRINCE block cipher (e.g., with 5 rounds at a latency of 1, which may be equivalent to a cipher used for SRAM), calculates a 39-bit truncated keystream for the ROM block. The keystream circuit 608 generates at least one key using the address from the request provided to the address adjustment circuit 504 (e.g., before the address is adjusted). On the next cycle, the scrambled data from the ROM array 404 (e.g., ROM data bits and corresponding ECC bits; the two sets or types of bits are intermixed in the ROM array 404 as ROM data 626) is sent through a manipulation circuit 612, such as another permutation / reorder network. The manipulated (e.g., permuted and / or permuted) ROM data from the manipulation circuit 612 and at least one key or keystream from the keystream circuit 608 are combined by a data combination circuit 614. In the illustrated example, the key and the permuted scrambled ROM data (including the ECC code) are XORed together by an XOR operation performed by data combining circuit 614. A block cipher such as PRINCE can be used, for example, in "Counter (CTR) mode." A counter (e.g., ROM data address 610) is encrypted with an N-bit block cipher (e.g., PRINCE) and a specific key (e.g., a netlist constant) to generate an N-bit keystream block 628, which can be XORed against the data (e.g., ROM data 626 corresponding to ROM data address 610).

[0115] The output from the data combiner circuit 614 is the decoded 32-bit data plus 7 ECC bits. If a ROM checker circuit 616 is implemented here, these 39 bits can be passed through the ROM checker circuit 616 and returned to the interface 604 if successfully verified by the ECC bits. An ECC decoding error can cause the ROM access in response to the TL request to report an error code (e.g., a read error indicator) via the interface 604 along with an error signal 622. The ROM controller can also use or alternatively set at least one of the registers 606 and / or generate a fatal alert based on the ECC decoding error. While specific bit lengths are shown herein, these are shown by way of example only, and the data, ECC, etc. may have different lengths or be omitted.

[0116] In alternative implementations of the ECC function, the "main" bus or system bus may be enhanced with ECC checking functionality. In such cases, the circuitry and its operation may differ from that shown and described with reference to FIG. 6. For example, ROM access response 624 may include ROM and ECC bits by passing them "directly" from the descrambling XOR operator of data combiner circuit 614 to interface 604. Thus, in these alternative implementations, ROM checker circuit 616 and its associated CSR may be omitted from ROM block 600.

[0117] FIG. 7 illustrates an exemplary timing diagram 700 for accessing the ROM array 404 of the ROM block 600 of FIG. 6. The timing diagram 700 illustrates the timing of various signals. These example signals map to the signals shown in the ROM block 600 of FIG. 6. The time from when the request 702 (req702) output is provided by the interface 604 until the response appears at the response or ROM valid 704 (rvalid704) input of the interface 604 is one cycle. Two examples are shown: an unscrambled or original address "12" and an unscrambled or original address "34." An example of how the addresses may be "scrambled" is by reversing the digits of each address. For the example original or unscrambled "12" address, the word stored at scrambled address 21 in the ROM is denoted "w21." The keystream value for the unscrambled or original address 12 is denoted "k12." The descrambled or decoded ROM data at original address 12 is designated "d12."

[0118] Referring to FIG. 6, the PRINCE block cipher-based implementation of the keystream circuit 608 and the two substitution and permutation (S&P) network implementations of the address adjustment circuit 504 and manipulation circuit 612 can be parameterized by a "key." In the case of a ROM controller, these keys can be globally randomized netlist constants. Thus, the keys are considered difficult to recover, but are not necessarily confidential data. While particular bit lengths (e.g., 39 bits and 256 bits) and word sizes (e.g., 32 bits) are shown in the description and / or accompanying drawings, these are provided by way of example only. In other implementations, different bit lengths, word sizes, etc. may be used.

[0119] This document describes an example of a boot ROM integrity check. ROM integrity checker circuit 502 can run after reset, including "immediately after" reset, or at least before any reads to the ROM occur. Until the ROM check is complete, integrity checker circuit 502 controls ROM address requests (e.g., via multiplexer 602). Multiplexer 602's select signal 632 can include redundant coding to protect the select signal from fault injection (FI) attacks. If select signal 632 has an invalid value, the detection of the invalidity can trigger a fatal alert. Before beginning to read data from ROM array 404 as ROM data 626 (which may correspond, for example, to encrypted ROM data 412 in FIGS. 4 and 5), ROM integrity checker circuit 502 (or the power manager module) can initiate an encryption operation on an encryption module (not shown in FIG. 6) to prepare for the ROM check (e.g., signal kmac_cmd_o can be used to initiate a cSHAKE operation in a keyed or Keccak message authentication code (KMAC) engine). An example of a ROM integrity checking process is described below with reference to the flow chart of FIG.

[0120] A possible physical attack on the security circuitry is an attempt to corrupt the mask ROM. The regular structure of mask ROM is convenient because it makes metal fixing relatively easy, but for the same reason, the regular structure can make the ROM a relatively easy target for an attacker. Because code in the ROM can be executed first, an attacker who modifies the ROM code without detection can completely destroy the chain of trust. Thus, the integrity checker circuit 502 can provide a measure of confidence in the integrity of the ROM code.

[0121] In the example implementation, after releasing the ROM controller from reset, the power manager waits until the "check_done_o" signal is asserted before starting the host processor. The power manager can also check that the check_good_o signal is "on". If not, the power manager can refuse to start. This provides a safety check, and additional security is provided by the integration of a key manager, described next.

[0122] The KMAC interface can be assumed to be pre-configured such that the KMAC engine runs the cSHAKE algorithm with a prefix specific to the ROM checker circuitry. The ROM checker does not assert the signal "kmac_rom_vld_o" after a hash calculation (or a known number of hash calculations) has finished. However, the KMAC engine may subsequently ignore the signal to allow for simple arbitration that still remains robust against fault injection attacks.

[0123] The integration with the key manager is based on transferring the digest data in "kmac_digest_share0_i" and "kmac_digest_share1_i" as "keymgr_digest_data_o". This 256-bit digest can be incorporated into "CreatorRootKey". In some cases, the key manager can only allow one transaction (e.g., 256 bits / 32 bits = 8 bits) to pass this information after a reset. In response to future messages, the key manager can issue an alert, which can thwart an attacker who tries to trigger additional transactions before or after the correct transaction.

[0124] The CreatorRootKey can form the first key in a chain of ID and root keys. An attacker modifying the ROM would disrupt the CreatorRootKey, as circumventing it would result in a preimage attack on the ROM checksum calculation or the KM_DERIVE function. The result would be a functional security chip, but the chip would have the "wrong" root key, breaking the chain of trust used for authentication.

[0125] Next, an example hardware interface for parameters and signals is described. Example ROM controller signal descriptions are provided below in Table 1. These signals can be sent from or received by the integrity checker circuit 502. The "check" related signals can communicate with a power manager. The "keymgr" related signals can communicate with a key manager. The "kmac" related signals can communicate with a KMAC engine or other circuitry that performs hashing operations.

[0126] [Table 1]

[0127] Examples of register values ​​for the ROM block registers 606 may include: ALERT_TEST; FATAL_ALERT_CAUSE; DIGEST_0...DIGEST_7 (e.g. with multiple registers); EXP_DIGEST_0...EXP_DIGEST_7 (e.g., with multiple registers); and ROM (e.g., windows into ROM).

[0128] Example fields of the FATAL_ALERT_CAUSE register are shown in Table 2 below.

[0129] [Table 2]

[0130] With regard to programming and ROM blocks, software can interact with the ROM controller by fetching code or loading data from ROM. From this perspective, a ROM block appears to be a block of memory accessible via the system bus. However, a ROM block may make some of its registers 606 accessible. With the exception of the ALERT_TEST register, the registers are read-only and may be writable. While the FATAL_ALERT_CAUSE register may change value during operation (e.g., when an alert is signaled), the other registers in the ROM block may have fixed values ​​by the time the software is executed.

[0131] The integrity checker circuit 502 can load the digest into register 606 via the digest signal 634. To obtain the calculated ROM digest, software can read the DIGEST_0 through DIGEST_7 registers. The ROM array 404 may also contain an expected ROM digest, EXP_DIGEST. Unlike the rest of the contents of the ROM array 404, the contents that store the expected digest may not be scrambled. Therefore, software cannot read the data through a standard ROM interface, which would cause it to be "de-scrambled" again, producing garbage data that would cause the ECC check to fail. If software is given access to this value, the expected digest can be read in EXP_DIGEST_0 through EXP_DIGEST_7.

[0132] 8 illustrates an example scheme generally at 800 according to which a resilient integrity check may be implemented. The security circuit includes a ROM array 404. The ROM array 404 includes encrypted ROM data 410. The encrypted ROM data 410 may include multiple instances of encrypted ROM data, such as L instances of encrypted ROM data 412-1...encrypted ROM data 412-L, where L represents an integer.

[0133] Each respective encrypted ROM data 412 is generated from a respective “original” ROM line 802-1 using an encryption algorithm 806 having at least one key 804 and / or based on a respective ROM address 414 (e.g., each ROM address 414 may be used as part of the at least one key 804). Thus, the first ROM line 802-1 results in first encrypted ROM data 412-1, the Lth ROM line 802-L results in the Lth encrypted ROM data 412-L, etc. Each ROM line or entry 802 may correspond to, for example, decrypted ROM data 416 after a pair of encryption and decryption operations.

[0134] In some cases, a particular combination of encryption algorithm 806 and key 804 may produce two or more instances of encrypted ROM data 412 that are identical, i.e., indistinguishable from one another. This can provide another potential avenue of attack by redirecting the ROM integrity checker to another ROM line with the same value if another ROM line in the ROM array 404 is modified. More specifically, an attacker may attempt to attack the communication between the checker and the ROM array. This may require manipulating the data bus (e.g., to hide changes made to the ROM data) or attacking the lower bits of the address bus. For example, an attacker may attempt to modify a word in the ROM, but redirect the ROM checker to another copy of the same word to avoid detecting such a modification through a hash calculation.

[0135] To counter this, if there are one or more duplicates, the encryption algorithm 806 and / or key 804 can be changed or replaced with a different algorithm or key. Using the changed algorithm and / or key, the ROM lines 802-1...802-L are re-encrypted to generate another set of multiple instances of encrypted ROM data 412-1...412-L. This process can be repeated until there are few or no identical instances of encrypted ROM data 412.

[0136] Unlike some scrambling approaches that use ephemeral (and unguessable) keys to make attacks on data at rest more difficult, the keys for ROM scrambling are fixed per circuit. Such fixed keys still provide the spreading and address linking properties described above. The keys can be derived from global constants. When building the final design for a security circuit instantiation, an "additional" check can be performed to ensure that constants have been chosen that will produce keys that are distinct for each word in the ROM after scrambling.

[0137] Having generally described the methods, techniques, and hardware for ROM security, the discussion now turns to exemplary methods.

[0138] Exemplary methods for ROM security An exemplary method is described below with reference to the flowcharts of FIGS. 9 through 13. FIG. 9 illustrates in flowchart 900 an exemplary method for a device to check the integrity of a ROM, such as upon power-up or reset. Flowchart 900 includes nine blocks 902-918. Referring also to FIG. 6, the ROM integrity checker circuit 502 can execute after reset, including immediately after reset, or at least before a read to the ROM occurs. The ROM checker (e.g., through multiplexer 602) can control ROM address requests until the ROM check is complete. The select signal 632 of multiplexer 602 can include redundant coding to protect the select signal 632 from fault injection (FI) attacks. If the select signal 632 has an invalid value, the detection of the invalidity can trigger a fatal alert. Before starting to read data from the ROM array 404, the ROM checker (or power manager module) can initiate an encryption operation in preparation for performing one or more hash operations for the ROM check.

[0139] At 902, the ROM checker can read the ROM contents in descrambled address order starting at "address 0," resulting in a scattered access pattern on the physical ROM due to the address scrambling. At 904, each ROM read produces 39 bits of data, which is zero-padded (e.g., by zero padder circuit 618) to 64 bits. This 64-bit length matches the interface expected by digest calculation circuit 508 of FIG. 5 (e.g., KMAC engine (not explicitly shown in FIGS. 5 or 6)). The address is incremented.

[0140] The ROM consistency checker circuit 502 loops through many of the words in the ROM (e.g., from bottom to top), reading and incrementing the address until it reaches a predetermined address, as described below with respect to block 906. The finite state machine (FSM) of the consistency checker circuit 502 passes each ROM word to the KMAC engine using a ready / valid interface, and sets the "kmac_rom_last_o" bit in response to the last word sent.

[0141] At 906, a determination is made based on the address value. A certain amount of words may be reserved for the expected hash value. For example, the top eight words in the ROM array 404 (e.g., by the unscrambled address) may be interpreted as a 256-bit "expected hash value." Unlike the rest of the ROM array 404, the data of the expected hash word may be stored unscrambled. Therefore, the expected hash value can be read directly without decryption. At 908, these top eight words are read from the ROM array 404 into a buffer or register to obtain the expected digest value. These words may then be obtained as the expected hash by the integrity checker circuit 502 (e.g., ignoring ECC bits). The expected hash may be compared to the digest returned from the KMAC engine or other implementation of the digest calculation circuit 508.

[0142] At 910, when the digest is received from the KMAC engine, the integrity checker circuit 502 may forward the digest to a key checker, such as a key manager. The key manager or integrity checker circuit 502 may compare the calculated digest to an expected digest read from the most significant eight words of the ROM array 404 at 912. If the FSM of the ROM controller 402 performs the comparison, the forwarding of block 910 may be omitted. If the two digests do not match, the key manager and / or integrity checker circuit 502 may generate an alarm at 914. The alarm may be signaled as an alert or an interrupt. In response to a match between the expected digest and the calculated digest, the integrity checker circuit 502 may signal the “check_good_o” indication as “on” at 916 and release the multiplexer 602. By doing so, the consistency checker circuit 502 switches access to the multiplexer 602 to allow other components to access the ROM array 404 via the interface 604. Upon completion of the calculation and / or comparison, either with a match or a mismatch, a "check_done_o" indication may be asserted (e.g., driven high), after which the system may enter normal operation at 918.

[0143] FIG. 10 shows a flowchart or process 1000 of an exemplary method according to integrity checking with resilience. Generally, for an encryption key-based implementation, the flowchart 1000 may first require selecting an encryption key. Second, each line of ROM data is encrypted using the selected encryption key to generate respective encrypted ROM data 412. Third, multiple instances of encrypted ROM data 412 are checked to determine whether duplicates exist. If no duplicates exist, the process can end. On the other hand, if at least one duplicate is detected, the process can continue by repeating the steps, starting with selecting another encryption key.

[0144] As shown in FIG. 10 , flow chart 1000 includes five blocks 1002-1010. At block 1002, an encryption key and / or encryption algorithm is applied to each line of the ROM to generate multiple encrypted ROM lines. At block 1004, the presence of a certain number of duplicate encrypted ROM lines is determined. If the number is zero (or meets another threshold), the process can end, as indicated by the dashed arrow. However, if the number of duplicates is not zero, at block 1006, the application of encryption to each line of the ROM is repeated using a new encryption key and / or a new encryption algorithm. At block 1008, a new number of duplicate instances of encrypted ROM lines is determined based on the new key and / or new algorithm. As at block 1010, the process can continue at block 1006 until a certain threshold number (e.g., zero) of duplicate encrypted ROM lines are achieved through application of a particular key and algorithm combination.

[0145] FIG. 11 illustrates, in a flowchart or process 1100, an exemplary method for an apparatus implementing ROM scrambling, such as for accessing scrambled ROM data. Flowchart 1100 includes four blocks 1102-1108. Operations may be performed by a ROM block, such as a ROM 118 / 206 peripheral device. In block 1102, the ROM may receive a ROM read request, including a ROM address, from a system bus or its interface. In block 1104, a ROM controller of the ROM may access the ROM array using the ROM address to obtain scrambled ROM data, which may include ECC or other protection data in addition to ROM instructions. More generally, the scrambled ROM data may be implemented as encrypted ROM data.

[0146] At block 1106, an encryption circuit of the ROM controller may descramble the scrambled ROM data using the ROM address to generate unscrambled ROM data. For example, the encryption circuit may use one or more of a keystream circuit 608, a manipulation circuit 612 (e.g., a permutation and permutation network or other circuitry to spread the bits of the scrambled ROM data), and a data combination circuit 614 that performs logical operations. At block 1108, the ROM controller may transmit the unscrambled ROM data to another peripheral device via an interface and / or a system bus.

[0147] 12 is a flow diagram illustrating an example process 1200 for accessing a ROM array containing encrypted ROM data. The flow diagram includes four blocks 1202-1208. At block 1202, a ROM read request is received. The ROM read request includes a ROM address associated with a ROM array containing encrypted ROM data stored at multiple ROM addresses. For example, ROM controller 402 may receive a ROM read request including ROM address 414 associated with ROM array 404 containing encrypted ROM data 410 stored at multiple ROM addresses 418. The ROM read request may be received from another component, for example, via interconnect 110 and / or interface 604.

[0148] At block 1204, the encrypted ROM data is read from the ROM array using the ROM address. For example, the ROM controller 402 can read the encrypted ROM data 412 from the ROM array 404 using the ROM address 414. In some cases, the ROM controller 402 can include an address adjustment circuit 504, which can adjust the ROM address 512 to generate an adjusted ROM address 514. In such a case, the ROM controller 402 can retrieve the encrypted ROM data 412 from the ROM array 404 using the ROM address 414, which is implemented as the adjusted ROM address 514.

[0149] At block 1206, the encrypted ROM data is decrypted to generate decrypted ROM data using the ROM address. For example, the encryption circuit 408 may use the ROM address 414 to decrypt the encrypted ROM data 412 to generate decrypted ROM data 416. To do so, the encryption circuit 408 may use the ROM address 414 to generate a key that is used as part of a decryption algorithm to generate the decrypted ROM data 416.

[0150] At block 1208, the decoded ROM data is transferred to the interconnect. For example, the ROM controller 402 may transfer the decoded ROM data 416 to the interconnect 110, where the decoded ROM data 416 may include check code bits. Additionally or alternatively, the ROM checker circuit 616 may perform an error checking procedure on the ROM as part of or in conjunction with transferring the decoded ROM data 416.

[0151] FIG. 13 is a flow chart illustrating an example process 1300 for checking the integrity of a ROM array containing encrypted ROM data. The flow chart includes three blocks 1302-1306. In block 1302, the encrypted ROM data is read from a ROM array based on a ROM address corresponding to the encrypted ROM data, and the ROM array stores the encrypted ROM data at multiple ROM addresses. For example, the ROM controller 402 can read the encrypted ROM data 412 from the ROM array 404 based on a ROM address 512 or 514 corresponding to the encrypted ROM data 412. Accordingly, the ROM controller 402 can include an address adjustment circuit 504 that generates an adjusted ROM address 514 from the ROM address 512, such that the adjusted ROM address 514 is used to identify the encrypted ROM data 412 to be retrieved. Here, the ROM array 404 can store the encrypted ROM data 410 at multiple ROM addresses 418. The ROM array 404 can also store an expected digest value 510.

[0152] At block 1304, at least one digest value is obtained using the encrypted ROM data. For example, the ROM controller 402 may obtain at least one digest value 516 using the encrypted ROM data 412. In some cases, the integrity checker circuit 502 of the ROM controller 402 may communicate with a digest calculation circuit 508 external to the ROM 118 to obtain the at least one digest value 516. In other cases, the integrity checker circuit 502 or another portion of the ROM 118 may include circuitry to calculate a hash of the digest value 516. The digest value 516 may correspond to a hash across multiple instances of the encrypted ROM data 412, including up to all instances of the encrypted ROM data 412 in a particular ROM array 404. In such a case, at block 1302, multiple instances of the encrypted ROM data 412 are read from the ROM array 404 based on multiple ROM addresses corresponding to the multiple instances of the encrypted ROM data 412. Additionally, in block 1304 , a hash algorithm is applied to the plurality of pieces of encrypted ROM data 412 read from the ROM array 404 .

[0153] At block 1306, access to the ROM array is gated based on at least one digest value and the expected digest value. For example, the ROM controller 402 may gate access to the ROM array 404 based on at least one digest value 516 and the expected digest value 510. To do so, the consistency checker circuit 502 may compare the digest value 516 with the expected digest value 510. If there is a mismatch, the gating circuit 506 may block or deny access to the ROM array 404. On the other hand, if the two values ​​510 and 516 match, the gating circuit 506 may allow other components access to the ROM array 404, for example, to allow initialization to continue or "normal" ROM access to occur.

[0154] Aspects of these methods may be implemented, for example, in hardware (e.g., fixed logic circuitry or a processor in conjunction with memory), firmware, software, or some combination thereof. The methods may be realized using one or more of the devices or components shown in Figures 1 through 8 and 14. These components may also be further divided or combined. The devices and components in these figures generally represent hardware, firmware, software, or combinations thereof, such as electronic devices, PCBs, packaged modules, IC chips, components, or circuits. Thus, these figures illustrate some of the many possible systems or apparatuses in which the described methods may be implemented.

[0155] With respect to the methods and associated flow diagrams described herein, the order in which operations are shown and / or described is not intended to be construed as a limitation. Instead, any number or combination of the described method operations can be combined in any order to implement a particular method or alternative methods. Operations can also be omitted or operations can be added to the described methods. Additionally, the described operations can be implemented in full or partial overlap.

[0156] ROM security aspects and implementation examples Several exemplary aspects and implementations are described below.

[0157] Exemplary embodiment 1: An apparatus for secure read-only memory (ROM), comprising: a ROM array including encrypted ROM data stored at a plurality of ROM addresses; and a ROM controller coupled to the ROM array, the ROM controller including an encryption circuit configured to perform a decryption operation on the encrypted ROM data based on the plurality of ROM addresses; and a ROM access interface coupled to the encryption circuit and to the ROM array, the ROM access interface configured to read the encrypted ROM data from the ROM array based on the ROM addresses corresponding to the encrypted ROM data, decrypt the encrypted ROM data using the encryption circuit to generate decrypted ROM data, and transfer the decrypted ROM data to an interconnect.

[0158] Exemplary Embodiment 2: The device of exemplary embodiment 1, wherein the ROM access interface is configured to generate decrypted ROM data by decrypting the encrypted ROM data using a ROM address corresponding to the encrypted ROM data.

[0159] Exemplary Embodiment 3: The apparatus of exemplary embodiment 1 or exemplary embodiment 2, wherein the encryption circuit is configured to perform a decryption operation on each ROM data of the encrypted ROM data based on a respective ROM address of the plurality of ROM addresses, each ROM address being configured to identify a respective ROM data within the ROM array.

[0160]

[0013] Exemplary Embodiment 4: The apparatus of any one of the preceding exemplary embodiments, wherein the ROM access interface comprises a finite state machine (FSM) configured to provide access to encrypted ROM data as decrypted ROM data for a boot procedure. The FSM is a system that always assumes a corresponding one of a plurality of predefined states, and the system transitions from one state to another based on an input to the FSM.

[0161] Exemplary Embodiment 5: The apparatus of any one of the preceding exemplary embodiments, wherein the ROM controller comprises an address adjustment circuit configured to generate the adjusted ROM address by adjusting the ROM address, and wherein the ROM access interface is configured to adjust the ROM address using the address adjustment circuit to read the encrypted ROM data stored at the plurality of ROM addresses.

[0162] Exemplary Embodiment 6: The apparatus of exemplary embodiment 5, wherein the address adjustment circuitry is configured to at least one of permute or permute two or more bits of each of the ROM addresses to generate the adjusted ROM addresses.

[0163] Exemplary Embodiment 7: The apparatus of any one of the preceding exemplary embodiments, wherein the encryption circuit comprises: a keystream circuit configured to generate a key based on a ROM address; and a data combination circuit coupled to the keystream circuit, the data combination circuit configured to generate decrypted ROM data based on at least one of the encrypted ROM data and the key.

[0164] Exemplary Embodiment 8: The apparatus of exemplary embodiment 7, wherein the encryption circuit includes a manipulation circuit configured to generate the manipulated encrypted ROM data by spreading two or more bits of the encrypted ROM data, and the data combination circuit is configured to generate the decrypted ROM data by combining bits of the at least one key and bits of the manipulated encrypted ROM data using a logical operation.

[0165] Exemplary Embodiment 9: The apparatus of any one of the preceding exemplary embodiments, wherein the encrypted ROM data includes bits corresponding to the ROM instructions and bits corresponding to check codes of the ROM instructions, and the decrypted ROM data includes bits corresponding to the ROM instructions and bits corresponding to check codes of the ROM instructions.

[0166] Exemplary embodiment 10: The apparatus of exemplary embodiment 9, wherein the ROM controller includes a ROM checker circuit coupled to an output of the encryption circuit, the ROM checker circuit configured to calculate another check code based on a ROM instruction of the decrypted ROM data, perform a comparison including the check code of the decrypted ROM data and the calculated check code, and generate an error signal based on the comparison (e.g., if there is no match between the check code and the calculated check code).

[0167] Exemplary embodiment 11: The apparatus of exemplary embodiment 9, wherein each encrypted ROM data of the encrypted ROM data stored at a plurality of ROM addresses of the ROM array is different from each other encrypted ROM data of the encrypted ROM data stored at a plurality of ROM addresses of the ROM array by an encryption scheme based on the plurality of ROM addresses.

[0168] Exemplary Embodiment 12: The apparatus of any one of the preceding exemplary embodiments, wherein the apparatus includes a mobile device.

[0169] Exemplary embodiment 13: A method for secure read-only memory (ROM), comprising: obtaining a ROM read request including a ROM address associated with a ROM array including encrypted ROM data stored at a plurality of ROM addresses; reading the encrypted ROM data from the ROM array using the ROM address; generating decrypted ROM data by decrypting the encrypted ROM data using the ROM address; and transferring the decrypted ROM data to an interconnect.

[0170] Exemplary Embodiment 14: The method of exemplary embodiment 13, wherein the decrypting includes generating at least one key based on the ROM address and generating decrypted ROM data by applying the at least one key to the encrypted ROM data.

[0171] Exemplary Embodiment 15: The method of exemplary embodiment 14, wherein applying includes performing a logical operation involving at least one key and the encrypted ROM data to generate decrypted ROM data.

[0172] Exemplary Embodiment 16: The method of exemplary embodiment 15, wherein the decrypting includes generating manipulated ROM data by manipulating bits of the encrypted ROM data before performing the logical operation, and the performing includes performing the logical operation using at least one key and the manipulated ROM data to generate the decrypted ROM data.

[0173] Exemplary embodiment 17: An integrated circuit including a security circuit for a secure read-only memory (ROM), the security circuit including a ROM array including ROM data at a plurality of ROM addresses, and a ROM controller coupled to the ROM array, the ROM controller configured to cryptographically bind each ROM address of the plurality of ROM addresses to each ROM data of the ROM data.

[0174] Exemplary Embodiment 18: The integrated circuit of exemplary embodiment 17, wherein the ROM controller comprises an encryption circuit configured to decrypt the respective ROM data using the respective ROM addresses.

[0175] Exemplary Embodiment 19: The integrated circuit of exemplary embodiment 18, wherein the encryption circuit is configured to generate at least one key based on the respective ROM addresses and decrypt the respective ROM data using the at least one key, thereby generating decrypted ROM data.

[0176] Exemplary embodiment 20: The integrated circuit of exemplary embodiment 19, wherein the encryption circuit is configured to generate decrypted ROM data using the at least one key by applying the at least one key to a version of each ROM data, the version corresponding to a manipulated version of each ROM data stored in the ROM array.

[0177] Exemplary Embodiment 21: The integrated circuit of any one of exemplary embodiments 17 to 20, wherein the ROM controller is configured to process a combination of ROM bits and error correction code (ECC) bits that collectively form respective ROM data corresponding to respective ROM addresses.

[0178] Exemplary embodiment 22: An integrated circuit of any one of exemplary embodiments 17 to 21, wherein the ROM controller includes a consistency checker circuit coupled to the ROM array, the consistency checker circuit configured to gate access to the ROM array based on a check procedure applied to the ROM data and an expected digest (e.g., granting access to the ROM array (i.e., a service request to read data from the ROM array) only if the check procedure results in a match).

[0179] Exemplary embodiment 23: The integrated circuit of exemplary embodiment 22, wherein the integrity checker circuit is configured to implement the check procedure by extracting an expected digest from the ROM array, performing a comparison including the extracted expected digest and a digest calculated based on ROM data in the ROM array, and granting or denying access to the ROM array based on the comparison (e.g., granting if there is a match between the extracted expected digest and the digest calculated based on ROM data in the ROM array, but denying otherwise).

[0180] Exemplary embodiment 24: An apparatus for secure read-only memory (ROM), comprising: a ROM array including encrypted ROM data stored at a plurality of ROM addresses; and a ROM controller coupled to the ROM array, wherein the ROM controller is configured to read the encrypted ROM data from the ROM array based on the ROM addresses corresponding to the encrypted ROM data, obtain at least one digest value using the encrypted ROM data, and gate access to the ROM array based on the at least one digest value and the expected digest value (e.g., grant access to the ROM array only if a match is obtained between the at least one digest value and the expected digest, but block or deny access otherwise).

[0181] Exemplary Embodiment 25: The apparatus of exemplary embodiment 24, wherein the ROM controller comprises an address adjustment circuit configured to generate an adjusted ROM address by adjusting the ROM address, and the ROM controller is configured to obtain the adjusted ROM address by adjusting the ROM address, and use the adjusted ROM address to read the encrypted ROM data stored at the multiple ROM addresses using the address adjustment circuit.

[0182] Exemplary embodiment 26: The apparatus of exemplary embodiment 24 or exemplary embodiment 25, wherein the ROM controller is configured to obtain at least one digest value based on applying at least one hash algorithm to the encrypted ROM data.

[0183] Exemplary Aspect 27: The apparatus of Exemplary Aspect 26, wherein the ROM array and the ROM controller comprise a first peripheral device, the second peripheral device is configured to implement one or more hash algorithms, and the ROM controller is configured to obtain at least one digest value by communicating with the second peripheral device.

[0184] Exemplary Embodiment 28: The apparatus of any one of exemplary embodiments 24 to 27, wherein the ROM controller is configured to read the expected digest value from the ROM array.

[0185] Exemplary Embodiment 29: The apparatus of exemplary embodiment 28, wherein the expected digest value is stored in the ROM array in unencrypted form.

[0186] Exemplary Embodiment 30: The apparatus of exemplary embodiment 28, wherein the expected digest value is stored in the ROM array at a predetermined location corresponding to a determinable ROM address.

[0187] Exemplary Embodiment 31: The apparatus of any one of exemplary embodiments 24 to 30, wherein in response to at least one digest value matching an expected digest value, the ROM controller is configured to grant access to the ROM array, thereby enabling a boot procedure to be performed using the encrypted ROM data.

[0188] Exemplary Embodiment 32: The apparatus of any one of exemplary embodiments 24 to 31, wherein in response to at least one digest value not matching an expected digest value, the ROM controller is configured to block access to the ROM array, thereby preventing a boot procedure from being performed using the encrypted ROM data, and send an alarm indication.

[0189] Exemplary Embodiment 33: The apparatus of any one of exemplary embodiments 24 to 32, wherein each respective encrypted ROM data of the encrypted ROM data is different from each other respective encrypted ROM data of the encrypted ROM data across the ROM array.

[0190] Exemplary embodiment 34: The apparatus of exemplary embodiment 33, wherein the encryption keys associated with generating the encrypted ROM data are selected to ensure that each respective encrypted ROM data is different from each other respective encrypted ROM data of the encrypted ROM data throughout the ROM array. For example, the one or more encryption keys may be used in an iterative process performed to reduce the number of identical ROM data (e.g., to zero, or at least below a threshold).

[0191] Exemplary Embodiment 35: The apparatus of exemplary embodiment 33, wherein the encryption algorithm associated with generating the encrypted ROM data is selected to ensure that each respective encrypted ROM data is different from each other respective encrypted ROM data of the encrypted ROM data throughout the ROM array. For example, one or more encryption algorithms may be used in an iterative process performed to reduce the number of identical ROM data (e.g., to zero or at least below a threshold).

[0192] Exemplary embodiment 36: A method for secure read-only memory (ROM), comprising reading encrypted ROM data from a ROM array based on a ROM address corresponding to the encrypted ROM data, the ROM array storing the encrypted ROM data at a plurality of ROM addresses, the method further comprising obtaining at least one digest value using the encrypted ROM data, and gating access to the ROM array based on the at least one digest value and an expected digest value.

[0193] Exemplary embodiment 37: The method of exemplary embodiment 36, wherein the reading includes adjusting a ROM address to generate an adjusted ROM address, and reading the encrypted ROM data from the ROM array using the adjusted ROM address.

[0194] Exemplary embodiment 38: The method of exemplary embodiment 36 or exemplary embodiment 37, wherein the gating includes blocking access to the ROM array in response to at least one digest value not matching an expected digest value.

[0195] Exemplary embodiment 39: An integrated circuit including a security circuit with read-only memory (ROM), wherein the security circuit comprises a ROM array including a plurality of encrypted ROM lines, each encrypted ROM line of the plurality of encrypted ROM lines being different from each other encrypted ROM line of the plurality of encrypted ROM lines, and the security circuit further comprises a ROM controller coupled to the ROM array and configured to control access to the ROM array in response to at least one digest value generated based on the plurality of encrypted ROM lines.

[0196] Exemplary embodiment 40: The integrated circuit of exemplary embodiment 39, further comprising a digest calculation circuit configured to calculate at least one digest value based on the plurality of encrypted ROM lines.

[0197] Exemplary embodiment 41: The integrated circuit of exemplary embodiment 40, wherein the digest calculation circuit is part of a ROM block that includes a ROM array and a ROM controller.

[0198] Exemplary Embodiment 42: The integrated circuit of any one of exemplary embodiments 39 to 41, wherein the encryption key is selected to ensure that multiple encrypted ROM lines do not overlap. For example, at least one encryption key (whether predefined or obtained in some manner) can be used in an iterative process that is performed to reduce the number of overlapping encrypted ROM lines (e.g., to zero, or at least below a threshold value).

[0199] Exemplary Embodiment 43: The integrated circuit of any one of exemplary embodiments 39 to 42, wherein the encryption algorithm is selected to ensure that multiple encrypted ROM lines do not overlap. For example, at least one encryption algorithm (whether predefined or obtained in some manner) can be used in an iterative process performed to reduce the number of overlapping encrypted ROM lines (e.g., to zero, or at least below a threshold).

[0200] Exemplary embodiment 44: A method for resilient integrity checking of read-only memory (ROM), comprising: generating a first set of encrypted ROM lines by applying an encryption algorithm and an encryption key to a plurality of lines of the ROM; determining a quantity of duplicate encrypted ROM lines among the plurality of encrypted ROM lines; modifying at least one of the encryption algorithm or encryption key based on the quantity; and generating a second set of encrypted ROM lines by applying the modified at least one encryption algorithm or encryption key to the plurality of lines of the ROM.

[0201] Exemplary Embodiment 45: The method of exemplary embodiment 44, further comprising repeating the modifying, applying for at least one modified encryption algorithm or encryption key, and determining until the quantity is zero.

[0202] Exemplary Embodiment 46: The apparatus of any one of exemplary embodiments 24 to 35, wherein the ROM controller is configured to provide the at least one digest value to a component external to the ROM.

[0203] Examples of Electronic Devices for ROM Security 14 illustrates various components of an exemplary electronic device 1400 that can implement ROM security in accordance with one or more described aspects. The electronic device 1400 can be implemented in any form, including any one or combination of fixed, mobile, standalone, or embedded devices, consumer, computer, portable, user, server, communication, telephone, navigation, gaming, audio, camera, messaging, media playback, and / or other types of electronic devices 1400, such as smartphones shown in FIG. 1 as device 102. One or more of the illustrated components can be realized as discrete components or as integrated components on at least one integrated circuit of the electronic device 1400.

[0204] The electronic device 1400 may include one or more communications 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 communications transceivers 1402 include near field communications (NFC) transceivers, wireless personal area network (PAN) (WPAN) radios conforming to various IEEE 802.15 (Bluetooth®) standards, wireless local area network (LAN) (WLAN) radios conforming to any of the various IEEE 802.11 (WiFi®) standards, wireless wide area network (WAN) (WWAN) radios for cellular phones (e.g., those conforming to 3GPP®), wireless metropolitan area network (MAN) (WMAN) radios conforming to various IEEE 802.16 (WiMAX™) standards, infrared (IR) transceivers conforming to the Infrared Data Association (IrDA) protocol, and wired local area network (LAN) (WLAN) Ethernet transceivers.

[0205] The electronic device 1400 may also include one or more data input ports 1406 capable of receiving any type of data, media content, and / or other input, such as user-selectable input, 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 may include USB ports, coaxial cable ports, fiber optic ports for fiber optic interconnects or cabling, and other serial or parallel connectors (including internal connectors) for flash memory, DVDs, CDs, etc. These data input ports 1406 may be used to couple the electronic device to components, peripherals, or accessories such as keyboards, microphones, cameras, or other sensors.

[0206] The electronic device 1400 of this example includes at least one processor 1408 (e.g., any one or more of an application processor, microprocessor, digital signal processor (DSP), controller, etc.), which may include a combined processor and memory system (e.g., implemented as part of an SoC) that processes (e.g., executes) computer-executable instructions to control the operation of the device. The processor 1408 may be implemented as an application processor, an embedded controller, a microcontroller, a security processor, an artificial intelligence (AI) accelerator, etc. In general, a processor or processing system may be implemented at least partially in hardware, which may include components of 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 implementations in silicon and / or other materials.

[0207] Alternatively or additionally, electronic device 1400 can be implemented with any one or combination of electronic circuitry, which may include software, hardware, firmware, or fixed logic circuitry implemented in association with processing and control circuitry, generally shown at 1410 (as electronic circuitry 1410). This electronic circuitry 1410 can implement executable or hardware-based modules (not shown in FIG. 14), such as through processing / computer-executable instructions stored on a computer-readable medium, through logic circuitry and / or hardware (e.g., FPGA, etc.), etc.

[0208] Although not shown, electronic device 1400 may include a system bus, interconnect, crossbar, data transfer system, or other switch fabric that couples various components within the device. The system bus or interconnect may 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 or local bus utilizing any of a variety of bus architectures.

[0209] The electronic device 1400 also includes one or more memory devices 1412 that allow for 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. The memory devices 1412 may therefore be distributed across different logical storage levels of the system and in different physical components. The 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, an operating system 1414 may be maintained as software instructions in the memory devices 1412 and executed by the processor 1408.

[0210] In some embodiments, electronic device 1400 also includes an audio and / or video processing system 1416, which processes audio data and / or passes audio and video data to audio system 1418 and / or display system 1422 (e.g., a video buffer or screen of a smartphone or camera). Audio system 1418 and / or display system 1422 may include any device that processes, displays, and / or renders audio, video, display, and / or image data. Display data and audio signals can be communicated to the audio and / or 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, audio system 1418 and / or display system 1422 are external or separate components of electronic device 1400. Alternatively, the display system 1422 may be an integrated component of the exemplary electronic device 1400, such as, for example, part of an integrated touch interface.

[0211] The electronic device 1400 of Figure 14 is an example implementation of the apparatus 102 of Figure 1, an example implementation of a device capable of implementing the analysis 344 of Figure 4, or an example implementation of a device capable of implementing any of the methods of Figures 9-13. Accordingly, the electronic device 1400 can include the security circuit 106, which can be a separate IC chip or can be included as part of another IC chip or device, such as the processor 1408, the electronic circuit 1410, or the memory device 1412. Thus, one or more of the illustrated components can be integrated on the same IC chip, such as an SoC, or at least on a single PCB.

[0212] 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. Thus, the memory device 1412 can store peripheral device design code 342, interface specifications 332, etc. The electronic device 1400 may also, or instead, implement the iterative process of FIG. 10. Furthermore, the ROM 118 / 206 may include any of the components of FIGS. 4-6, for example, as part of the security circuit 106. Furthermore, the ROM 118 / 206 may be implemented in any of the components of the electronic device 1400 described above, either as part of the security circuit 106 or separate from the security circuit 106. Thus, the ROM security principles described herein may be implemented by or in association with the electronic device 1400 of FIG. 14.

[0213] Unless the context dictates otherwise, the use of the word "or" herein may be considered an "inclusive or" or the use of a term permitting the inclusion or application of one or more items linked by the word "or" (e.g., the phrase "A or B" may be interpreted as permitting only "A," permitting only "B," or permitting both "A" and "B"). Also, as used herein, a phrase referring to "at least one" of a list of items refers to any combination of those items, including single members. For example, "at least one of a, b, or c" includes not only a, b, c, ab, ac, bc, and abc, but also multiple combinations of the same elements (e.g., aa, aaa, aab, aac, abb, acc, bb, bbb, bbc, cc, ccc, or other permutations of a, b, and c). Additionally, items depicted in the accompanying figures and terms discussed herein may refer to one or more items or terms, and thus, the singular or plural forms of items and terms may be referred to interchangeably herein. Although implementations of ROM security have been described in language specific to particular features and / or methods, the subject matter of the appended claims is not necessarily limited to the particular features or methods described. Rather, the particular features and methods are disclosed as example implementations of ROM security.

Claims

1. 1. An apparatus for a secure read-only memory (ROM), comprising: a ROM array containing encrypted ROM data stored at a plurality of ROM addresses; a ROM controller coupled to the ROM array, the ROM controller comprising: an encryption circuit configured to perform a decryption operation on the encrypted ROM data based on the plurality of ROM addresses at which the encrypted ROM data is stored; a ROM access interface coupled to the encryption circuit and the ROM array, the ROM access interface comprising: reading the encrypted ROM data from the ROM array based on a ROM address corresponding to the encrypted ROM data; after reading the encrypted ROM data, decrypting the encrypted ROM data using the encryption circuit using the ROM address corresponding to the encrypted ROM data to generate decrypted ROM data; configured to transfer the decoded ROM data to an interconnect; The encryption circuit a keystream circuit configured to generate a key based on a ROM address; a manipulation circuit configured to generate manipulated encrypted ROM data by at least one of permuting or substituting two or more bits of the encrypted ROM data; a data combining circuit coupled to said keystream circuit; the data combination circuit is configured to generate the decrypted ROM data by combining bits of at least one of the keys with bits of the manipulated encrypted ROM data using logical operations.

2. 2. The apparatus of claim 1, wherein the encryption circuitry is configured to perform the decryption operation on each ROM datum of the encrypted ROM data based on a respective ROM address of the plurality of ROM addresses, the respective ROM address configured to identify the respective ROM datum within the ROM array.

3. 10. The apparatus of claim 1, wherein the ROM access interface includes a finite state machine (FSM) configured to provide access to the encrypted ROM data as decrypted ROM data for a boot procedure.

4. the ROM controller includes an address adjustment circuit configured to adjust a ROM address to generate an adjusted ROM address; 2. The apparatus of claim 1, wherein the ROM access interface is configured to adjust the ROM addresses using the address adjustment circuit to read the encrypted ROM data stored at the plurality of ROM addresses.

5. 5. The apparatus of claim 4, wherein the address adjustment circuitry is configured to at least one of permute or permute two or more bits of each one of the ROM addresses to generate the adjusted ROM addresses.

6. the encrypted ROM data includes a bit corresponding to a ROM command and a bit corresponding to a check code of the ROM command; 2. The apparatus of claim 1, wherein the decoded ROM data includes bits corresponding to the ROM instruction and bits corresponding to the check code of the ROM instruction.

7. The ROM controller a ROM checker circuit coupled to an output of the encryption circuit, the ROM checker circuit comprising: calculating another check code based on the ROM instruction of the decoded ROM data; performing a comparison involving the check code of the decoded ROM data and the calculated check code; The apparatus of claim 6 , configured to generate an error signal based on the comparison.

8. 7. The apparatus of claim 6, wherein each encrypted ROM data of the encrypted ROM data stored at the plurality of ROM addresses of the ROM array is different from each other encrypted ROM data of the encrypted ROM data stored at the plurality of ROM addresses of the ROM array by an encryption scheme based on the plurality of ROM addresses at which the encrypted ROM data is stored.

9. The apparatus of claim 1 , wherein the apparatus comprises a mobile device.

10. 1. A method for a secure read-only memory (ROM), comprising: Obtaining a ROM read request including a ROM address associated with a ROM array including encrypted ROM data stored at a plurality of ROM addresses; reading encrypted ROM data from the ROM array using the ROM address; after reading the encrypted ROM data, decrypting the encrypted ROM data using the ROM address to generate decrypted ROM data; transferring the decoded ROM data to an interconnect; The decoding step comprises: generating at least one key based on the ROM address; manipulating bits of the encrypted ROM data to generate manipulated ROM data; and performing a logical operation using the at least one key and the manipulated ROM data to generate the decrypted ROM data.

Images