By Daniel Lizewski | Sep 23, 2019
Internal flash storage is at a premium on embedded micro-controllers. Typical micro-controllers often have less than a megabyte of internal non-volatile memory, which is shared for both program and data storage. Certain product applications may require much more data storage. Common examples include embedded web servers or graphical resources for user interfaces. The obvious solution is to use external storage such as quad-SPI NOR flash or EEPROM. These parts are relatively inexpensive, fast, and come in a variety of sizes. However, while the amount of storage provided by these devices may be abundant, it comes at the cost of security. Product designers need to consider all possible vulnerabilities to ensure data remains secure.
Many microcontrollers have security mechanisms that prevent reading or modifying the contents of internal Flash, but this is not the case for external storage. An attacker can easily connect an external device to copy or modify the contents of any external storage media for the purpose of stealing data or intellectual property.
If data privacy is required, then the data must be encrypted. If implemented incorrectly, this can lead to significant overhead in both processing time and data storage. This article helps address the security concerns by offering a possible solution that has minimal overhead while remaining transparent to the other layers of the application.
External storage security can be achieved by adding encryption and decryption to the physical storage translation layer of the filesystem. Doing the cryptographic operations in the translation layer ensures that absolutely everything, including the filesystem structure and metadata, is encrypted. This has the added benefit of seamless integration to both the filesystem and application layers since the filesystem only operates on plaintext. All cryptographic operations are handled in the lower layers and are transparent to the higher layers. It is important to note that the plaintext never leaves the safety of the microcontroller. All external communication should be encrypted. The figure below shows the different software layers and where the data is encrypted.
Depending on the type of storage, encrypting in the translation layer can add some restrictions on the way the filesystem can interact with the physical storage. This is only a restriction to highly optimized storage-specific filesystems which exploit asymmetric behaviours of the storage media. For example, Flash storage can change a ‘1’ to a ‘0’ with a relatively quick write operation but requires a longer erase operation to change a ‘0’ to ‘1’. The filesystem can no longer rely on a written ‘1’ being changed to a ‘0’ since it may be stored as a ‘0’ after encryption. The product designer must be aware of this limitation when selecting a filesystem format.
In the Advanced Encryption Standard (AES) the cipher needs both a private key and a uniquely generated Initial Vector (IV). Unlike other modes of operation, if used in counter mode, the IV needs to be unique but does not require randomness. It is important to not re-use IVs because an attacker can then easily decrypt ciphertext if they’ve acquired a known plaintext.
Random access into the filesystem can be achieved by devising an efficient method of determining the IV of any particular AES block. It is too much overhead to store the IV for each block. It is not sufficient to use the address as the counter because doing so would result in re-use of the IV after a page is re-written. It is the responsibility of the product designer to find an appropriate time-memory trade-off that is optimized for the system’s speed and memory requirements.
One possible solution would be to store a base count at the top of each page. The individual IV of any block within the page is calculated as the base count plus the offset into the page.
Each time a page is erased, a new base count should be written to the page. This base count can either be a randomly generated number or a separately stored master count. It is important to consider where the separate master counter is stored because it may result in excessive storage wear or pose a security threat if an attacker can manipulate it to force an IV re-use. One solution is to store the count in RAM and search the filesystem on boot up for the highest base count of any valid block. Again, it is important to validate the blocks so an attacker is unable to manipulate the IV selection algorithm. The easier and less error prone option may be to use a random number, but generating truly random and uncorrelated numbers is a challenge of its own.
Prior to performing encryption/decryption, read and write operations first determine the IV by reading the base count and adding the appropriate offset into the page. Many microcontrollers have built-in AES hardware accelerators capable of performing these encryption/decryption operations seamlessly and with minimal overhead. This can also be implemented in software, but at the cost of performance. This is yet another possible design decision where, depending on the application, the faster but more expensive option may or may not be the best solution for the product as a whole.
It is important to consider system security in all aspects of product design. Designers often forget to consider physical attack vectors such as probing of external data lines. Without proper consideration and implementation, a system may be vulnerable to cyber attacks. Unencrypted external storage leaves a system vulnerable to data theft. If data privacy is required, all external data should be properly and securely encrypted. As discussed in this article, if implemented correctly, this can be done with minimal overhead or impact on the remaining software architecture.
Contact Nuvation Engineering to learn how we can provide system security services for your product design.