Tortuga Logic Security Verification of Rambus CMRT

TORTUGA LOGIC | ENABLING FULL-CHIP SECURITY VERIFICATION WITH HARDWARE EMULATION
Security Verification of Rambus’

CryptoManager Root of Trust
TORTUGA LOGIC | SECURITY VERIFICATION OF THE CRYPTOMANAGER ROOT OF TRUST
Summary
The confidentiality and integrity of cryptographic key material is critical to maintaining system
security. Hardware roots of trust, such as the CryptoManager Root of Trust (CMRT) from
Rambus are designed to securely generate, store, and use cryptographic keys. Tortuga Logic
has independently verified the policies surrounding access to keys stored within registers in
the CMRT using its pre-silicon security verification platform, Radix™.
Confidentiality and integrity properties require tracking how information contained in design
signal flows between design logic blocks. Tortuga Logic’s Radix provides 1) a mechanism for
specifying security requirements as information flow rules in a concise and comprehensive
manner and 2) the ability to verify these rules during simulation and emulation to leverage
existing high-quality test stimulus developed for functional verification.
Three (3) security rules related to the management of the most critical cryptographic key assets
in the CRMT were developed collaboratively by Tortuga Logic and the security and verification
teams at Rambus. The 3 security rules easily integrate into the existing verification
environment and were successfully analyzed using an existing set of regression tests provided
by Rambus.
No security vulnerabilities were found during analysis of these 3 security rules.
Security Requirements
The CMRT assets analyzed are all cryptographic keys stored in registers within the Key
Derivation Core (KDC) and AES Core. The relevant blocks are outlined in red in Figure 1.
Keys inside the CMRT are governed by hardware-enforced policies dictating how keys can be
accessed and used. For example, a subset of keys can be manipulated by software running
on the CMRT Secure CPU, while others should always remain software-hidden.
The 3 keys analyzed are used to protect sensitive customer data. The CMRT employs key
derivation algorithms (implemented in hardware by the Key Derivation Function Core) to
generate unique key material which is never externally visible, even to the software requesting
that cryptographic operations are performed. These internal keys, which are only permitted to
reside in the KDC and other cryptographic cores such as the AES Engine, are critical to protect
and are the focus of Tortuga Logic’s security verification effort.
2
FIGURE 1: CMRT BLOCK DIAGRAM WITH CORES RELEVANT TO THE SECURITY RULES
VERIFIED OUTLINED USING RED BOXES
Design Assets Analyzed:
• KREG: Key register inside the Key Derivation Core (KDC)

• KDC_KEY: Key register inside the KDC
• AES_KEY: Key register inside the AES Engine
Security Requirements Verified:
1. KREG information should not leak to software*.

2. KDC_KEY information should not flow to software unless the destination for KDC_KEY
is software as specified by a control register within the KDC.
3. The Key in the AES block should not leak through the encrypted output of the block
except as fully encrypted ciphertext.
*In the context of the CMRT hardware architecture, software includes the inputs to the Secure
CPU and the SRAM block storing Security Processor code and data.
Tortuga Logic has verified the confidentiality of these keys is maintained by the CMRT
hardware architecture.
3
Verification Results
The security requirements outlined in the previous section were captured as security rules
using Tortuga Logic’s Sentinel™ security specification language. The rules were verified using
Tortuga Logic’s Radix in combination with an existing functional regression test suite from
Rambus which exercises the KDC, AES, and OTP blocks. No new tests were required to
perform security verification using Radix. A high-level description of the security rules along
with the verification results is given in the chart below.
Rule No. Security Rule Rule Pass/Fail

(1) KREG =/=> Software PASS
(2) KDC_KEY =/=> Software unless destination Software PASS
(3) AES_KEY =/=> AES Outputs unless encryption done PASS
Tortuga Logic tools provide a simple syntax for expressing security rules. A Sentinel rule
always consists of a source, the “no-flow” operator, =/=>, and a destination. The source and
destination can be a single signal, or a set consisting of multiple signals. The rule will fail if
information from any signal in the source signal set flows to any signal in the destination signal
set. All 3 security rules passed, meaning no illegal information flows were observed during the
regression tests, which heavily exercised functionality surrounding the usage of these keys.
Radix generates a security model design (SMD) based on the original RTL (CMRT design files)
and the security objectives captured by the security rules. This custom security model contains
patented technology to detect violations of these rules during RTL simulation and emulation
meaning the existing functional verification infrastructure can be leveraged for security
verification.
A comprehensive security verification methodology should validate that the security

architecture is trusted for the IP, subsystems and the full SoC integration of hardware and
software. At Tortuga Logic, we have validated that the Rambus CMRT hardware root of trust
provides a security anchor for the design and implementation of any system. For complete
security assurance, it is required that any customization made to the CMRT design or
additional components incorporated into the system-level security architecture also do not
violate the security intent of your system. With the Radix solution from Tortuga Logic, Rambus
customers utilizing the CMRT can identify and fix potential system level vulnerabilities in their
design during pre-silicon verification. Radix does not require development of custom
verification infrastructure thus the effort to deploy Radix is very low. These existing rules and
additional system rules can be easily verified in a system-level context that includes all
hardware blocks and the software that configures the security infrastructure. The
software/firmware configuration of secure assets is a common source of security
vulnerabilities. Radix is uniquely able to identify vulnerabilities due to errors in the hardware
implementation and the software configuration.
4
About Tortuga Logic

Tortuga Logic is a cybersecurity company that provides industry-leading solutions to address
security vulnerabilities overlooked in today's systems. Tortuga Logic's innovative hardware
security verification platforms, Radix-S™ and Radix-M™, enables design teams to identify and
prevent system-wide exploits arising around a Hardware Root of Trust that are otherwise
undetectable using current methods of security review. To learn more,
visit www.tortugalogic.com or contact info@tortugalogic.com.

Tortuga Logic Security Verification of Rambus CMRT

Uploaded by

Copyright:

Available Formats

Tortuga Logic Security Verification of Rambus CMRT

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tortuga Logic Security Verification of Rambus CMRT

Uploaded by

Copyright:

Available Formats

TORTUGA LOGIC | ENABLING FULL-CHIP SECURITY VERIFICATION WITH HARDWARE EMULATION

Security Verification of Rambus’

No security vulnerabilities were found during analysis of these 3 security rules.

Design Assets Analyzed:

• KREG: Key register inside the Key Derivation Core (KDC)

Security Requirements Verified:

1. KREG information should not leak to software*.

Rule No. Security Rule Rule Pass/Fail

A comprehensive security verification methodology should validate that the security

About Tortuga Logic

You might also like