Cryptography Does Not Equal Security

At Rambus, we often receive RFIs, RFPs and RFQs for security silicon IP cores to be used in our customer’s next semiconductor product. Such requests often contain a long shopping list of required cryptographic algorithms, their modes of operation, their key lengths or strengths and performance and sizing requirements. Depending on the target segment, additional requirements such as robustness, product security and functional safety certificates are part of the requests. Most often these RFIs do not paint the complete picture, as they define cryptographic requirements, but omit security requirements. Even though cryptography is part of a security implementation, having robust cryptographic accelerators in your chip design does not provide security. Cryptography merely provides the toolbox.

We aim to help our customer prospects define and develop products with best-in-class security implementations. After receiving requests from our customers, we enter a dialog that attempts to answer a couple of questions that aim to provide valuable information for building a threat assessment.

The main question should be: what are you, or your customer, protecting and what are you protecting against? More elaborate questions help to clarify what is required: What is the operational environment in which the device needs to function; what type of attacks can be identified; what level of access does a potential attacker have to the device; what possible attack paths can an attacker exploit; what resources like money, time, expertise and specialized equipment would a potential attacker be willing to expend given the value of assets at risk; what would be the damage incurred if an attacker successfully obtained control over the device or its data? Identified attacks can be categorized as logical or physical. Physical attacks like board-level or chip-level attacks open more avenues for exploitation. The threat model will classify board-level attacks, non-invasive chip-level and invasive chip-level attacks, where the latter will certainly leave traces and requires the highest skill levels to execute.

The next set of questions are a result of what assets need to be protected, and where these assets are generated and how they are communicated and/or stored. We tend to categorize assets as: “Data-at-Rest”, “Data-in-Motion” and “Data-in-Use.” Protecting each of these asset types will typically use similar cryptographic techniques that contribute to generating randomness and providing confidentiality, integrity, authenticity and availability mechanisms. The main difference is how and where these cryptographic techniques are built into the SoC architectures.

Data-in-Motion is typically the payload of external off-device communication. This data needs to be protected while being transported over wired or wireless interfaces. Dedicated security protocols such as MACsec for Level 2, IPsec for Level 3 and TLS for Level 4 are widely accepted security mechanisms. Data-in-Motion protection typically requires high throughput, low latency and line-rate security-aware protocol engines that allow for fully offloading the SoC’s compute elements.

Data-in-Use is defined as assets that need to remain within the device boundary at all times but can be stored in off-chip memory like DRAM or FLASH. Protecting Data-in-Use is a vital part of the Confidential Computing Concept, where processing elements need to be able to work on data that is stored in off-chip memory in an encrypted format. Data-in-Use protection typically requires high throughput, very low latency and line-rate encryption engines. Examples of such engines are found in-line in a PCIe or CXL controller path or in-line in a LP(DDR) controller path.

Data-at-Rest can be defined as assets such as keys, identities, and sensitive parameters that have a long lifetime, and need to remain within the chip boundary at all times. Vulnerabilities that lead to leaking, altering or misusing these assets are considered detrimental to the usability and/or availability of the product and service. Data-at-Rest is typically protected by so-called on-chip Root of Trust (RoT), embedded Hardware Security Module (eHSM), Trusted Platform Module (TPM) or Secure Element (SE) cores.

This is where security comes into play. What these Data-at-Rest cores have in common is that they provide and enable system-wide security (against the determined threat model assessment), by providing key management services, such as key generation, key storage, key distribution (to Data-in-Motion and Data-in-Use engines), platform security, such as attestation, life-cycle management, secure boot, firmware and debug management to name a few. Rambus Data-at-Rest solutions come in standard, FIPS 140-2 and FIPS 140-3 CMVP, automotive grade ASIL-B certified eHSM, DPA resistant, and DPA resistant/FIA protected configurations as well as Quantum Safe protections. So, whatever your target application, there’s a security solution to protect against the assessed threats.

Links: 

• Data-at-Rest Security Solutions
• Data-in-Motion Security Solutions
• Data-in-Use Security Solutions