Data in the stream: minimizing security risks in embedded devices

The way verified data is stored on an embedded device can add a security risk. We provide an overview of why data verification matters, the risks involved, plus a clever approach some experts are using to deal with that.

As we have spoken about previously, ensuring that data on an embedded device is verified correctly can prevent costly security risks for the manufacturer. And when it comes to securely storing that data, an important factor is where and how the data is actually stored.

Why storing crucial data in the same stream is a security risk

When talking about embedded device security, we are particularly interested in so called security-specific data – that’s the hash data and other important pieces needed to do fs-verity for a file. The fs-verity implementation on ext4 stores that security-specific data at the end of a file, and then it hides that data. In principle, this makes the data more secure, as it is then tougher to find or locate (and might therefore be able to quietly stay uncorrupted or untampered). In practice though, the data is not hidden very well. Why? Because on a block device, simply accessing the next block can allow you to find the hidden data.  

What is fs-verity?

Fs-verity is a tool that validates a single file, or selected portion of a file system. It checks the media for any corruption or tampering. 

Learn more about fs-verity, dm-verity, and fs-crypt by reading our whitepaper, “Linux file system verification – understanding fs-verity.” 

Crossing data streams for better data security

One possible option that has been suggested is to use multiple streams for the data storage. With this method, the security-specific data is stored in a different stream, so it is still connected to the file (through the file system) but not directly accessible. This is a method that makes sense, it has worked for us, and is what we plan to release as a feature of Tuxera Reliance Velocity. 

From a user’s point of view, there is no difference in the implementations between ext4 and Tuxera Reliance Velocity. Both the IOCTL commands and the user space tools will be able to utilize the security specific data the exact same way. Making a copy of the file and security data is actually easier with separate streams – this is the use case that is followed by validated apps in the Google Play Store (for example).  

Final thoughts

Leaving data at the end of a file and hiding it is a method with real risks to embedded device security. Those risks can end up incurring costs to device manufacturers due to important data getting maliciously corrupted, in addition to loss of valuable development time. However, by storing the security-specific data to a different stream instead, risk is minimized – the data is harder to access, but still connected via the file system. Want to know more about tackling data security risks in embedded devices? GET IN TOUCH