What's the point of hiding the key in white box cryptography if the attacker already has full access to the encryption (or decryption) implementation?

The attacker doesn't need the key in order to decrypt ciphertexts or encrypt plaintexts since he/she already has the full implementation.

• So what's the point of hiding the key?
• What advantage would the attacker even have by knowing the key?

Update: ddddavidee's answer below, in the second paragraph, raises an interesting point: a white-box implementation of a symmetric cipher that exhibits the "one-wayness" property - i.e. it is infeasible to derive the decryption circuit from the encryption circuit, or vice versa - can be used to create an assymetric cipher. That would indeed be useful. Note that key-extraction security - i.e. it is infeasible to derive the key from the encryption (or decryption) circuit - is a necessary but not sufficient condition for achieving one-wayness.

However, I'm still stumped by the tenor of the first paragraph of ddddavidee's answer, which is why I asked this question to begin with. The model for an attacker of a white-box implementation assumes that they have full access to the encryption (or decryption) circuit. In that case (aside from the scenario in the previous paragraph), what is the point of the notion of key-extraction security, or key-extraction itself, for that matter, since the attacker can accomplish any encryption without using the key? Either I am missing something or there is something missing or flawed in the definition of white-box cryptography itself.

• In white box cryptography anyone could use the algorithm to encrypt something but the key is irretrievable, only the person that originally created the key can then decrypt the message again. Oct 11, 2019 at 15:38
• As per ddddavidee's answer, that is only true if the implementation exhibits the "one-wayness" property. See my comment to his answer below as well. Oct 11, 2019 at 16:14

The main goal is to, at least, oblige the attacker to use the software to consume the encrypted message and avoid to use it on a different platform. It is quite easy to understand this reason if one thinks to the DRM (Digital Right Management) model: one vendor sells hardware with the capability to show some media content. If an attacker can decrypt and use the content on her PC the vendor loses some market. In the mobile payment context one wants to avoid that a malware could steal payment keys and use them in a different platform against the legit user. A different use is to protect the Intellectual Property from the final user: some piece of firmware or software has to be given to the final user but the vendor wants to keep it protected. Other examples can be found thinking when, where and why hardware tokens are used. The white-box encryption can be seen as, with some other software security measures, as a cheap replacement for the hardware tokens (or smart cards).

Moreover you can see the white-box encryption as a way to transform a symmetric key algorithm into a asymmetric one. If it is infeasible to reverse the white-box encryption algorithm into a decryption one and it is infeasible to extract the key, only the encryption algorithm is available and the decryption remains infeasible. The same applies in the opposite direction: providing a white-box decryption makes impossible to encrypt something under the same key.

Some other security properties are discussed in this paper White-Box Security Notions for Symmetric Encryption Schemes

In particular the "incompressibility" property says that "should not be possible to output a program smaller than the challenge one doing the same crypto-operation". Some solutions have published achieving a provable incompressibility, the reason motivating such construction is that it is more difficult for a national agency to store (say) 1 terabyte of key per person to decrypt the targeted user data, while would be feasible to store the corresponding 128-bit key.

• I see your point about the use of white-box {en,de}cryption to obtain an assymetric cipher from a symmetric one. I believe some papers called this a "one-wayness" property of the white-box symmetric cipher implementation, although I haven't actually seen any implementations that exhibit this property. Oct 11, 2019 at 16:04
• What I don't understand is the part where you said "If an attacker can decrypt and use the content on her PC." That "if" is not hypothetical. It is a consequence of the white-box attacker having full access to the implementation. With this access, the attacker can copy the implementation as he/she sees fit, and use it anytime, anywhere. What's the point of hiding the key then? I believe the literature calls this a "code-lifting" attack. I guess my point is that I don't see how white-box cryptography can be useful in this context (DRM, etc), in light of code-lifting attacks. Oct 11, 2019 at 16:08
• @GiulianoSider Generally the whitebox implementation of an "encrypt" function would not be distributed with an implementation of a "decrypt" function - the key holder would generate both circuits and distribute the "encrypt" circuit publicly but keep the "decrypt" circuit secret. The decrypt circuit exists, but is not made public. There are plenty of things that can be achieved by doing so. Oct 11, 2019 at 16:33
• @Ella Rose, to prevent attackers from deriving the "encrypt" function based on the "decrypt" implementation, you would have to engineer your implementation very carefully to exhibit this "one-wayness." It is by no means automatic. The attacker may be able to reverse the algorithm by reversing each round of the algorithm, for example. This can be done in published algorithms like Chow's white-box AES, SPACE, SPN-Box, etc. Oct 11, 2019 at 16:48
• I put the sentence in a hypothetical way, with an "if" because even if as today we do not have any provably secure white-box construction for the AES algorithm there is no proof of its impossibility. And the discussion was about a "secure white-box implementation". Code lifting attack is a real threat in the real use case of white-box encryption, but WBC has, IMHO, to be considered only as a brick to build a security solution and that can be paired with other software security soliution (anti-tampering, anti-debug, binding, ...) Oct 12, 2019 at 10:56