Usually, I don’t react strongly to articles that contain bullshit. But when I stumbled on an article that contained three false statements in the very first sentence, I simply could not leave it be.

The first sentence of the article is:

Program obfuscation is a breakthrough and trending field of cryptography.

– valerini

My post touches a lot of topics, and I’m not an expert in any of those.

Strong opinion inside.

What’s white-box crypto?

The challenge that white-box cryptography aims to address is to implement a cryptographic algorithm in software in such a way that cryptographic assets remain secure even when subject to white-box attacks.

This technology allows to perform cryptographic operations without revealing any portion of confidential information such as the cryptographic key.

– whiteboxcrypto.com

As far as I understand, the formulation of the problem is the following:

• Alice gives Bob software with some crypto and keys inside
• The software can decrypt ciphertexts that Alice will give to Bob
• Bob should not be able to extract the decryption key from the software
• There Bob is evil for trying to figure out what’s the software doing on his own computer

Personally, I already see several problems within that problem formulation:

• Why is Alice trying to hide the key from Bob? Bob gets to see the plaintext anyway!
• Bob can simply use the obfuscated code for ciphertext decryption aka “code lifting”, which defeats the purpose of encryption.
• Security through obscurity? It does not seem to conform Kerckhoffs’s principle, therefore it is not strong crypto.

Anyway, why would you want to do such a useless thing?

White-box cryptography is the breakthrough technology that enables modern day software DRM systems.

– Schultz12

Ah, now I see. Alice is trying to imlpement a DRM system, so she converted one broken problem to another more narrow (and still broken) problem and called it “white-box crypto”.

It would probably be fair to call White-box crypto “DRM”, I’ve failed to find any other application for it.

What’s algorithm obfuscation?

There is a good paper on the theoretical impossibility of program obfuscation even under very weak formalization Barak01, which removes one way to achieve the goal of WBC. And another paper shows some classes of function that cannot be obfuscated Goldwasser07.

The other paper Goldwasser07 states that the best possibly achievable obfuscation is “indistinguishability obfuscation” which tells us nothing about extracting data from obfuscated programs.

All WBC implementations I know of depend on embedding the key in the algorithm and obfuscation, and have been defeated.

When talking about obfuscation, some people mention that it is possible Wee05 to “hide” point function implementation in the code. Which is basically checking the hash.

myHiddenPointFunction x = sha256(x, "f5cb1e...") == "5b27d1..."
# the entire article reduced to a single line of code

Or that it is possible to obfuscate some other functions: Ran10, Zvika05 … which are way, waaay far from obfuscating decryption, especially AES.

What do the authors of WBC say about WBC security?

all references, excluding Wyseur12, in the following paragraph are taken from Wyseur12 have not been read/verified by me, there are no download links

After reading the file Wyseur12 by a proponent of WBC, I noticed that in that very paper the author mentions that all other previous attempts on WBC implementations have been defeated [Jacob02], [Link05], [Wyseur07], [Billet04]; can be defeated in a similar way [Mich08]; can be defeated with a similar formulation of a problem [Wyseur09]; and modifications have been defeated too [Bri06wbc], [Dem10].

And also quote:

Despite all the new constructions that have been presented, the security of white-box cryptography is very unclear. Almost all of the presented constructions have been shown insecure with academic cryptanalysis papers that have been published. Only a few constructions remain ‘unbroken’, but they are merely a minor tweak to existing constructions – hence the existing attacks will apply with little effort.

So the author is focusing on the obfuscation part, and making obfuscation less prone to code lifting, reverse engineering, etc.

And WBC now becomes a problem of software obfuscation. We’ve completed the circle.

The Many Facades of DRM

After reading the file Schultz12, I’d like to quote

White-box cryptography … enables modern day software DRM systems. Without this technique digital media distribution from iTunes, Amazon, and others using software DRM protection would simply not exist.

And call bullshit twice:

• Most of all known WBC is broken as shown in Wyseur12, therefore it “enables” nothing.
• iTunes is selling DRM-free tracks. People like it and AAPL gets the profits.

Then the author is referencing [Chow02AES] as WBC implementation, which is defeated by [Jacob02] and [Link05] as been claimed in Wyseur12.

Homomorphic encryption is unrelated

I remember some people claiming that homomorphic encryption might somehow help with white-box crypto implementation.

Here’s why not: homomorphic encryption assumes that computation is carried on the ciphertext, and plaintext (modified or not) is never available to the party performing the computation. Once that party gets the plaintext, that assumption is broken, and within WBC problem formulation plaintext is available to the end-user.

