The cryptography required for this can prove to be a challenge on an IoT device, especially with older, more specialised or low-performance devices. These devices often lack the necessary hardware support, which is why cryptography has to be performed purely on the software side. This has an impact on system performance on the one hand, but also on actual data security on the other. For example, the secure storage of secrets is not possible without hardware support (TPM chip or similar).
In an industrial environment, this results in a special situation with regard to secure software development, as devices are operated and maintained over a much longer period of time. Replacing devices is time-consuming and therefore expensive, provided that suitable replacement devices with the necessary hardware support can be found.
As many IoT devices have an SD card slot, it makes sense to use this to retrofit security functions. Secure SD cards can be used for this purpose, which enable partitions to be protected and encrypted and secrets to be stored. Such SD cards are offered by the company Swissbit, for example. Using their ‘upgrade kits’ as an example, we have analysed whether (and how) functions can be retrofitted in this way.
With data storage devices such as an SD card, there is a risk that an attacker could gain access to the data on the memory by simply physically removing the memory from the device.
Accordingly, the data on SD cards is often stored in encrypted form. Without hardware support, this can mean a significant loss of performance - especially with large amounts of data.
With secure SD cards, it is possible to actively encrypt individual partitions. By unlocking the SD card, the device gains access to the partitions and can access the data transparently, i.e. the data is made available to the device in decrypted form. This protects the data from unauthorised access. An attacker would have to unlock the SD card in order to access the data.
As the SD cards can be unlocked via various APIs, it is possible to unlock them either from within the application via user interaction (e.g. by entering a PIN) or automatically by storing the access data for the SD card within the device.
This protects the SD card from simple theft or replacement, as an attacker must also extract the access data for the SD card from the device. To make this more difficult, the access data can be stored in protected areas within the device, such as in a TPM module if available.
Optionally, the SD cards can also have a secure element that can be used by the device. This enables the SD cards to securely store secrets within the SD card. This allows the device to access and use these secrets via the SD card. This is useful as many industrial IoT devices do not have such a secure element, making it impossible to securely store access data in cloud systems, for example.
The secure SD cards support various protection modes for partitions on the SD card. These modes include a ‘Write Once’ mode, which prevents data that has been written once from being deleted or changed. This means that data can only be written once and is then unchangeable. This functionality is particularly interesting for audit logs/audit trails, as it is usually necessary to ensure that the logs cannot be subsequently changed. Accordingly, the functionality of the SD card already ensures this.
In addition to the functionality of the secure SD cards already described, which can also be used for IP protection, there is also integration with CodeMeter for the SD cards. This means that WIBU licences can be bound to the SD cards, allowing the cards to be used as licence dongles.
When a system is securely booted, the integrity and authenticity of the entire system is validated during the boot process. This usually begins with the CPU, which checks the first boot loader. Each boot component then validates the next component until the entire system is finally verified and booted. This allows corruption or manipulation of the system to be intercepted during the boot process. Secure Boot requires hardware support and corresponding integration on the software side. Retrofitting Secure Boot on devices is therefore generally difficult. The secure SD card offers an alternative approach to Secure Boot. Here, the boot loader and the operating system of the device are stored on protected partitions of the SD card. The device starts a modified bootloader on the SD card, which unlocks the protected partitions in the SD card and carries out the boot process.
By using the hardware properties as an unlocking method, the SD card is trained on the device and can be unlocked automatically as long as it is inserted in the same device. With further integration work, authenticity checks could also be built in, for example by securely storing the necessary keys on the SD card and protecting the corresponding partitions from write access. This brings the system closer to an actual secure boot.
To summarise, it can be said that appropriate SD cards offer promising options for retrofitting security functions.