Whitebox Cryptography

Protect sensitive keys and data

Until not that long ago, cryptography was done using hardware. This didn’t mean everyone was using strong cryptographic hardware; it meant most applications weren’t using crypto at all. However, as computers started to proliferate into all aspects of our lives, the need to secure data became ever greater, and software cryptography became a necessity. Consider the difference – when DES was chosen as the first government cryptographic standard, it was deliberately designed to be inefficient in software. Fast forward 20 years, and software efficiency was one of the primary criteria for evaluating the AES candidates.

This early focus on hardware had an interesting effect; cryptographic implementations, when actually running, were considered a blackbox.  All the attacker could do (we postulated) was feed in inputs and examine the outputs.  To this day, when evaluating the security of new cryptographic algorithms, this blackbox attack context is still the primary model.  The problem is, this model isn’t the right one for software, especially software on a system controlled by the attacker.

In 2002, four researchers, three of them working at Cloakware® (now Irdeto), published two papers [1, 2] that proposed a new model for evaluating cryptographic software; the whitebox attack context.  In this unfortunately all-too-real context, attackers not only see inputs and outputs, they see – and can manipulate – every intermediate computation and piece of data.  Importantly, this isn’t a choice; if you are doing cryptography in software, you are subject to whitebox attacks.

whitebox_diagram-01

Figure 1: The blackbox, greybox and whitebox attack contexts.  Note that every blackbox and greybox attack is also a whitebox attack.

However, these same papers also proposed the idea of cryptographic implementations that were specifically designed to resist whitebox (as well as black- and grey-box) attacks.  Because “cryptographic implementations designed to resist whitebox attacks” was a pretty cumbersome name, though, they shortened it to whitebox cryptography (initially hyphenated white-box until it fell into common usage).

These papers discussed AES and DES respectively.  (Side note: the whitebox DES implementation actually came first, but the authors decided to publish the results on AES first because AES was the newer standard.)  This reflected the abiding belief that cryptographic implementations for software environments should still use well-studied algorithms based on solid security principles.

Hot on the heels of these early papers, Irdeto in 2002 also produced the first commercial implementation of AES with whitebox attack resistance; this implementation quickly became known as whitebox AES.  Several other industry firsts followed:

  • First dynamic-key whitebox AES in 2003
  • A series of faster and smaller whitebox AES implementations, dropping table sizes from over 1MB to under 100KB, and increasing performance by 100x
  • First whitebox ECC in 2006
  • First whitebox RSA in 2007
  • First whitebox SHA in 2010

As useful as whitebox cryptography is for protecting sensitive keys and data, it loses a lot of its value if the data on which it operates becomes exposed through subsequent processing, if every instance looks the same, or if users have to share their keys with the party creating the whitebox implementations.  To address these issues, in 2005 Irdeto created Flexible Libraries [3], and have been delivering their whitebox crypto implementations this way ever since.  A whitebox crypto Flexible Library can be easily incorporated into an application by simply calling its API.  At the same time, it can be provisioned along with the rest of the application, ensuring data is protected both inside and outside the cryptographic implementation, letting the user choose their own keys – and every provisioning produces a completely unique implementation (diverse instances).

Speak to your trusted Healthcare Cybersecurity Partner now!

[1] S. Chow, P. Eisen, H. Johnson, P.C. van Oorschot. White-Box Cryptography and an AES Implementation. In 9th Annual Workshop on Selected Areas in Cryptography (SAC 2002), Aug.15-16 2002, St. John’s, Canada. Proceedings (revised papers): volume 2595 of Lecture Notes in Computer Science, pages 250-270, Springer LNCS 2595 (2003). Sept.30 2002 version: ps. Earlier version (pre-proceedings): ps. https://www.researchgate.net/publication/221274739_White-Box_Cryptography_and_an_AES_Implementation

[2] S. Chow, P. Eisen, H. Johnson, P.C. van Oorschot. A White-box DES Implementation for DRM Applications. In Proceedings of 2nd ACM Workshop on Digital Rights Management (DRM 2002), volume 2696 of Lecture Notes in Computer Science, pages 1-15. Jan 13, 2003 version: ps. https://crypto.stanford.edu/DRM2002/whitebox.pdf

[3] Eisen et al. (2013). United States Patent No. US 8510726 B2. Retrieved from https://patents.google.com/patent/US8510726