Is dm-crypt right for your design?

Posted by: Thom Denholm

Security concept

If I were in London last week instead of this one, I would have wanted to attend the 2nd annual Secure IoT Conference. Several companies have recent white papers on security also. How does security factor into a file system on an embedded device? One example is encryption. We will focus on Linux, which has the most options today - though other RTOS environments will probably catch up soon.

Linux media encryption using dm-crypt

On Linux, dm-crypt is a transparent disk encryption subsystem included in the Linux kernel. It is implemented at a device mapper, which means it can be stacked on top of devices or even other device mappers. The device, in this case, is a block device, used by the file system to store data.

So dm-crypt can encrypt whole disks, partitions, software RAID volumes, and logical volumes. The block device can be fixed or removable. With FlashFX Tera, the block device could represent NAND or NOR flash as well, an option not commonly available in unpatched Linux kernels.

The important thing to know is that dm-crypt encrypts the data and writes it onto the storage device (by way of the device driver) using a storage format called LUKS.

LUKS (Linux Unified Key Setup) is the format used on the drive itself, and this format is essentially used in place of a file system. This dm-crypt system sits between the filesystem and the media. As an example, Reliance Nitro writes file data or metadata, or even transaction point information, to the block device driver, and that data gets pushed through dm-crypt which then stores the data in LUKS format on the media. The blocks are encrypted, but still protected by the various methods used in Reliance Nitro.

Other Linux encryption options

Another option in Linux is fscrypt, which provides protection at the file and folder level. Each directory may be encrypted separately with a different key. This method is designed to protect against "occasional temporary offline compromise of the block device content, where loss of confidentiality of some file metadata, including the file sizes and permissions, is tolerable."

File based encryption using fscrypt is supported in Android versions 7.0 and later. Like many of the newest kernel changes, this one is under constant revision. For example, in Linux kernel 4.18, fscrypt support for Speck128/Speck256 algorithms was added.

What are you planning to use?

As we examine future encryption options for Reliance Nitro, we come to the question of how are you planning to use encryption in the future? Is block level encryption the best option, or does your design require file level encryption? Is unencrypted metadata acceptable, or does your design require that to be protected as well? Which encryption algorithms are you considering? And, perhaps most important of all, which RTOS do you plan to use encryption on for your design?


Comments (0)


Add a Comment





Allowed tags: <b><i><br>Add a new comment: