Supplier eBooks

Securing Data at Rest A fundamental requirement for device security is to be able to store data securely on the device, but as with all things in the security realm, secure storage has different aspects. If your device has no external connectivity, an MCU is quite simple to secure by disabling or protecting all debugger and programmer access. If you need to ensure that the device cannot inadvertently corrupt itself by reprogramming its flash, many MCUs have the capability to designate part, or all of the flash, as one-time password (OTP), preventing it from being erased and/ or reprogrammed even via self-programming. If, however, your device has external connectivity, you might want to consider logically separating your code and data into "trusted" and "non-trusted" categories, and limiting access of the "trusted" data to only the "trusted" code. Optimally, this isolation should be hardware-enforced via a mechanism such as a Memory Protection Unit (MPU) or Arm ® TrustZone ® . While this isolation is not complete security, it does serve to reduce the attack surface for the "trusted" area. Device Identity If your product is going to be connected to an infrastructure, you are going to need some way of uniquely identifying it. There are a variety of ways to give each device a unique identity. Some MCUs already have a unique identity built-in, but these tend to be simple serialization, which then needs to be mapped so the centralized command center knows which device is deployed where. Although this can be useful, a cryptographic unique identity is even more useful, as it enables additional security solutions, like securing data in flight. A cryptographic identity leverages the properties of various encryption schemes, with the device's identity being the encryption key. There are two basic options: • Symmetric encryption, where the same key both encrypts and decrypts the data. The command center needs to know the symmetric key for each device. • Asymmetric encryption, where two keys are required–one to encrypt the data, and one to decrypt the data. The functionality is interchangeable, enabling the device to keep one key private. The tricky bit is how to get the keys on the device in the first place, such that the command center either knows the key, or knows that the key can be trusted. This is called provisioning. If your security assessment concludes that your product can be installed and provisioned by a trusted technician, then your solution might consist of injecting or even generating keys onsite. If, however, your product is intended to be installed by a general consumer, you will need to provision your devices securely. This can be done during secure programming. Securing Data in Flight There are five goals for securing data in flight: confidentiality, data integrity, data origin, entity authentication, and non- repudiation. The scope of that discussion is beyond this overview. The primary consideration here is, what is the communication infrastructure? If your device is communicating over a proprietary bus within a closed infrastructure, you will have very different solutions for meeting these requirements than if your device is connected to the internet over a Wi-Fi connection. The latter is a worst-case scenario, but it is also the most common use case for Internet of Things (IoT) devices. The fundamental building block to securing data in flight over an IP connection is a cryptographic identity. Although it might seem that a cryptographic identity might be a bit overkill, it becomes a requirement if your product is IP connected. Secure Programming Like most security solutions, secure programming can solve | 4 | | 6 | Headline Learn More 4 • Evaluate the features of the RA2A1 32-Bit Microcontroller • Flexible Software Package (FSP) • Debug on-board (Segger J-Link ® ) EK-RA2A1 Evaluation Kit for RA2A1 MCU Group Headline Learn More 4 • 48MHz Arm Cortex-M23 Core • 8kB DataFlash to Store Data in EEPROM • Capacitive Touch Sensing Unit RA2A1 32-Bit Microcontroller Group

• Cover