Rambus

At Rambus, we create cutting-edge semiconductor and IP products, spanning memory and interfaces to security, smart sensors and lighting.

Home > Blogs

Scaling Anti-tamper Countermeasures to Meet a Range of Threats

by Leave a Comment

In a new webinar, Scott Best, the director of anti-counterfeiting products and technologies in the Security business at Rambus, discusses how the design of anti-tamper protection needs to recognize and scale with rising threats. Adversaries range from high school hackers to well-funded state actors. As such, Scott details how it’s useful to think about anti-tamper countermeasures as a hierarchy of safeguards that parallel the type, effort and expense of attacks.

The categories of tampering attacks include:

  • Non-invasive: usually passive, the attacker monitors the operation of the chip but does not try to modify its normal operation
  • Semi-invasive: an attacker induces electrical failures within the chip and monitors the resulting effects
  • Fully invasive: often destructive attacks where an attacker bypasses shields, modifies signal connectivity, etc.
  • Reverse engineering: destructive analysis of the chip aimed at obtaining the non-volatile memory (NVM) contents or recovering netlist algorithms

One of the values of thinking about the threat in this hierarchical manner is that it aids in planning the anti-tamper defenses for a chip appropriate to the motivation and funding of the attacker. For instance, if a chip is going into a military platform that could fall into the hands of a state-actor adversary, then it should be hardened against the full range of tampering attacks.

Within this context, Scott details eleven categories of tampering attacks ranging from protocol and software attacks to NVM extraction attacks. For each category, he lays out the resources and skills adversaries employ and the countermeasures to counter these attacks. It’s a great road map for chip makers planning the anti-tamper safeguards they need to incorporate into their designs. You can listen to a replay of the full webinar here.

Watch Anti-Tampering Technologies

Side-Channel Attacks Target Machine Learning (ML) Models

by Leave a Comment

Written by Paul Karazuba for Rambus Press

A team of North Carolina State University researchers recently published a paper that highlights the vulnerability of machine learning (ML) models to side-channel attacks. Specifically, the team used power-based side-channel attacks to extract the secret weights of a Binarized Neural Network (BNN) in a highly-parallelized hardware implementation.

“Physical side-channel leaks in neural networks call for a new line of side-channel analysis research because it opens up a new avenue of designing countermeasures tailored for deep learning inference engines,” the researchers wrote. “On a SAKURA-X FPGA board, [our] experiments show that the first-order DPA attacks on [an] unprotected implementation can succeed with only 200 traces.”

According to Jeremy Hsu of IEE Spectrum, machine learning algorithms that enable smart home devices and smart cars to automatically recognize various types of images or sounds such as words or music are among the artificial intelligence (AI) systems “most vulnerable” to such attacks.

“Such algorithms consist of neural networks designed to run on specialized computer chips embedded directly within smart devices, instead of inside a cloud computing server located in a data center miles away,” he explains. “This physical proximity enables such neural networks to quickly perform computations with minimal delay, but also makes it easy for hackers to reverse-engineer the chip’s inner workings using a method known as differential power analysis (DPA).”

Indeed, edge devices storing AI/ML models and data can be physically disassembled. If unprotected, an attacker can run malicious firmware, intercept network traffic, and employ various side-channel techniques to extract secret keys and steal sensitive information. Both AI/ML inference models, as well as input data and results, are often quite lucrative and should be shielded from criminal elements intent on financial gain. Moreover, the integrity of AI/ML systems must be secured from tampering to prevent malicious attackers from designing cloned or competitive devices, as well as altering training models, input data, and results.

To protect both silicon and data, edge devices running AI/ML algorithms should be built on top of a secure, tamper-proof foundation that ensures confidentiality, integrity, authentication, and availability (up-time). This can be achieved with a programmable security co-processor such as the Rambus CryptoManager Root of Trust (CMRT) which uses a combination of hardware and software countermeasures to thwart side-channel attacks. For AI/ML edge devices built without the Rambus CMRT, we recommend that system designers utilize a Test Vector Leakage Assessment (TVLA) platform like Rambus’ DPA Workstation Analysis Platform (DPAWS) to help detect side-channel leakage and implement appropriate countermeasures.

