8
$\begingroup$

Background: I want to use white-box cryptography to hide the keys stored in a client application.

I am looking for existing implementations of white-box cryptography, such as AES 128 or 256. But I found that almost all the existing implementations are breakable in some reasonable period of time. For example, see the CHES 2017 challenge and BGE attacks on the original Chow's scheme, etc. I haven't been able to find a mature/unbroken implementation so far.

My objective is to make WBC implementation very difficult to be broken. As we know,

1) WBC aims to protect cryptographic algorithms against key recovery

2) Code obfuscation aims to protect against the reverse engineering of a cryptographic algorithm.

Thus, I want to use a published WBC implementation (may be broken already), and then apply obfuscation on the code (e.g., C++).

  1. Is the above way reasonable (if we cannot find a proper implementation)?

  2. Please recommend any mature WBC implementations (not broken yet)

  3. Any better ideas? (other than re-design & evaluate a new WBC algorithm)

$\endgroup$

migrated from security.stackexchange.com Jun 3 at 9:53

This question came from our site for information security professionals.

  • 4
    $\begingroup$ Using code obfuscation is already more or less what white box crypto does, and adding a new layer of home-crafted obfuscation is unfortunately very unlikely to make the code more resistant to known attacks. The only known way to currently have "some" security in code obfuscation is by doing what e.g. Apple is doing, namely, hiding the very method used to obfuscate, and having a super strong control to ensure that this method does not leak. And this is known to not be a great approach to security, to put it mildly. $\endgroup$ – Geoffroy Couteau Jun 3 at 11:36
  • 2
    $\begingroup$ Also this (kind of) goes against Kerckhoffs's second principle because it protects the algorithm and since you referenced AES code-obfuscation doesn't really make sense. Best to assume that the enemy knows the algorithm. $\endgroup$ – AleksanderRas Jun 3 at 11:56
7
$\begingroup$

Is the above way reasonable (if we cannot find a proper implementation)?

No, there are currently no such code-obfuscation algorithms that securely obfuscate code to a point where it's very hard to reverse engineer it.

Please recommend any mature WBC implementations (not broken yet)

I'm not aware of any WBC implementations for AES.

