Cybersecurity Designed For the Edge

This blog post was originally published at Ambarella’s website. It is reprinted here with the permission of Ambarella.

Onboard security is mandatory for today’s embedded processors.

Our vision SoCs perform critical tasks in automotive safety, video security, and other AI camera applications where environmental perception—seeing and interpreting the world—plays a pivotal role. From front ADAS devices to airport security cameras, our processors are central to a number of applications in which lives are often, quite literally, at stake. A compromised chip is potentially catastrophic.

For these and other reasons, we at Ambarella approach chip design with a focus on reliability, robustness, and redundancy. Our compliance with ISO 26262 standards is one example of our commitment to dependable hardware performance, but there is another less-talked-about example as well—cybersecurity. This term refers to the specific security protocols we implement on-chip in order to make our processors more resistant to hacking. While cybersecurity is a well-established concept, not all cybersecurity features are the same, so it is worth taking a moment to share Ambarella’s approach.

Ambarella’s embedded vision processors are used in a variety of safety-critical applications in automotive, security, and more.

Vision processors like ours are, by definition, embedded inside a larger system, but this doesn’t mean they aren’t attractive targets for bad actors—especially when the application is safety-critical, as ours tend to be. Moreover, when the embedded processor is mass-produced and deployed in the millions of units, its appeal as a target increases even further. When one considers that our SoCs are typically expected to operate for decades in the field, inside hundreds of millions of platforms, it becomes evident that the security features we implement today must be designed to protect our devices for years to come.

The stakes are extraordinarily high. For this reason, Ambarella focuses on the implementation of multiple layers of protection at the hardware and SDK level, going far beyond simple encryption and authentication. A one-size-fits-all approach isn’t sufficient in our case—given the resource limitations inherent to embedded platforms, we can’t, for example, rely on cybersecurity solutions designed for the cloud. Therefore, instead of relying on protections designed for other platforms, we focus on incorporating specific security protocols for embedded devices in the earliest stages of our development process.

Fortunately, our long history as a chip supplier for the professional security camera industry has provided us with significant experience in developing system-security solutions alongside our customers. And now we’re able to transform this expertise and experience into robust on-chip security solutions.

“Instead of relying on protections designed for other platforms, we focus on incorporating specific cybersecurity protocols for embedded devices in the earliest stages of our development process.”

Until recently, embedded security features were centered around ancillary components such as secure elements (SEs), trusted platform modules (TPMs), secure NAND, and eMMC, to name a few. While these solutions address many of the concerns inherent to embedded platforms, they aren’t comprehensive—in particular, hardware root-of-trust and trusted execution environment aren’t addressed. To remedy this, we designed our line of computer vision SoCs with a slew of security feature options specifically for embedded use cases. Some are available directly via the SDK, while others are based on lower-level functions that allow product manufacturers to implement their own customized security protocols in a straightforward manner.

Below are some key characteristics of our cybersecurity approach.

Note that this listing reflects our current feature lineup at publication—however, as requirements and technologies change over time, our methodologies will continue to evolve.

Mask-programmed boot ROM acts as a hardware root-of-trust. Initial stages of the boot process are verified via on-chip memory with keys stored in the on-chip OTP area. Signature verification uses 2048-bit keys and SHA-256.
Later in the boot process, we load a trusted OS (OP-TEE) to set up a trusted execution environment. This provides a secure environment in which to perform sensitive operations such as key generation, password verification, and other authentication features.
Our vision SoCs also include:
- A True Random Number Generator (TRNG) that can be used for key generation and other related functions
- An OTP region that can store multiple RSA 2048-bit keys for signature validation with the option to invalidate compromised keys—this region also includes a user-configurable region to store other information a customer may require
- Other high-level features: (numbers 7-10 are built on top of numbers 1-6)
  1. Secure Boot
  2. Device Unique ID
  3. Device Unique Encryption Key
  4. Secure Random
  5. JTAG/Debug Enable
  6. Arm® TrustZone®
  7. Data-at-Rest Encryption
  8. Secure Wipe
  9. Rollback Prevention
  10. Secure Credential Provisioning

Availability of features either via the SDK directly, or via lower-level functions that allow product manufacturers to implement their own customized security protocols

Note: features 7-10 are built on top of features 1-6.