Webinar: Ensuring System-level Security based on a Hardware Root of Trust

A root of trust, particularly a hardware root of trust, has become a central principle in well-architected design for security. The idea is that higher layers in the stack, from drivers and OS up to applications and the network, must trust lower layers. What does it help it to build great security into a layer if it can be undermined by an exploit in a lower layer? The lowest level foundations of the stack – hardware and bootloader for example – must guarantee trustworthiness in operation; these become the root of trust. The function of this level is to ensure trust in critical functions – trust in downloaded software/firmware, trust in device authentication and trust in the security of privileged operations such as encryption.

REGISTER HERE for this Webinar on September 6th, 2018 at 11:00 AM PT.

Why is this so important? After all, the easiest place to attack is in application software and the beauty of hardware is that it is difficult/impossible to attack, right? Remember there is software, aka firmware, that runs down in the hardware, driving the bootload process for example. Not as easily accessed as application software, particularly if that code is stored in ROM, but not inaccessible either.

One telling example was demonstrated in Nintendo Switch consoles. This depends on a USB recovery-mode offered by the Nvidia Tegra X1 on which the console is based. Maybe you can already guess the problem. This mode can be tricked into bypassing the normal processes to control external data input. This starts by shorting a pin on a controller connector, forcing the USB recovery mode. Then the USB input fakes out the recovery using a variant on the time-honored buffer-overflow exploit; sending a bad length arg can force the system to request up to 64K bytes per request, overflowing the DMA buffer in the boot ROM, from where it can be copied into the protected application stack. From there it can do anything it wants since it’s already privileged. Yikes.

Of course another problem is that ROM coding is pretty final. Great if you know it can never be hacked but see above for how well that worked out for Nintendo (who apparently have already shipped ~15M consoles with this vulnerability). Perhaps a better approach is to accept that we can never guarantee absolute security and instead allow for carefully-secured updates to firmware to address the latest known threats.

The logical way to do this is through over-the-air (OTA) updates. For many reasons, no-one wants to have to plug in a USB-stick (again, see above) or have to visit a dealer/shop for an update. Security updates should be painless; OTA is the only way we know how to do that today. But how many ways could that be compromised? Man-in-the-middle attacks, or faking OEM credentials? These won’t just spoil a game; they may hack your car and since they’re working with a boot image, again they can take over everything. Fortunately, this kind of attack can be largely averted through strong authentication, using encrypted downloads and signing the code in some manner to detect any code-tampering on each boot.

Adding these kinds of root of trust to a system obviously isn’t just a matter of plugging in an extra block of RTL. There are multiple components: CPU, memory, true random number generator, encryption logic and software at minimum. And these have to be configured together with your system needs, providing plenty of opportunities for you to get it wrong in some subtle way.

Meltown, Spectre and more recently Foreshadow may garner the majority of media attention and panic but all devices need a root of trust. Whether you build your own from scratch, from 3[SUP]rd[/SUP] party IP or you use a pre-built ROT solution, you still have to verify correct operation of the ROT. You might want to watch Tortuga’s webinar on this topic. You can REGISTER HERE.