Many systems use external standard flash memory chips to store the processor’s operating program that does not include embedded non-volatile program storage. This is great because it allows for easy flash expansion and software modification, perhaps on the production line as a customer download or during maintenance operations. The downside is that the OEM loses control over the contents of the flash memory, potentially allowing unauthorized copying or modification.
However, it’s not just revenue loss to worry about. If malware is downloaded into the system, the OEM’s reputation can be affected. For systems such as medical devices, OEMs may even face liability issues.
take back safe
Hardware security chips can help hand control back to OEMs. Programmable, highly secure smart card processors have been available for some time, but require additional firmware to be written and add an unacceptable cost to the system. Hardware authentication chips, on the other hand, are turnkey devices that do not require internal programming or detailed knowledge of cryptographic algorithms, and are affordable.
The way these chips work is very simple. The system microprocessor sends a challenge to the chip, which then uses an encryption algorithm to combine the challenge with a secret stored securely in non-volatile memory. The response is then sent back to the system. The algorithm implemented inside the chip is chosen in such a way that an observer watching the bus can see the challenge and response, but cannot determine the value of the key. Depending on how securely the chip stores secrets, replicating such a personalized chip can be very difficult.
While these chips can be used in a variety of ways to add security to a system, two software protection features are of particular interest. The first is Secure Boot, which provides a way to ensure only real programs are executed while still allowing upgrades to take place. Second, anti-cloning, which prevents unauthorized system builds or full duplication of designs.
A system-on-chip (SoC) device typically contains a small boot ROM that contains programs that initialize the chip’s operation before executing the external flash contents. This boot ROM can be easily reprogrammed to work with an external verification chip.
The OEM stores the verification values in flash memory with the program before the system ships. This is calculated by combining the program’s digest with the secret, a copy of which is stored in the authentication chip. Use a hashing algorithm such as Secure Hash Algorithm 1 (SHA-1) or SHA-2 to generate the program digest. A hacker might be able to change the contents of the flash, but without knowing the secret, there is no way to generate a new verification value.
During the execution of the code in the boot ROM, the microprocessor generates in real time a summary of the executable program stored in flash memory (see Figure 1). This digest is then sent to the authentication chip as a challenge. The chip combines the digest with its internally stored secret, and can treat the response as a kind of program signature. If the response matches the verification value stored in the flash, execution of the flash contents is allowed to proceed; if not, the microprocessor can loop to the downloader to wait for a valid flash image to be loaded.
Figure 1: The boot ROM can work with a microprocessor that generates a digest of the executable program stored in flash memory and sends it to the authentication chip as a challenge.
If a hacker could send modified software to the authentication chip, read the response using a logic analyzer, and then store this verification value in flash along with the modified code, this scheme could be a security hole. However, there are several ways to solve this problem.
The best solution is to use an authentication chip that does not return the expected authentication value but takes it as input and returns true/false to indicate a match. The digest is often too large and the chip too slow for an attacker to guess the correct validation value to modify the code. For even more security, the security chip can combine a random challenge (or possibly the current time or processor serial number) with true/false encryption and return it to the processor. This way, simple switch-like circuit modifications cannot be used to fool the processor.
Another way is to mechanically prevent access to the pins of the security chip. For ASIC SoCs, the security chip can be purchased as a die and integrated into the main package as a multi-die package. Another approach is to buy a security chip similar to a BGA package that does not allow probing since the pads are completely hidden. Or a security chip on the board could be conformally coated with epoxy to prevent access.
In some cases, the system may be able to use the software in the boot ROM to calculate a digest of the flash program. However, validating the entire memory array at boot time can be too time-consuming, especially for systems with larger flash memory. There are two ways to solve this problem: incremental verification or hardware acceleration.
Using an incremental verification scheme, only the boot ROM code is used to verify the module loader stored in flash. Before loading each new module for execution, the module loader performs the same verification process on that module using the authentication chip. These modules can also be validated ahead of time during idle time to improve incident response performance.
Modern processors don’t always include hardware hashing engines, but Advanced Encryption Standard (AES) or Triple Data Encryption Standard (3DES) engines are very common. These encryption algorithms can easily be used to generate program digests at hardware speed by configuring the encryption engine to operate in Cipher-based Message Authentication Code (CMAC) mode.
Most OEMs now use subcontractors to manufacture their equipment. As a result, the system is sometimes overbuilt for local sale or possibly on the grey market. Alternatively, a competitor or hacker might clone the system and sell it at a lower cost because they don’t have to invest in software development. Manufacturing costs can be reduced if the system uses only off-the-shelf components, but this makes it easier for unauthorized systems to be built.
Using a hardware security chip could put an end to these clones without significantly increasing the size or cost of the system. Compiled into the embedded software are a number of tests to check for the presence of a properly programmed hardware security chip. The OEM controls the secrecy that is programmed into the chip and controls the distribution of the programmed chip to subcontractors. Alternatively, chip suppliers can manage chip personalization for OEMs.
There are several ways to implement these software tests. An easy way to do this is to compile the challenge and expected response in software. If the security chip is missing or the password is wrong, the responses do not match, and the system can be disabled or returned to download mode for a corrected file. Add these checks in many places in the program, and it is very difficult for a hacker to remove them, especially when the code is verified by ROM on initial load.
Other options for these software tests include distributing challenge generation and response checks in various parts of the program. The response from the security chip can be used as a key for instant software module decryption. The response can be XORed with a single constant, which is then used as a jump vector. If the security chip supports it, multiple challenges can be sent from different code sections and combined to generate a single response.
In a typical implementation, many different types of tests are included in the chip, so even if one mechanism is defeated, the others still function. Ideally, these tests rely on multiple secrets stored in the security chip to ensure that even if one secret value is compromised, the security of the entire system is maintained.
None of this would matter if it was easy to get the secret from the authentication chip. In this case, a hacker can create the correct software verification values, or a system cloner can use a simple microprocessor to model the security chip. Authentication chips protect secrets in at least two ways: using strong cryptographic algorithms and using special hardware chip design techniques to prevent direct or indirect attacks on the silicon.
In the past, some form of Linear Feedback Shift Register (LFSR), also known as Cyclic Redundancy Check (CRC), was used as a hashing algorithm. These algorithms are common due to the low cost of implementation, but with modern high-speed PCs, these algorithms can usually be analyzed and cracked in a short time.
The LFSR/CRC algorithm is especially weak if the secret size is too small, since a brute force attack is possible with relatively simple software. There is no general rule about what size is large enough, but most modern systems use keys of 128 bits or longer.
Currently, the SHA algorithm is the best choice for secure boot and anti-cloning. SHA-1 is secure enough today, but it has some known weaknesses and has been superseded by the SHA-2 family (including SHA-256 and SHA-512, etc.). Since the life cycle of most embedded systems is measured in years, using the latest algorithms ensures the security of the system even at the end of its useful life.
Authentication chips can also be purchased that use public key (asymmetric) algorithms, which are generally slower and more complex. The software on the system side can also be much more complex. Compared to authentication chips that use hashing algorithms, they can improve the security of secure boot schemes with little or no additional benefit to software cloning.
But a strong algorithm is not enough. Microprobes are easy to buy on eBay these days, so the chip must prevent an attacker from etching away the package and microprobing some of the internal nodes to gain access to these secrets. Modern chips prevent this with active internal shielding throughout the chip, narrow width metal over three layers, additional encryption of the internal blocks, and no exposed test pads.
Hackers may also try to use high or low voltages or too high a clock frequency to get the authentication chip to reveal its secrets. These attacks can be defended against with an internal tamper detector that shuts down the chip if one attempts to operate outside of its normal operating range. These are common security blocks, and most chip manufacturers add other proprietary security components on top of the usual tamper blocks.
Authentication chips in embedded systems can detect unauthorized modification or duplication of system software stored in flash memory. Additionally, they can be used in a variety of other ways to exchange session encryption keys, provide node authentication to remote servers, verify serial number storage, securely store manufacturing and/or maintenance history, and various other security-related functions.
High-security authentication chips do not require designers to have any special cryptographic knowledge and can be integrated into embedded systems without compromising time-to-market. Often available in small packages, they are suitable for even the most space-sensitive applications. The Atmel AT88SA102S is one such chip. It combines the SHA-256 algorithm with a 256-bit key length and an easy-to-use one-wire interface compatible with all microprocessors. The design includes an active shield covering the entire circuit, a tamper detector, and encrypted internal memory.
Reviewing Editor: Guo Ting