DPAWS includes all the hardware, software, and training material needed to evaluate and certify secure AI/ML edge devices. It offers a Windows-based, intuitive user interface that enables system designers to efficiently perform side-channel analysis on AI/ML edge devices to identify potential security flaws. Collected signals are examined using simple power and electromagnetic analysis (SPA/SEMA) or more powerful differential power and electromagnetic analysis (DPA/DEMA) to identify exposure of secret keys.

The recently released DPAWS 9.2 offers several new notable features, including sample leakage history plotting. This capability allows system designers to detect and better understand side-channel leakage. More specifically, confirming the increase of electronic leakage across time can help improve countermeasure design, detect additional locations vulnerable to potential leakage, and provide a baseline for comparing non-leaking locations.

DPAWS 9.2 also offers system designers access to bi-variate leakage detection; a form of higher-order side-channel analysis to which more robust designs may need to be resistant. Essentially, bi-variate analysis combines different points from within the analysis range to detect leakage. This methodology may reveal leaks in implementations that are univariate or first-order secure. Previously, separate tools were used to combine pairs of data points within the analysis window or perform bivariate analysis from the command line.

In summary, AI/ML edge devices, like all physical electronic systems, routinely leak information about the internal process of computing via fluctuating levels of power consumption and electro-magnetic emissions. To protect both silicon and data, edge devices running AI/ML algorithms should be built on top of a secure, tamper-proof foundation. As well, AI/ML edge devices should be carefully evaluated with a testing platform like Rambus DPAWS to validate the effectiveness of countermeasures in reducing sensitive side-channel leakage.

Rambus CryptoManager Root of Trust Cores Certified ASIL-B/D Ready for Enhanced Security in Automotive Applications

by Leave a Comment

Highlights:

  • Safeguards automotive Vehicle-to-Everything (V2X) communications, Advanced Driver Assistance Systems (ADAS), Electronic Control Unit (ECU) platform management, and infotainment applications
  • Provides ISO 26262 Automotive Safety Integrity Level (ASIL)-B and ASIL-D ready security solutions
  • Offers comprehensive suite of security features including secure boot, secure firmware updates, authentication, device personalization, secure key and data storage, and secure provisioning

Rambus is pleased to announce our CryptoManager Root of Trust RT-640 and RT-645 cores have been certified ASIL-B and ASIL-D ready, respectively. These automotive-grade secure co-processor IP safeguards SoCs in V2X communications, ADAS, ECU platform management, infotainment and other critical vehicle systems.

CryptoManager Root of Trust diagram

“As vehicles become increasingly connected, securing communications and the numerous electronic components that are responsible for critical vehicle systems is a necessity,” said Robyn Westervelt, research director, security and trust for IDC. “ASIL certification of security features such as authentication, attestation cryptographic accelerators are imperative to meet the evolving security needs in the automotive market.”

Easily integrated into chips serving the automotive market, the CryptoManager Root of Trust RT-640 and RT-645 provide a broad suite of security features. These include secure boot, secure firmware updates, secure debug, authentication, attestation, device personalization, key and data provisioning, secure feature and configuration management, cryptographic acceleration, and secure key and data storage. In addition, the RT-640 and RT-645 cores provide design integrity and reliability.

“The increasing sophistication and complexity of automotive electronic systems brings a greater attack surface. This requires robust security solutions to safeguard these vital systems from a growing range of cyber threats,” said Neeraj Paliwal, vice president and general manager of Rambus Security. “With our ASIL-ready CryptoManager secure co-processors, automotive chip makers can be assured of functional safety and have access to a rich set of security features that can be quickly implemented to accelerate the certification of their SoCs.”

With features tailored for the automotive market, the RT-640 and RT-645 can operate as E-safety Vehicle Intrusion Protected Applications (EVITA) full or medium Hardware Security Modules (HSM). Certification for ASIL-B and ASIL-D readiness and “functional safety” was provided by SGS-TÜV Saar GmbH. Copies of the certifications are available on Rambus.com.

