Enhance system security with better data-at-rest encryptionEmbedded systems designers can protect sensitive data that's on a device's hard drive (data-at-rest) by using encryption techniques.
1 From copiers randomly selected from a used copier warehouse, investigators recovered lists of wanted sex offenders, drug-raid targets, architectural design plans, personal identification information (name, address, Social Security number), and medical records—including blood-test results and a cancer diagnosis.
When asked whether this could be prevented, one copier company said that customers could purchase a $500 option that will erase copied images from the hard drive after use. Give the guy who wrote those couple lines of code a bonus!
Another obvious solution to this problem is data-at-rest protection. Data-at-rest protection is a when data stored on a device and not in transit, known as data at rest, is either encrypted or follows certain protocols that include encryption to protect the data from unauthorized access. The storage media for an embedded system may include hard disk drives, flash memory, and attached USB thumb drives.
• Medical sector: the Health Industry Portability and Accounting Act (HIPAA) requires that patient data stored within medical devices is protected.
• Financial sector: the Payment Card Industry (PCI) data security standard (PCI DSS) requires the protection of credit card information within financial processing systems.
• Government and security-conscious enterprises: Data-at-rest protection within smartphones and tablets is a requirement if handhelds are used for the processing of sensitive information.
This article discusses approaches for protecting data-at-rest.
Choosing the storage layer
Hardware layer: With full-disk encryption (FDE), the entire medium used for storage is encrypted. All the data that goes on the storage medium is encrypted, including certain hidden files, such as the operating system's temporary files and swap space. The advantage is such files are not exposed. However, the drive itself is not encrypted, leaving the master boot record exposed.
When FDE is handled within the medium peripheral itself, it's referred to as a self-encrypting drive (SED). SEDs are common in the laptop market. The advantage of SEDs for the embedded systems developer is that little or no new software must be written to take advantage of the data-protection facilities. Encryption is performed with specialized hardware within the storage device, offloading the main embedded applications processor. If self-encrypting storage media is feasible, it's an excellent choice due to ease of use, excellent performance, and the ability to hide the storage encryption key from the main applications processor and memory. Unfortunately, many embedded systems will be unable to use the available standalone SED products due to form-factor limitations.
Block manager layer: Encryption can be performed at the next level up, the device-management layer, typically a block-oriented driver. Protection at this level may cover the entire managed device (FDE). The performance implications of this approach vary. If the embedded platform contains a symmetric encryption accelerator, the overhead is likely to be reasonable, while a purely software cryptographic implementation may cause a dramatic loss in performance. Embedded systems developers can architect the encryption facilities such that the device driver calls out to generic medium block encryption routines, ensuring that software is easier to maintain across different generations of the embedded product that may use different types of storage.
File system layer: The next candidate for data-at-rest protection is the file system. The major advantage of implementing storage protection at the file system layer is to provide finer granularity over the choice of information that requires storage confidentiality. This is especially important if encryption is performed in software with minimal or no hardware acceleration. Depending on the file system implementation, developers may be provided options for encryption at the volume level or at the individual file level.
Applications layer: Finally, applications can add their own data protection, either using underlying file-system encryption features or a custom implementation. For example, an audit logging application can encrypt its audit records prior to calling the standard file system output functions.
For volume, file, or application-level data protection, developers can employ separate keys for these groups of data rather than a single key for the entire system. This is a sensible application of "least privilege" principles.
Developers resorting to custom, application-level approaches will also need to design their own key-management system, whereas users of encrypting file systems or SEDs can use the key-management framework provided by the product supplier.
Page 1 of 4Next >
Currently no items