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, BELGIUMoffice 01.53
brecht.wys...@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 majord...@metzdowd.com
