MPUs and MCUs Figure 3: TrustZone and MPU partitioning


The first building block of any cryptographic protocol is a TRNG (True Random Number Generator), which shall be validated and tested for its entropy properties and quality of randomness. For local storage, symmetric algorithms like AES with multiple modes is mandatory, to protect bulk of data. In combination with hashing algorithms (“cryptographically secure checksums”) like SHA-2 or SHA- 3 the application can perform simple authentication checks and verify that data contents have not been modified. For advanced connectivity, asymmetric algorithms like RSA or ECC can support identity verification in client / server connections, help to derive ephemeral session keys or verify source and legitimacy of a firmware update. Such accelerators shall also be able to generate keys on-chip, for local usage.


But the really hard problem is key management, as keys must be kept confidential, integer and available. One must consider when the key is injected (stored), how to transport it, load it in the crypto hardware and protect it from leakage. Ideally the application shall never handle key material in clear, avoiding exposure. A simple way to prevent this is to handle it inside the TrustZone secure area, but best is within a dedicated isolated on-chip subsystem. Once keys are stored in the non-volatile memory, techniques like key “wrapping” (key encryption) help to protect privacy. Making the wrapped data unique on every MCU further mitigates keys leakage risks and eliminates cloning threats. For such a mechanism a ‘root of trust’ for storage is needed, in form of an exclusive ‘key encryption key’ unique for each MCU, to ensure no compromise of a specific device allows a ‘class’ attack on all similar units.


DPA and SPA attacks log and analyze power consumption traces to reverse- engineer the key value. These get increasingly cheap and quick to implement, even for non-highly skilled attackers with


www.cieonline.co.uk


limited resources. If physical access to the device is of concern, without other access control means in the system, countermeasures against those threats are required within the crypto engines. Additionally, any monitoring of signals connected to the equipment housing, which can notify the MCU and possibly take a


entities are able to autonomously transfer data to and from memory or peripherals, to improve performance and use the available bandwidth efficiently. Some examples are DMA engines, graphics controllers, ethernet controllers and such. It is vitally important that the MCU can set the security attributes of such agents and implement specific “access filters” on the communication endpoints like memories and memory mapped peripherals. Any processor is useless without input and output capability of signals. Protecting such interfaces from misuse is a fundamental requirement to prevent tampering, as this is the natural way to interact with the MCU. The wary designer should check that the MCU can restrict access to secure I/O ports and peripherals, thereby preventing software to maliciously ‘take control’, interfere or


enforcing the proper authorization via an authentication key and provide access only after successful completion of a challenge-response protocol. Finally, the device shall support and secure the mechanism to return the device to the factory in case of defect analysis, possibly erasing any stored secret asset while keeping the interface secured until reaching its destination.


Figure 4: Secure Crypto Engine


timestamp of the tamper event, will be highly desirable.


The isolated subsystem shall enable a user to provision chosen keys into the device and have those wrapped and securely stored, ready for later application usage. The MCU should support some interface to do this both in field and in factory, allowing easy first-time production, and later update in the field. Such steps shall be secured and not expose any key content while in transit.


In modern MCUs, other functional


snoop the communication, while isolating ports and peripherals from each other. During development and test a Jtag based debugger is mandatory. Such interface is able to access most resources on the chip and therefore constitutes a critical backdoor for any field deployed application. The use cases for securing Jtag are very different: either permanently lock it or keep the debug capability in the field but protect the access. Whatever strategy is chosen, the protection shall not allow to be bypassed,


The final application image, once deployed in the field, might need to be made immutable in some parts, to ensure that it is in a well-known state at any time. To support this requirement, the microcontroller shall have the capability to permanently protect user-defined parts of the non-volatile memory from modification. Last but not least, each microcontroller undergoes a lengthy test process before shipping; many of such test results (trimming values, production specific data etc.) and other settings get stored on the device. This special test mode although not meaningful for an end-user can access, control, and potentially tamper with all chip resources. The manufacturer should ensure that such a potential backdoor cannot be entered maliciously or by mistake, once the device is out of the factory and in customer hands. Searching for a microcontroller supporting the above requirements can be a daunting task. Fortunately, Renesas designed the RA series of microcontroller exactly with such goals. The RA6 and RA4 series include devices with an Arm Cortex-M33 CPU with TrustZone and secure MPUs. They allow programming secure boundaries for all built-in memory types easily and simply. They embed the Secure Crypto Engine, a crypto subsystem (Figure 4) which provides secure element functionality at higher performance and less bill of material cost. The SCE includes state of the art cryptographic accelerators, a TRNG, supports key generation, key injection, implements SPA/DPA countermeasures and a hardware unique key as root of trust. Its DMA controllers, bus masters, peripherals, I/O ports have dedicated security attributes and tamper detection functionality is implemented. The integrated device lifecycle management handles secure/non-secure debugging, programming, supports return material procedures and protects the test mode. Non-volatile memories can be block-wise permanently protected at user’s choice.


www.renesas.com/RA Components in Electronics April 2022 39


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52  |  Page 53  |  Page 54  |  Page 55  |  Page 56  |  Page 57  |  Page 58  |  Page 59  |  Page 60  |  Page 61  |  Page 62  |  Page 63  |  Page 64