Availability
The CryptoManager Root of Trust RT-640 and RT-645 are available for licensing. In addition to a robust Root of Trust framework with functional safety at ASIL-B and -D levels, the RT-640 and RT-645 come with a Secure Application SDK that allows rapid Secure Application development and deployment. Rambus will support its licensees by providing extensive documentation including the ISO26262 FMEDA (Failure Modes Effects and Diagnostics Analysis) sheets and Safety manuals, reducing time to ISO26262 certification and thus time to market.

Additional Information
For additional details about the CryptoManager Root of Trust RT-640 and RT-645, and copies of the ASIL-B/D certifications, please go to https://www.rambus.com/security/root-of-trust/cryptomanager-root-of-trust/rt640/ or visit https://www.rambus.com/security/root-of-trust/cryptomanager-root-of-trust/rt645/.

MACsec Explained: From A to Z

by Leave a Comment

From A  to Z, learn everything you need to know about Media Access Control Security (also known as MACsec).

For end-to-end security of data, it needs to be secured when at rest (processed or stored in a device) and when in motion (communicated between connected devices). For data at rest, a hardware root of trust anchored in silicon provides the foundation upon which all data security is built. Similarly, for data in motion, security anchored in hardware at the foundational communication layer provides that basis of trust, and that’s where MACsec enters the picture.

In this article:

What is MACsec?

Media Access Control security provides security of data between Ethernet-connected devices.

The MACsec protocol is defined by IEEE standard 802.1AE. Originally, Media Access Control Security secured the link between two physically connected devices, but in its current form can secure data communications between two devices regardless of the number of intervening devices or networks.

When MACsec is enabled, a bi-directional secure link is established after an exchange and verification of security keys between the two connected devices. A combination of data integrity checks and encryption is used to safeguard the transmitted data.

The sending device appends a header and tail to all Ethernet frames to be sent, and encrypts the data payload within the frame. The receiving device checks the header and tail for integrity. If the check fails, the traffic is dropped. On a successful check, the frame is decrypted.

Don’t have time to read the whole article right now?
 No worries. Let us send you a copy of a related white paper so you can read it when it’s convenient for you. Access it here »

Foundation for Network Security

One of the most compelling cases for MACsec is that it provides Layer 2 (OSI data link layer) security allowing it to safeguard network communications against a range of attacks including denial of service, intrusion, man-in-the-middle and eavesdropping.

These attacks exploit Layer 2 vulnerabilities and often cannot be detected or prevented by higher layer security protocols. In this way, MACsec provides the foundational security on which a network security architecture can be built.

Seven-layer Open systems Interconnection (OSI) Model - MACsec
Seven-layer Open systems Interconnection (OSI) Model – MACsec

The OSI model partitions a communication system into seven layers. Each of these abstraction layers serves the layer above and is served by the layer below.

From a security standpoint, each layer can secure its activities and those above it, but depends on the security of the layers below. Since Layer 2 is where communication begins, security here establishes the foundation for security for the entire network stack.

Security at Full Speed

Another compelling advantage of MACsec is that it operates at line rate. Speed is critical as networks and data centers need all the bandwidth they can get to handle the deluge of data traffic growing at an exponential pace. Line rate operation means networks can get the robust Layer 2 security of Media Access Control Security with no sacrifice in performance.

Features and Benefits

Going deeper, here is what MACsec offers:

  • Device-to-device security – MACsec establishes secure transfer of data between two devices regardless of the intervening devices or network. This has allowed MACsec to be used in LANs, MANs and WANs to secure data communication.
  • Connectionless data integrity – Unauthorized changes to data cannot be made without being detected. Each MAC frame carries a separate integrity verification code, hence the term connectionless.
  • Data origin authenticity – A received MAC frame is guaranteed to have been sent by the authenticated device.
  • Confidentiality – The data payload of each MAC frame is encrypted to prevent it from being eavesdropped by unauthorized parties.
  • Replay protection – MAC frames copied from the network by an attacker cannot be resent into the network without being detected. In special configurations, with the possibility of frame reordering within a network, limited replay can be permitted.
  • Bounded receive delay – MAC frames cannot be intercepted by a man-in-the-middle attack and delayed by more than a few seconds without being detected

