Joppe Bos from NXP gave the same talk I had seen a couple month ago at SSTIC .
To recap the white box model:
you can inject fault you can access the source code you can alter the memory, observe it ...If a secure whitebox solution exists, then by definition it is secured to all current and future side-channel and fault attacks .
In practice we only know how to do it for symmetric crypto (although that's not what Mike Wiener said after (but his design is proprietary))
Chow et al. construction:
converted every operation (mixcolumns, xor, etc...) in LUT (look up table) applied linear encoding to inputs and outputs of look up tables (input/output encoding) adding non-linear encodings to inputs and outputs as wellAnd this is the reason why it only works for symmetric crypto. For richer math problems like RSA we can't do all these things.
In practice you do not ship whitebox crypto like that though:
you add more obfuscation on top, just to make the work of the hacker harder) you glue the environment to the whitbox, so that you can't just take the whitebox and hope it will work) you support for traitor tracing , if the program is copied to other people you can trace where it came from you create a mechanism for frequent updating, so a copy of the whitebox is useless after some time, or if you end up breaking it it might be too late ...In practice to attack:
you reverse-engineer the code (time-consuming) identify which WB scheme is used target the correct look up tables apply an algebraic attackBos' approach:
is it AES or DES? launch the attack (that's the only thing you need, see how they pwned the CHES challenges)The idea is to create software traces like power traces using dynamic binary instrumentation tools (Pin, Valgrind). They created plugins for both of them. Then they record every instructions in memory made by the whitebox and apply a DPA-style attack. If you don't know what that is check my video on the subject here .
The idea here is that you can't remove some correlation with input/ouput encoding
they can visually tell what's the cipher by looking at the memory trace
picture of AES, the 10th round is different so you don't see it
And if memory access is made linear, you can still look at the stack access and it will reveal the algorithm as well
They can do better than a CPA (Correlation Power Analysis) attack, which they call a DCA (Differential Computation Analysis) . The hamming weight makes a lot of sense in the hardware setting, but here without the noise and the errors it does not so much. Also they need way less traces. All in all, these kind of DPA attacks are much more powerful in a software setting compared to a hardware setting.
By the definition of the WB attack model, implementations shouldn't leak any side channel data. tl;dr: they all do. Well, except when there is this extern encoding thing (transformation added to the beginning and the end of AES).
intuition why this works: Encodings do not sufficiently hide correlations when the correct key is used.
Countermeasures?
most of the countermeasures against DPA/CPA rely on random data (but in the WB model we can't rely on random data...) if you take large encodings, this attack shouldn't work anymore (why? dunno)The code is on github!
Marc Witteman - Practical white-box topics: design and attacks IIThe hype of WB crypto comes from mobile payment and streaming video. Today if you look in your pocket you most probably have a whitebox implementation.
In practice for an attack you need to:
root the phone decompile/disassemble code use a debugger to step through the code instrumentate the binary to change the behavior of the code
They applied the Differential Fault Attack (DFA) on a bunch of whitebox implementations, broke almost all of them except the ones using extern encoding (apparently in banking there is no extern encoding because of "constraints")
But overall, if you're designing whitebox crypto, you don't need to make the implementation perfect, you just need to make it good enough