Additional info on WBC

Souchet15AES gives a great example of AES WBC implementation, but he shows how to defeat it (apart from obfuscation) in the same article.

Khovratovich13WBCSurvey (video) is a survey on WBC.

In the question section someone gives a comment 52:59 I’d like to quote

First of all, thank you for the presentation because it helped shed some light on the mysterious topic of white-box cryptography. And it helped me calling out bullshit on the whole idea, I think someone should make this critical comment, because the whole concept breaks with one of the principles of cryptography that the algorithm should be verifiable. If you obfuscate it to hide something… if it’s only hiding the key, it’s no use because I would not go after the implementation at all, I would use other ways to attack and recover the key. Everybody knows how easy that is. And if it obfuscates even more, it changes it, then it breaks with the principle of being verifiable. So I think that the whole thing is snake oil and should not be used by anybody.

Summary

• White-box cryptography problem formulation is utterly broken.
• All existing white-box cryptography implementations do not achieve their purpose.
• The only application for white-box crypto is DRM, which is a broken task on its own.
• The only ways to implement WBC seems to be algorithm or software obfuscation.
  Neither are shown to be doable securely for any sufficiently interesting tasks.

The world is going to be a better place without “white-box crypto”.

Used literature

[Barak01]: Boaz Barak et al. “On the (Im)possibility of Obfuscating Programs” wisdom.weizmann.ac.il/~oded/PS/obf4.pdf
[Goldwasser05]: Shafi Goldwasser, Yael Tauman Kalai “On the Impossibility of Obfuscation with Auxiliary Input” http://research.microsoft.com/en-us/um/people/yael/publications/2005-impossibility_obfuscation.pdf
[Goldwasser07]: Shafi Goldwasser, Guy N. Rothblum “On Best-Possible Obfuscation” iacr.org/archive/tcc2007/43920194/43920194.pdf
[Wee05]: Hoeteck Wee “On Obfuscating Point Functions” cs.columbia.edu/~hoeteck/pubs/obf-point-stoc05.pdf
[Zvika05]: Zvika Brakerski, Guy N. Rothblum “Black-Box Obfuscation for d-CNFs” eprint.iacr.org/2013/557.pdf
[Ran10]: Ran Canetti et al. “Obfuscation of Hyperplane Membership” iacr.org/archive/tcc2010/59780071/59780071.pdf
[Wyseur12]: Brecht Wyseur “WHITE-BOX CRYPTOGRAPHY: HIDING KEYS IN SOFTWARE” whiteboxcrypto.com/files/2012_misc.pdf
[Schultz12]: Rod Schultz “The Many Facades of DRM” whiteboxcrypto.com/files/2012_MISC_DRM.pdf
[Souchet15AES]: Axel Souchet “Spotlight on an Unprotected AES128 White-box Implementation” doar-e.github.io/blog/2015/02/08/spotlight-on-an-unprotected-aes128-whitebox-implementation/
[Khovratovich13WBCSurvey]: Speaker: Dmitry Khovratovich “White-Box Cryptography Survey” [30c3] youtube.com/watch?v=om5AVTqB5bA

Not actually used literature

[Jacob02]: Matthias Jacob, Dan Boneh, and Edward W. Felten. “Attacking an Obfuscated Cipher by Injecting Faults” 2002
[Link05]: Hamilton E. Link and William D. Neumann. “Clarifying Obfuscation: Improving the Security of White-Box DES” 2005
[Wyseur07]: Brecht Wyseur, Wil Michiels, Paul Gorissen, and Bart Preneel “Cryptanalysis of White-Box DES Implementations with Arbitrary External Encodings” 2007
[Billet04]: Olivier Billet et al. “Cryptanalysis of a White Box AES Implementation” 2004
[Mich08]: Wil Michiels, Paul Gorissen, and Henk D.L. Hollmann “Towards Security Notions for White-Box Cryptography” 2008
[Wyseur09]: Brecht Wyseur, “White-Box Cryptography” 2009
[Bri06wbc]: Julien Bringer, Herve Chabanne, and Emmanuelle Dottax. “White box cryptography: Another attempt”
[Dem10]: Yoni De Mulder, Brecht Wyseur, and Bart Preneel, “Cryptanalysis of a Perturbated White-box AES Implementation”
[Chow02AES]: Stanley Chow, Philip A. Eisen, Harold Johnson, and Paul C. van Oorschot. “White-Box Cryptography and an AES Implementation” 2002