Where is MACsec Used?

Ethernet has become the ubiquitous communication solution from the desktop to the carrier network.

A growing torrent of network traffic has driven rapid advancements in the performance of Ethernet with 800G Ethernet representing the latest milestone in the evolution of the standard.

With MACsec as the foundational security technology for safeguarding data in motion across Ethernet networks, the use cases are many:

  • WAN/MAN routers
  • Data center routers and switches
  • Server, storage and top-of-rack switches
  • LAN switches
  • Secure endpoints such as security cameras and industrial robots

Here’s a detailed example:

WAN MACsec security for Ethernet over MPLS (EoMPLS)
WAN MACsec security for Ethernet over MPLS (EoMPLS)

Imagine a global enterprise with multiple enterprise networks, here we show three (the enterprise network clouds).

At the edge of each enterprise network is an edge router (CEn). Each CE connects to a service provider edge router (PEn). The MPLS (Multi-protocol Label Switching used for speed and to guarantee QoS levels) service provider network, which may span many routers, optical transport networks, etc., links the PEs.

MACsec can be used to securely connect two CEs.

The service provider network passes the traffic using “in the clear” routing information in the header. But the key authentication, integrity checks and encryption of MACsec are still enforced just as if CE1 and CE2 were physically connected. And this scales to any number of devices, so we could link to tens or hundreds of other MAC-sec enabled CEs.

Now, imagine there is an industrial robot at the far end of Enterprise Network 1 (CE1’s cloud), and there is a server running an AI inference application in Enterprise Network 2 (CE2’s cloud).

We could securely connect these two devices to switches using MACsec, and those switches to the CEs providing end-to-end security with Media Access Control Security.

Device-level Use Cases

Let’s turn now to specific device-level use cases for MACsec.

1. Use Case: Securing 800G Multi-Port PHY

Use Case: Securing 800G Multi-Port PHY - MACsec

In our first use case, we want to provide communication security for an 800G Multi-port PHY.

We need line-rate encryption of the output which could be one 800G channel or 8 parallel 100G channels with aggregate bandwidth of 800 Gbps. The solution is provided by our multi-port MACsec engine consisting of MACsec classifier and MACsec transformation cores that are incorporated in the PHY transceiver chip. The system would work like this for outbound (transmit) data:

  1. Time-sliced (TDM) parallel data streams are received by the PHY transceiver chip
  2. Packet headers are classified
  3. Data rate is controlled based on the classification and timestamping performed per the precision time protocol (PTP)
  4. Security implemented (transform packet) with option of constant latency or predictable latency
  5. Encrypted and authenticated data stream transmitted at line rate under all conditions

In the 800G PHY use case, we assumed all traffic would be MACsec secured. What about the use case for a switch where we have differing security needs depending on the port. We’ll take a look at that use case next.

2. Use Case: Securing Terabit SwitchUse Case: Securing Terabit Switch - MACsec

In our terabit switch, a subset of traffic requires MACsec security.

The solution is a multi-port MACsec engine implemented in the switch ASIC. The MACsec engine is capable of servicing a flexible number of ports with aggregate throughput of up to 800 Gbps. Here’s how that would work:

  1. TDM data is received
  2. Packet headers classified for all ports that require security
    • Allow deep packet inspection for MACsec EoMPLS
    • Support various proprietary schemas if required
    • Provide optional support of switch classifier inputs
  3. Add security (transform packet) with encryption of the data payload
  4. Stream out encrypted and authenticated data at line rate under all conditions to all protected ports

800G MACsec Protocol Engine

For networking SoC and ASIC designers, Rambus offers an 800G Multi-Channel MACsec Protocol Engine comprised of Transform and Classifier cores. It can support up to 64 channels with aggregate bandwidth of 800 Gbps providing tremendous design flexibility. It is supported with a widely-adopted MACsec Tookit and a Driver Development Kit.

800G Multi-Channel MACsec Protocol Engine

800G Multi-Channel MACsec Protocol Engine

