Re: consulting question.... (DRM)

2009-05-30 Thread Jerry Leichter

On May 29, 2009, at 8:48 AM, Peter Gutmann wrote:

Jerry Leichter writes:

For the most part, software like this aims to keep reasonably honest
people honest.  Yes, they can probably hire someone to hack around  

licensing software.  (There's generally not much motivation for J
Random User to break this stuff, since it protects business software
with a specialized audience.) But is it (a) worth the cost; (b) worth
the risk - if you get caught, there's clear evidence that you broke
things deliberately.

I think a far more important consideration for license-management  
isn't how secure is it but how obnoxious is it for legitimate  
users?  I
know a number of people who have either themselves broken or  
downloaded tools
to break FlexLM and similar schemes, and in every single case they  
legitimate users who were prevented from using their legally  
purchased product by the license-mismanagement tools, or who after  
spending hours or even days fighting with the license-mismanagement  
software found it easier to break the protection than to try and  
figure out what contortions were required to keep the license- 
checking code happy

I agree 100%.

The most important thing to keep in mind when doing license management  
software is that it has *NO* value to the *customer*.  The guys who  
sell this stuff will always claim that it helps the customer keep  
track of licenses or some such rot - but it's complete nonsense.  In  
fact, license management code has *negative* customer value.  That  
doesn't mean it doesn't have a legitimate role - the cash registers in  
the supermarket add a negative value to all the sold, but the  
supermarket wouldn't be there without them.  But unless you  
understand, deep down, that this is something that you're imposing on  
your customer and that therefore it needs to be as close to invisible  
and fail-safe as possible; and you act *effectively* on that basis -  
you're just going to encourage circumvention or a search for  
alternatives to your software.

-- Jerry

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

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

2009-05-30 Thread 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:

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

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.

I also wrote a (rather theoretical) paper to settle a concrete
definition of white-box cryptography, which you can find on e-print:
 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

 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


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


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

P=NP if (P=0 or N=1)
GPG Pub key:
GPG Fingerprint: 890C 7C0B F1D9 597E F205 87C8 B716 D7D3 20F8 353F

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

Re: consulting question.... (DRM)

2009-05-30 Thread John Ioannidis

John Gilmore wrote:

PPS: On a consulting job one time, I helped my customer patch out the
license check for some expensive Unix circuit simulation software they
were running.  They had bought a faster, newer machine and wanted to
run it there instead of on the machine they'd bought the node-locked
license for.  The faster their simulation ran, the easier my job was.
Actually, I think we patched the Unix kernel or C library that the
program depended upon, rather than patch the program; it was easier.

Kernel. Instead of calling the subroutine that would retrieve the 32-bit 
hostid from the PROM, you just did a load immediate with the right 
number.  The instructions were the same length, so everything worked fine :)

Not that I know of any places that actually did this, of course :)


The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to