“The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true.” ― James Branch Cabell

Given the magnificent complexity of modern microprocessors, it’s inevitable that they’ll have bugs and security holes. It might even be physically impossible to create a bug-free CPU, but that’s a mathematics/physics/EDA/statistics/philosophical conundrum that’s above my paygrade. For now, we finds the bugs and we works around ’em. 

But what if… 

What if a processor could be designed with security in mind, first and foremost? Would that be possible, and if so, would it be useful? Or, would a maximum-security CPU be uselessly slow, complicated, and unwieldy? 

It’s a thorny problem, and one not easily solved – or even answered. After all, it’s not as though today’s CPU designers are slacking off and deliberately allowing bugs to creep in. It just happens, and it might not be possible to do any better. 

Rambus thinks it has one good solution, however, and that’s to make a security-first processor that sits alongside your normal one. It’s a coprocessor to handle the usual cryptography tasks, but one that also is designed and hardened against weird side-channel attacks like clock glitching, undervoltage dips, spooky RF emissions, physical tampering, and the like. It’s like having a bodyguard to stand over your main processor. 

The company calls it CryptoManager Root of Trust, and it comes in seven different levels of complexity, from a quick-and-dirty IoT version to the fiendishly complex military edition. Much of its block diagram is familiar: RISC-V processor core, AES and SHA accelerators, hardware root of trust, ECC hardware, and so on. These are fine features, but they’re often included in high-end CPUs or available elsewhere from other hardware vendors. 

Where Rambus thinks CryptoManager stands out is in its resistance to outright attacks. Most versions include a “Canary Core monitor” that acts as the proverbial canary in the coal mine, sniffing out nefarious activity intended to circumvent the other security measures. Specifically, Rambus says it can detect momentary under-voltage attacks like Plundervolt and alert the main processor. Deliberate clock glitching also triggers an alarm. 

The key to securing the secure processor is that it isn’t designed to do much else. Yes, okay, it’s programmable and can run useful code (which Rambus provides), but that’s not really its purpose. Unlike, say, your Cortex-A57, Ryzen 3970X, or Core i7-10510, CryptoManager isn’t designed for performance first and security (hopefully) a close second. Once you give up on the idea of making a fast and efficient processor that’s also secure, you can start designing the processor differently. 

That includes circuit-design tricks that Rambus is hesitant to disclose. CryptoManager is supplied as licensed IP, not a physical chip, so customers implement it on the same silicon die as the processor(s) and other hardware they’re protecting. It would be hard to physically attack or electrically manipulate the main processor without also triggering CryptoManager. 

For code that runs internally on CryptoManager, the device has multiple levels of privilege, combining the concepts of task ID and privilege level. Most CPUs today have “binary” privilege. That is, code is either privileged (supervisor) or it’s not (user). Privileged code can do things that unprivileged code can’t, such as access internal CPU registers, execute certain instructions, or update restricted areas of memory. The x86 family has four privilege levels arranged in conceptual “rings,” but the concept is the same. 

In each case, the privilege is applied equally across all programs and tasks, which means Privileged Program A can generally do anything that Privileged Program B can do. That’s not always a good thing, and that egalitarianism has been the root cause of a few security bugs. Sometimes, you want one, and only one, program to be able to update the system’s memory maps or handle cryptography keys. Clearly, the operating system and/or BIOS needs to be able to set these things up at boot time, but why should every piece of privileged code have the same potential ability?

CryptoManager expands those levels of security with unique privileges for each program. Instead of a broad-brush approach, it’s more fine-grained, doling out a different set of rights and privileges for each individual task. Even if Program A is deemed safe, it’s assigned its own unique safety level, and it’s incapable of accessing other secure applications running within CryptoManager. That helps avoid tricky privilege-elevation bugs when one privileged program asks another equally privileged one to do something naughty on its behalf. 

Of course, the “running within CryptoManager” part is important. It’s great at securing itself but it can’t magically make your iPhone or Windows 10 system bulletproof. Rambus’s security coprocessor is an add-on, not a replacement, for the main processor(s). Treat it like a useful peripheral and it’ll do its job.