Architecting Hardware Protection For Data At Rest, In Motion, And In Use

Planning the security architecture for any device begins with the security 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 money and effort 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, modified, 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 to 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.

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’s 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.

Data in motion (also known as data in transit) 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) – the 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 (often called session 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 line rate throughput while requiring minimal interaction from the host processor(s) to move the data through the accelerator cores. These cores are normally implemented inline, close to an interface.

Contrary to the previous two scenarios, data in use is typically stored on the device, but off chip, most often inside a device in its DRAM or flash memory. Data in use protection assumes that the device or platform using the data cannot be trusted or is not 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.

A prime example of data in use is the data moving back and forth between a CPU and DRAM. An adversary could potentially probe the connections between the processor and the DRAM memory module and intercept the plaintext data being written and read. Protecting data in use can be achieved by encrypting it when it is written to DRAM and decrypting it when read. This is complicated however by the need to be aware of and maintain memory coherency in the multi-tiered memory caching architecture of the processor. In addition, the inline memory encryption engine must be extremely fast (low latency) to maintain CPU performance.

Rambus has three decades of security expertise and a broad portfolio of hardware security IP solutions designed to support protect your device’s valuable data at rest, in motion, and in use. We offer a broad selection of security solutions that can be tailored to the needs of nearly every application, including data center, automotive, government, and IoT use cases.

Additional resources:

• Data at Rest: Rambus Root of Trust Solutions
• Data in Motion: Rambus Security Protocol Engines
• Data in Use: Rambus Inline Cipher Engines