With the Rambus 800G MACsec Protocol Engine, designers get the benefits of robust Layer 2 security with line-rate performance. It can be easily integrated into networking chips and is backed with supports and services from the world-class Media Access Control Security experts at Rambus.

Keep on reading: Rambus Launches 800G MACsec Multi-Channel Engine

High-Performance Memory for AI/ML and HPC: Part 2

by Leave a Comment

In part one of this two-part series, Semiconductor Engineering Editor in Chief Ed Sperling and Rambus Sr. Director of Product Management Frank Ferro took a closer look at the various types of memory that system designers are using to support artificial intelligence (AI), machine learning (ML), and high-performance computing (HPC) applications. In this blog post, Sperling and Ferro explore how bandwidth-hungry AI/ML and HPC applications are driving new chip, system, and memory architectures.

“We’ve seen that HBM2 and HBM2E are frequently used in applications that demand high performance computing. These include AI/ML training in particular – along with certain networking applications that have locked in on HBM as a solution of choice,” Ferro confirms. “What is shipping out in the market today are solutions based on HBM2. HBM2 gives you a quite a bit of bandwidth. Although 2Gbps per pin isn’t very fast from a per pin standpoint, you’ve got 1024‑bit wide access, which gives you a total of 256 gigabytes of bandwidth.”

Memory Solutions for AI and HPC
Comparison chart of Memory Solutions for AI and HPC

As Ferro notes, the 256Gbps represents the throughput that is delivered by HBM2.

“If you look at some of the applications in AI/ML training, if these are where you string multiple HBM stacks together, this paradigm will give you the kind of performance you are looking for,” he explains. “For example, four stacks of HBM2 will get you up to a terabyte of data throughput.”

Another advantage of HBM2 and HBM2E, says Ferro, is that the memory comprises a small portion of the total system area – with relatively low levels of power consumption.

“With HBM2 and HBM2E, you’re only taking up a small area on the system, along with very low levels of power consumption,” he elaborates. “In short, high bandwidth memory offers a compact solution that delivers very high bandwidth, low power, optimal density, high performance and a small footprint.”

Moreover, says Ferro, HBM2 or HBM2E memories can be linked together in HPC systems.

“How one daisy chains everything together, how the data is moved to the CPU, that is the secret sauce for companies architecting their respective systems,” he states. “Perhaps they have a CPU with its own HBM, or multiple CPUs feeding off a single HBM. These are all potential system designs.”

Commenting on the future beyond HBM2E, Ferro notes that the need for more bandwidth and higher memory densities is only increasing.

“HBM2E uses wide I/O and TSV technologies to support densities up to 24 GB per device at speeds up to 307 GB/s. This bandwidth is delivered across a 1024-bit wide device interface, which is divided into 8 independent channels on each DRAM stack,” he explains. “HBM2E can support 2-high, 4-high, 8-high, and 12-high TSV stacks of DRAM at full bandwidth to allow systems flexibility on capacity requirements from 1 GB – 24 GB per stack.”

As well, says Ferro, HBM2E extends the per pin bandwidth to 3.2 Gbps, adds a new footprint option to accommodate the 16 Gb-layer and 12-high configurations for higher density components, and updates the MISR polynomial options for these new configurations.

HBM2E PHY

Nevertheless, Ferro emphasizes that AI/ML data sets continue to increase at almost exponential rates.

“Even with the improvements offered by HBM2E, system designers are having difficulty keeping up with the massive data sets for AI/ML training. HBM3 is anticipated to deliver much higher bandwidth and densities.”

Commenting on SoC size and chiplets, Ferro points out that costs associated with increasing SoC size has become a significant consideration for the industry.

“We have to look at ways to reduce those costs. We have seen a certain level of disaggregation which has given rise to chiplet technology. There are many reasons aside from a silicon reticle perspective to leverage chiplets,” he elaborates. “One example could be high speed IP that was designed in an earlier node. By using chiplets, a company can take advantage of all that work that was previously developed.”

More specifically, a CPU can be fabbed in the most advanced node, with I/Os in an older node.

