Architecting Hardware Protection For Data At Rest And In Motion

Planning the security architecture for any device begins with the threat model. The threat model describes the types of attacks that the device or application may face and needs to be protected against. It is based on what attackers can do, what level of control they have over the product (i.e., remote or direct access), and how much effort and money they are willing and able to spend on an attack. Based on the threat assessment, security architects can define the right level of security for their device and how it is to be implemented and maintained.

Securing a device’s assets can be simple. Build a very strong vault and destroy the key. Clearly that’s an extreme solution that would prevent further use of the device’s assets. Assets are present on a device for a reason. They will need to be used or accessed by different stakeholders during the lifecycle of the device. It is therefore important, when designing the security architecture for a system to understand which stakeholder is allowed to perform what operations with/on which assets during the various lifecycle stages of the device. Only if the security architecture does not impede the intended use of the device, while still protecting the various assets located in the device, can it be considered successful.

Whether data on the device is considered an asset depends very much on the use case and application environment of the device. When considering data as an asset, it is vital to understand who owns the data and what the impact would be if it is lost or stolen, who needs to be able to use the data, and what an attacker might gain from being able to steal, modify or destroy the data.

There are many reasons that data need be protected. It may have economic value as in digital media or intellectual property. It may be sensitive as in medical records or account information. It may be essential to the operation of the device as in telemetry data from sensors in an autonomous vehicle. It may be the key material itself which if compromised lays open access to all other data on the device. Developing a security architecture which safeguards data assets needs to consider the data “state” whether “at rest,” “in motion,” or “in use.”

Data at rest is data that is stored persistently on some storage medium, with the device or owner of the data not necessarily present. Consider, for instance, data stored on an encrypted SSD, or (encrypted) data located in the cloud. Encryption of data in DRAM can also be considered Data at Rest protection although this is sometimes also referred to as data in use protection as DRAM do not store data persistently.

When a device reaches out to the storage location to request the encrypted data, the attacker may be able to modify the data, replace it with other data or replay data that was updated previously. Hence for a device to protect its assets it needs to ensure the data received or stored is:

• confidential – the attacker cannot learn the plaintext
• unmodified – the attacker cannot modify the plaintext without the device being able to detect the modification (also referred to as data integrity protection)
• fresh – the attacker cannot replace the encrypted data with an older version of the data that might have existed for that storage location previously
• correct – the requested data needs to have been stored to the indicated location previously. An attempt by an attacker to offer data originally located at a different storage location, must be detectable

Data at rest is typically both written and read by a single device, with the device internal operation considered trusted. Because data at rest is expected to be around ‘a long time,’ key material used to protect the data needs to be around for a longer time. Using short-lived ‘session keys’ is difficult as changing key material would require a re-encryption of any data stored under the protection of the key being replaced. Hardware acceleration for off-chip data at rest protection comes in the form of (inline) memory encryption hardware, or Flash/SSD encryption cores. These cores are designed for high throughput/low latency and can be integrated with SoC memory controllers.

Data in motion is data that is being sent from a source to a physically different destination device. An attacker can monitor the data exchanged between two endpoints, modifying, replaying, or removing data in transit. Therefore, parties exchanging data in motion must make sure that the data is:

• confidential – the attacker cannot learn the plaintext
• authentic – (implies integrity protected), ability to verify it originated from the actual communication peer, without an attacker being able to fake or impersonate the identity of the communicating peer(s)
• fresh – data replayed from earlier transmissions must be detected as such

The protection mechanism employed will need to consider the properties of the communication channel, whether it is lossless or not, or whether it allows for out-of-order delivery of data or not, for instance. Data in motion protection typically applies to protection of data transmitted over well-known transport mechanisms, with security protocols tailored specifically to each transport mechanism (e.g., MACsec, IPsec, TLS).

Unlike data at rest protection, data in motion can change to fresh keys on a regular basis. Protection for data in motion is typically instantiated in hardware in the form of ‘security protocol accelerator’ cores. These cores are designed to allow maximum throughput while requiring minimal interaction from the host processor(s) to move the data through the accelerator cores. These cores are normally implemented close to an interface (inline) or close to memory or the memory bus.

Contrary to the previous two scenarios, data in use protection assumes that the device or platform using the data is not trusted/secure. This implies that the data must remain encrypted while it is being used or modified. As a result, this is by far the most complex scenario for which to provide protection. Cryptographic mechanisms like homomorphic encryption and secure multi-party computation are typically used to protect data in use. Due to the complexity and application-specific nature of this class of data protection, it is mostly implemented in software.

With decades of experience in hardware-level security solutions, Rambus can help you design a security architecture that protects your device’s valuable assets including data at rest and in motion. We offer the industry’s broadest selection of security solutions that can be tailored to the needs of nearly every application.

Additional resources:

• Website: Rambus Root of Trust Solutions
• Website: Rambus MACsec Protocol Engines
• Website: Rambus Multi-Protocol Security Engines