Whitebox Attacks… on Hardware?

In our very first Cloakable blog post, we discussed why whitebox cryptography is so important when developing software that needs to keep data and keys secure.  Specifically, we discussed how software is an open book, with the ability to view and alter the internals of an implementation while running.  We call this the whitebox attack context, and it is a fact of life for software protection.  However, we also teased the topic of this post with the following statement – “Put simply, software is a white box. This is not contrasting it with hardware, which is increasingly open to knowledgeable souls as well.”

There’s long been a presumptive hierarchy when it comes to attacks.  Software is most vulnerable, smart cards are next, and hardware is the hardest to attack.  Put another way, software is (correctly) modelled as a whitebox (fully observable, can be modified while running), smart cards are modelled as a greybox (can be indirectly probed without physical tampering), and hardware is modelled as a blackbox (I/Os only).

(A subtle but necessary clarification here – “blackbox” doesn’t mean we don’t know what the system is doing, it means we don’t have access to the internals of that system while its doing it.  This is Kerchoff’s principle, and however much we try to avoid it in practice, it’s good to keep it in mind.)

The assumption that hardware == blackbox is an oversimplification in two very important ways:

  • It doesn’t have enough context.
  • It doesn’t take time into account.

Let’s talk about context first.  Basically, what this comes down to is: how powerful is your attacker?  The more sophistication (read: money) an attacker can throw at reverse engineering, the more likely they can work around steps taken to secure hardware internals.  Soldering irons, oscilloscopes, lasers and more can enable access to many commercial systems.  Hardware security isn’t magical; it’s just a set of clever techniques refined over many years.  These techniques are designed to make it difficult and expensive to reverse engineer or tamper with hardware, but with enough time and money, it can be done.

The second point is time.  The security field is constantly evolving, and once a new attack is discovered, it becomes part of an attacker’s toolbox forever more.  What’s more, attacks have a tendency to inspire other attacks.  (See Spectre and Meltdown as recent examples that have spawned more than a dozen subsequent attacks.)  So yesterday’s blackbox is today’s greybox is tomorrow’s …

Are we saying there’s no value to secure hardware?  Of course not.  When available, secure hardware such as HSM’s, TPM’s and secure bootloaders should be incorporated into your overall protection solution, and indeed will often form the root of trust for that solution.  However, we caution against relying exclusively on secure hardware.  Saying “my code runs in a TPM, therefore it’s secure” is saying that not only is that hardware a blackbox against any potential attackers, it will remain a blackbox for the lifetime of your application.  History tells us that assumption just doesn’t hold water.

We’d love to hear your thoughts/feedback/questions on this! Please reach out to contact us.

Leave a Reply