white-box crypto Was: consulting question....

[Brecht Wyseur]

James Muir wrote:
> Alexander Klimov wrote:
>   
>> On Tue, 26 May 2009, James Muir wrote:
>>     
>>> There is some academic work on how to protect crypto in software from
>>> reverse engineering.  Look-up "white-box cryptography".
>>>
>>> Disclosure:  the company I work for does white-box crypto.
>>>       
>> Could you explain what is the point of "white-box cryptography" (even
>> if it were possible)?
>>     
>
> The introduction to the following paper (from SAC 2002) gives a very
> good overview of white-box crypto:
>
> http://www.scs.carleton.ca/%7Epaulv/papers/whiteaes.lncs.ps
>   

The aim of white-box cryptography is to implement cryptographic
primitives in such a way that they remain /secure/ against software
analysis. The 'white-box' refers to the fact that the adversary has full
access to the software implementation and control over its execution
environment.

Its prior objective would obviously be the protection of secret keys
that are embedded in key instantiated implementations of encryption
schemes. But often it goes beyond that objective. In some practical
settings it will indeed turn out that the resulting white-box
implementation behaves as a public-key primitive, as you point out, but
for other applications, that might be overshooting the objective.

The paper that James mentioned introduced the subject of white-box
cryptography into academia. In the mean time, the subject received more
interest, and has been studied further on. For more information
(introduction and subsequent research), I'm happy to point you to my PhD
dissertation of March this year, entitled "white-box cryptography".

https://www.cosic.esat.kuleuven.be/publications/thesis-152.pdf

I also wrote a (rather theoretical) paper to settle a concrete
definition of white-box cryptography, which you can find on e-print:
http://eprint.iacr.org/2008/273.
>   
>> If I understand correctly, the only plausible result is to be able to
>> use the secret key cryptography as if it were the public-key one, for
>> example, to have a program that can do (very slow, btw) AES
>> encryption, but be unable to deduce the key (unable to decrypt). If
>> this is the case, then why not use normal public-key crypto (baksheesh
>> aside)?
>>     
>
> You're right -- a white-box implementation of a symmetric cipher
> essentially creates an asymmetric cipher.  Despite this, there are still
> situations where you might want a whitebox AES implementation running on
> a client.  Consider a server that sends out updates to several hundred
> clients (each client has its own key).  The clients are subject to
> whitebox attacks but the server is not.  Rather than force the server to
> do several hundred public-key operations when it needs to push out an
> update, we might be able to save the server some work if use a symmetric
> cipher.
>
> -James
>
>   
Consider a DRM application that contains a key-instantiated decryption
algorithm and some authentication scheme. In that case you want to
prevent the extraction of the secret key, otherwise an adversary could
easily circumvent the authentication scheme. Deploying a public-key
cipher wouldn't help achieving this objective, since it is a matter of
how you implement the decryption operation and entangle it with the
authentication scheme.

Another example might be a mobile agent system, where a signing key
would need to be embedded in the software such that the agent can sign
contracts.


Brecht
http://whiteboxcrypto.com

-- 
Brecht Wyseur
Katholieke Universiteit Leuven                      tel. +32 16 32 17 21
Dept. Electrical Engineering-ESAT / COSIC           fax. +32 16 32 19 69
Kasteelpark Arenberg 10, B-3001 Leuven-Heverlee, BELGIUM    office 01.53

                       brecht.wyseur at esat.kuleuven.be
                   http://homes.esat.kuleuven.be/~bwyseur

                                                    P=NP if (P=0 or N=1)
GPG Pub key:     https://homes.esat.kuleuven.be/~bwyseur/pubkey
GPG Fingerprint: 890C 7C0B F1D9 597E F205 87C8 B716 D7D3 20F8 353F

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com