By Arnaud Le Mignon
Field Applications Engineer, Future Electronics (France)
Security is a type of technology which, like RF circuit design or DC-DC conversion, often appears complex and difficult to non-specialist design engineers embarking on it for the first time.
Like RF and power conversion, security technology has generated its own jargon and obscure acronyms. There are also usually many different methods for achieving the same goal. And just as in the fields of RF and power, security has attracted huge investment by semiconductor manufacturers, leading to a proliferation of products with complex specifications that can be hard to compare precisely on a like-for-like basis.
Despite the apparent difficulties, however, before long almost every electronics system is going to need to embed security capabilities to a greater or lesser degree. Figure 1 shows a forecast of explosive growth in the use of security technology in Internet of Things (IoT) devices in the coming years. Likewise the automotive market is expected to be a very large-scale adopter of enhanced security devices, as car manufacturers seek to harden their products’ defences against the threat of intrusion into vehicles’ software systems. In fact, across almost the entire electronics industry design engineers with no special security expertise are going to have to make decisions and choices about security system architectures, and about the components required to meet the needs of their application.
Fortunately, semiconductor manufacturers are increasingly recognising the need to provide for the common, basic security needs of mainstream electronics designs. This article describes the encryption and anti-cloning technologies which may be used to protect electronic products, and the types of IC which best enable design engineers to implement security functions quickly and easily.
Why are security capabilities needed?
Electronics OEMs have two main interests in implementing security:
• to protect the Intellectual Property (IP) bound-up in their products. This IP can reside in the software running on a device such as a microcontroller, or in the stream of board-level signals passing between devices. This IP may be stolen by cloning or by tampering with components such as Flash memory chips that store boot code or applications. The risk of IP theft and cloning is of particular concern to OEMs which outsource the final assembly of their products to Contract Electronics Manufacturers (CEMs).
• to prevent snooping, theft or corruption of data transmitted via a network such as the internet
The OEM’s expectation should not be to eliminate the risks of tampering, cloning, data theft and so on. There is no effective security technology
in existence – and there never will be – that can be guaranteed to be unbreakable, although implementing hardware security features always
provides stronger protection than software security. In the US, the Federal Bureau of Investigation’s success in decrypting an Apple iPhone® used in the 2015 San Bernardino attack demonstrates vividly the limits of even sophisticated anti-intrusion technology. Instead, the OEM’s goal should be to make interfering with its products, not impossible, but merely very difficult.
Consider a typical example of an end-product requiring protection from cloning or IP theft. A set-top box contains valuable application software which must not be copied or corrupted. The manufactured product itself also requires protection from cloning by its contract manufacturer – that is, the unauthorised production of additional units beyond the quantity ordered by the OEM, to be sold privately by the contract manufacturer.
Before now, designers have implemented anti-cloning/anti-theft protection using a NOR Flash memory with block protection for boot-code storage, combined with a standard Single-Level Cell (SLC) NAND Flash memory for system firmware and application-code storage. A secure EEPROM such as an Atmel CryptoMemory® part is another commonly used type of component for tamper-proof code storage.
Another solution from Cypress Semiconductor achieves the same goal in a simple, cheap implementation. The new Cypress SecureNANDTM memory, shown in Figure 3, has an on-chip security controller, providing a single non-volatile memory with integrated block protection. Available in densities of 1Gbit, 2Gbits and 4Gbits, it can securely store boot code, firmware and applications.
Protected by a secret known only to the OEM, the SecureNAND devices may be programmed by the OEM before shipment to the CEM. By shipping only as many memory chips as are required for the intended production run, the OEM can prevent the CEM from cloning additional production units.
The cost and effort involved in breaking a secure NOR Flash memory or a SecureNAND device would be too large to make an attack on a set-top box design worthwhile. Nevertheless, the contents of secure memory can be copied by determined and well-resourced hackers. Used microprobes, an instrument employed in semiconductor wafer fabrication, are readily available for sale on Ebay for no more than a few thousand dollars. These allow the user to analyse the voltage variations at the processor pins connected to a memory chip, as shown in Figure 4.
So an even more secure defence against cloning and code theft is available by implementing the design in a secure FPGA, such as the SmartFusion2 system-on-chip devices from Microsemi, a long-standing supplier of secure ICs to the military and aerospace markets.
The FPGA integrates the required storage for boot code, firmware and applications on-chip, so that memory accesses performed by the CPU are not accessible via the chip’s pins. In addition, the chip is programmed to detect attempts to tamper with it, and automatically deletes the contents of on-chip memory when an intrusion event occurs, rendering the information unreadable.
How to harden system data security
Protection of IP, then, can be assured through the use of off-the-shelf secure devices which any OEM can readily implement. The same is true for the protection of data, either as it moves between components on the board, or as it moves between devices over a network.
Various forms of encryption are used to ensure data security, and therefore protect the end-user’s privacy. The details of the operation of cryptographic technologies are extremely complex, and the technologies themselves carry a bewildering and non-intuitive array of labels: RSA, Elgamal, DSS, Diffie-Hellman, Guillou-Quisquater, Fiat-Shamir and Elliptic Curve Cryptography (ECC) are just a selection of the terms that designers might come across.
It could take months of dedicated study for the non-specialist design engineer to get to grips with the many different flavours of cryptographic technology. Fortunately, there is no need for this. Common, off-the-shelf cryptographic ICs available today from suppliers such as NXP Semiconductors, STMicroelectronics and Atmel (part of Microchip) provide ready-made implementations of highly secure encryption schemes.
The feature to look for is a hardware cryptography acceleration engine. This provides three benefits:
• security implemented in hardware is inherently harder to crack than security implemented in software
• a hardware implementation relieves the OEM system designer of software integration effort, and thus speeds end-product development
• a hardware acceleration engine has its own, dedicated resources on-chip and leaves the CPU free to implement the core application
The most common form of encryption provided by IC manufacturers such as NXP, ST and Atmel is Advanced Encryption Standard (AES), in 128-bit or 256-bit formats. AES is a symmetric-key technology – an AES engine can both encrypt and decrypt data – which uses a secret key known only to users for both encryption and decryption, as shown in Figure 5.
In implementing AES, the most important decision for the system designer to make is architectural: whether to implement AES capability through a discrete companion device, or with a microcontroller featuring a built-in cryptographic engine. Discrete companion devices in the Atmel CryptoAuthenticationTM family, for instance, work with any MCU, are small, require only a single GPIO and use very little power. The use of a companion chip gives the designer the flexibility to choose exactly the right MCU for their application, without limiting the choice to those with built-in cryptographic capability.
On the other hand, an MCU with a hardware encryption engine eliminates the need for an additional companion chip, making for a smaller circuit which is cheaper and easier to assemble and which has a lower component count. MCUs in the Atmel SAM S series, for instance, and the STM32L series from STMicroelectronics include an AES-256 hardware encryption engine, and NXP LPC43S series MCUs include an AES-128 encryption engine.
An AES implementation requires the OEM to generate a secret key for each secured device, and to operate rigorous key management. The OEM must register and securely store the private key assigned to each device: this calls for a managed process covering both software for data storage and hardware including regulation of physical access by staff and contractors to secure servers.
To maintain security throughout the end-product’s supply chain, the AES security device may be shipped directly to the OEM, so that the OEM can programme the secret key into the device. It can then ship the programmed security device to third-parties such as CEMs for final assembly, with no need to share the key with these third parties, as shown in Figure 6.
Low barriers to implementation of basic security
The threats of cloning, IP theft and data tampering are real and present. This article shows that basic but highly effective forms of protection
are readily available off-the-shelf today from merchant semiconductor manufacturers. Tools and simple instruction sets or programming interfaces are supplied with secure memories, security companion chips and security microcontrollers. Design engineers do not need to become security specialists in order to secure their product designs today, and the additional component and development costs are negligible compared to the value of the protection they provide for both IP and data.