In part 1 of this securing embedded memory blog, we considered how your data is at risk and concluded that security needs to start at the hardware level. And as your IIoT’s data resides in memory, that’s the best place to start.
Isolation through partitioning is key to securing embedded memory. Partitioning is also great for achieving higher reliability and safety, better system modularity and accommodating partial uploads (for future software revisions) and partial reboots. So, the good news is that partitioning with security in mind should not be too much of an overhead.
Multicore microcontrollers typically achieve isolation through assigning cores and memory to functions that need to be secure and ones which don’t. Alternatively, some micros are rather more dynamic. For example, ARM has TrustZones for its Cortex-M micros; devices such as the Armv8-M. After power up (or reset), memory is divided into secure and non-secure areas.
Note, though it’s a couple of years old now, check out Demistifying ARM TrustZone for Microcontrollers by Nihal Pasham, who states:
“Security is defined by address, i.e. memory security attributes are really what define security states of the processor.”
A sound observation. And even if you’re not employing a micro as sophisticated as the Armv8-M, then most other micros from a variety of other vendors will have some form of memory protection unit (MPU). Functions can be assigned areas of memory and told what they can and can’t do in terms of reading and/or writing.
Through the MPU, some memory can be assigned to a unique function, and made non-shareable. Other areas of memory might need to be accessed by multiple functions, in which case the locations are only as secure as the least secure function. So, be careful.
Authentication & Encryption
It’s fair to say we’re all familiar with the dangers associated with cleartext in transit, and that encryption is the answer.
The use of SSL and TLS – both of which are cryptographic protocols that provide authentication and encrypt data between servers, computers and other platforms – is a must. However, encryption strength is important. For instance, in the summer of 2022 there were several posts in online forums about some servers supporting SSL/TLS key exchanges that were weaker than recommended.
It was suggested that key exchanges should provide at least 224bits for Diffie Hellman and RSA key exchanges; where the former generates public and private keys on both sides of the transaction, and the latter is a symmetric key exchange that requires the exchange of a public key beforehand.
On the subject of keys, we recommend you give thought to where they are stored. If your system can be breached or easily reversed engineered, and the encryption keys are in obvious places that’s like locking your front door and placing the key under the mat. Again, if you’re on top of your hardware partitioning key storage should not be an issue.
Take the Hard Line
Last year, Embedded.com posted a great article entitled ’10 fatal mistakes in embedded system security’, by Michael Mehlberg, in which he says:
“Most devices focus on the device-specific software and often ignore the OS and lower-level components.”
That’s certainly something with which we agree; and in part 1 of this blog, we stated that it’s the security of the underlying hardware that is often overlooked. Thankfully, some memory OEMs have products that can help. For example, if your embedded system needs an SSD drive – i.e., your system is equivalent of a custom-built PC for an industrial application – drives are available with algorithms present to watch the data 247. Flexxon’s X-PHY is a prime example.
If your system needs an SSD, the memory should ideally have detection and reaction capabilities. It can then be ringfenced with security measures in the OS and in software.
However, whether your system is something as bespoke as a custom-built PC (for a one-off project) or an IoT device that will be produced in volume, securing embedded memory provides a last line of defence, but should be one of the first things you consider during your product development.