“You can also have chips that are I/O bound and then you don’t want to waste silicon. There are a lot of different applications for chiplets going forward. However, system designers will have to determine how a chiplet communicates with the SoC,” he says. “If you are talking to a DRAM – and you have the same HBM PHY – you will have with a monolithic design. But then, as you go back to the CPU, there are different SerDes technologies that are being explored: high speed, very high-speed, and short reach.”

Ferro concludes by noting that high bandwidth memory presents a number of design challenges, as it combines 2.5D and 3D technologies.

“There are a lot of advantages associated with HBM: low power, low area and high bandwidth. However, you must deal with fitting these 2.5D structures in a small area. In addition, maintaining signal integrity is a challenge with traces running at high speeds, as is thermal dissipation from the heat generated by the SoC and the memory itself. Last, but certainly not least, the HBM interposer is a fairly large piece of silicon that presents warping concerns. Nevertheless, even with these design challenges, the performance benefits of HBM are well worth the extra design effort,” he adds.

High-Performance Memory for AI/ML and HPC: Part 1

by Leave a Comment

Semiconductor Engineering Editor in Chief Ed Sperling recently spoke with Rambus Sr. Director of Product Management Frank Ferro about designing high-performance memory subsystems for artificial intelligence (AI), machine learning (ML), and high-performance computing (HPC) applications.

As Ferro notes, there is plenty of compute (CPU) power available today to support the above-mentioned markets.

“[However], the advances in computing are now outstripping the ability to feed those [compute] engines with memory. [So, we are often asked (by customers) how to solve this memory bottleneck]– how do we keep all these compute engines fed for applications like HPC and AI/ML?”

More specifically, says Ferro, the above-mentioned bottleneck is in the memory subsystem, with compute speeds routinely outstripping the memory.

“In the past, system designers had limited choices for their memory subsystem. Essentially, DDR4 was the only choice for a time. [Since DDR4 could only hit a max speed of 3.2Gbps, it gave rise to the need for new solutions],” he explains. “High bandwidth memory (HBM), which was one of the first to emerge, is based on DDR technology. It runs at about 3.2Gbps today and gives you the same DDR technology – only with a very wide interface.”

Another memory type based on DDR, says Ferro, is GDDR6 which was originally created for the graphics market some 20 years ago. GDDR has undergone several major evolutions, with the latest iteration running at 16Gbps. In addition, LPDDR5, which has broken out of the mobile market, is running at speeds of 6.4 Gbit/s/pin.

“Designers can now look at all these different technologies to architect the memory subsystem. Depending on the application, any of these – HBM2E, GDDR6, and LPDDR – could potentially be a good solution to keep those CPUs fed with data.”

Selecting the most appropriate memory type, continues Ferro, depends on multiple tradeoffs that are illustrated in the image below.

Tradeoffs for High Performance Computing

“There are a number of applications that require HPC capabilities in the cloud. For example, HPC is often a key requirement for complex applications such as genome sequencing and graphics rendering,” Ferro states. “The trade-off for memory to support HPC applications is paying more in terms of power consumption, as well as dollars to access the highest levels of performance computing.”

For AI/ML, says Ferro, there are several market segments, including training with large, complex data sets that can take weeks to process and refine.

“Nevertheless, the tradeoffs for AI/ML memory can be more practical, as these applications typically require one to two terabytes of bandwidth. Power consumption is one of the biggest expenses in the data center, so a more balanced approach makes sense,” he explains. “Certainly, the more processing power you can access in the data center the better. At the same time, you must be conscious of the power and cost elements. Even within the data center you see several market segments where accelerator cards are limited by power. You have some cards that are down as low as 75 watts, but you’ll also have cards that are up to 250 to 300 watts – so you can draw on additional power for those highest performance applications.”

Ferro also notes that although networking isn’t typically associated with high bandwidth computing, the increase of in-line processing means that companies can no longer rely completely on the cloud.

“As you go through the edge of the network all the way up through the cloud, you’re going to want to do processing in-line. So that is why we are now seeing networking applications that require very high bandwidth,” he adds.

Upcoming Webinar: AI Requires Tailored DRAM Solutions

Register Today