Note, that a successful implementation of a WB-AES algorithm would mean that the "one-wayness" (very hard to invert) would turn this algorithm into a public-key-cryptosystem without a need for asymmetric cryptography (you would just publish the WBC-AES-implementation and the key wouldn't leak). So I'm pretty sure that there are no unbroken implementations.

It could be that there are some unbroken WBC implementations out there, but I don't think that they would remain unbroken for long if they would attract a lot of attention from the cryptographic community.

Any other better idea? (other than re-design & evaluate a new WBC algorithm)

No. As Geoffroy Couteau and I commented, self-made code obfuscation is likely unsecure for many reasons, the main reason being that the security would rely on the fact that nobody ever would gain knowledge of your obfuscation algorithm.

$\endgroup$
  • $\begingroup$ for Q1, if I add WB algorithm as part of my application's C++ code, and apply LLVM obfuscator on the code. how about it? $\endgroup$ – TJCLK Jun 4 at 1:51
  • $\begingroup$ i am not very understand why "would turn this algorithm into a public-key-cryptosystem"? i would like to embed the "master key" (e.g., AES) in the WB, so I can use this WB to encrypt/decrypt other child keys, without additional effort to hide the master key (assume WB is secure in theory) $\endgroup$ – TJCLK Jun 4 at 1:56
  • 1
    $\begingroup$ @LiDong Applying LLVM obfuscation would probably make the reverse engineering harder but as I said it's currently possible to reverse all obfuscation processes. About the public-key-cryptosystem: It could be used as such but doesn't have to be used as such, you could very well encrypt/decrypt other child keys with a WB implementation that has the AES master key embedded in the algorithm. $\endgroup$ – AleksanderRas Jun 4 at 6:19
  • 1
    $\begingroup$ @LiDong, "would turn this algorithm into a public-key-cryptosystem" explains some like: the white-box implementation is used as a public key, so it can only encrypt and if the key cannot extracted only who generated it knows the embedded AES key and can use it to decrypt the ciphertext. To work like this one requires that the key cannot extracted from the white-box implementation and the white-box cannot be "reversed" to produce a decryption routine from the encryption one. $\endgroup$ – ddddavidee Jun 6 at 12:21
3
$\begingroup$

Adding software obfuscation to the standard white-box designs is close to what it is already done in the industry. This solution is not strong enough, it can be somewhat useful to make reverse engineering harder and make the attacker spend a longer time to fully understand the underlying design but does not avoid the key extraction. Software obfuscation, indeed, makes harder to understand and potentially lift some portion of the code but does not avoid the execution of the encryption function. Few years ago, a new family of attack techniques, borrowed from the secure element world, has been successfully applied to the white-box context (see Differential Computational Analysis(video here), Differential Fault Analysis, shameless plug: Bucketing Attack). With those more recent techniques, even if the software is obfuscated the attacks are effective.

On the other hand, code obfuscation aims to hide the logic of the obfuscated algorithm, and usually, this is not the same security target of such situation you described, code obfuscation aims to hide that the obfuscated code is an AES implementation, but from a security point of view, the attacker already knows the encryption algorithm, only the secret key has to be protected. Code obfuscation in this context is used to hide how it is computed and in particular when/where the key is loaded in memory, data obfuscation is used to hide the link between some loaded data and the plain AES key.

If you are looking for white-box designs you can have a look here: Side-Channel Marvels (more specifically in Deadpool) or OpenWhiteBox.

Better ideas...

actually the scientific community and the industrial one are actively looking for a better idea and solution to the problem. The industrial world is looking for a secure enough solution staying secure for the life of the product (at least until next update). As today no know design is considered secure, and as a consequence the industry produces software security solutions including (but not limited) to white-box cryptography, anti-tampering and anti-reverse engineering techniques, but to keep an advantage over the attacker the details are not public. Some other (non published) designs are available at the WhibOx Contest - Edition 2

$\endgroup$
3
$\begingroup$

There are no unbroken and published designs. The strongest recently published design from CHES 2017 challenge withstood attack for slightly less than a month and the strongest design from WhibOx 2019 challenge withstood attacks for 51 days since publication.

If you can, choose an alternative to AES white-box:

  • use hardware-backed operating system features to store and use the key (e.g. Android Keystore, iOS Secure Enclave)
  • use trusted application in TEE (Trusted Execution Environment, such as ARM TrustZone, Intel SGX)
  • change the design so that security of keys during use are not so critical
  • use a custom white-box algorithm instead of AES (this will thwart typical white-box attacks but is a mine-field in itself)

Applying obfuscation may help depending on the type of the attack and the features of obfuscation but you will probably never know until you do a penetration test or discover a hack after you publish your application.

Also please note that in the CHES challenge, encryption of a single AES block could take up to a second and the code could be 20 MB big, which means that performance and size of a decent white-box will be a concern.

BTW, even if you had access to a perfect white-box implementation, you may still need to further protect it against code lifting (attackers simply using your code to encrypt and decrypt, instead of learning the key).

In short, white-box protection is extremely difficult and good free versions of AES white-box don't exist.

Disclaimer: I work for a company, selling white-box implementations.

$\endgroup$
1
$\begingroup$

To my knowledge, there is no white-box cryptographic algorithm that is "secure" in cryptographic sense, that means its security depends on a random key from a space of certain size.

In practice the "security" of white-box cryptography is achieved by hiding implementation and by employing automated updates to quickly replace the key with new implementation when the old one is broken.

Two sad conclusions follow: 1) The best white-box cryptographic algorithms will never be published and will be available only at very high price. 2) White-box cryptography in its current state is completely unsuitable for Open Source software.

$\endgroup$
  • $\begingroup$ If it's never published, it very likely won't be the "best" because not enough people can attack it. $\endgroup$ – forest Jun 18 at 1:47
1
$\begingroup$

I just wanted to add a reverse engineering perspective on this sort of thing, since I've broken some such systems before.

Attackers often don't care about unraveling the math to determine the original algorithm. You can just copy the obfuscated algorithm outright from the (for example) movie player. It doesn't matter whether the code is simplified.

The only way to get partial success is to obfuscate the whole program and intertwine the encryption with the rest of the program to make it hard to isolate. Also, this allows for tamper resistance and anti-debugging techniques.

But in the end, just remember that always it takes longer to make an obfuscation system than it takes an attacker to break it. Nobody has ever gotten around this; just ask Denuvo.

$\endgroup$
  • 1
    $\begingroup$ you mean prevent code lifting? $\endgroup$ – TJCLK Sep 24 at 6:27
  • $\begingroup$ @LiDong Yes. I didn't know that the technique had an academic name - I just used it. Thanks for telling me the name =^-^= $\endgroup$ – Myria Sep 24 at 14:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.