what are the most popular building and packaging tools for python ??

[Andrew Dalke]

Bengt Richter wrote:
> Using this kind of system, a customer would give you his CPU's public key and serial number,
> and you would send him the encrypted code as part of your app package. No other CPU would
> be able to run this code, since no other CPU would have the matching private key
> to decrypt it. Yes, someone could send a bogus non-CPU public key that he has the private
> key for, so there would have to be an authentication of CPU public keys in some kind of
> registry, presumably generated by CPU manufacturer, mapping chip serial number to its
> *public* key, available for checking at some authenticable site.
> 
> Maybe I am missing something, but this seems feasible to me.

When the software starts, how does it know it's getting data from the
cryto core?  It could be running on an emulated processor that supports
the new verification system.  I use it to generate the public key and
get the code from you.  I then save the state of the emulated
machine and send a copy of the image and your software's key to all
my buddies.  Poof, they can use it, albeit slowly.

Your solution to that is a global registry.  If you only check it
once, when the license key is generated, then all it takes for the
emulator to work is for someone, somewhere in the world to reverse
engineer the key for a given CPU.  And experience has shown that
it's very hard to design tamper-proof crypto hardware.  There are
attacks like looking at the power draw on the circuitry to estimate
where in the process the verification failed.  See comp.risks for
many more.

Even if it isn't emulated, how does the software connect to the
core?  Can I put a shim between the software and the OS that
intercepts the crypto calls and replaces them with my own calls?

(Some examples of this in real life include malloc debuggers,
OpenGL debuggers, and system call tracers.)

If so, I can register the software with the public key generated
from my shim, which acts like a real machine.  Or I can record the
messages and attempt a replay attack.  If your software generates
a nonce to get around the attack, well, how does it generate the
nonce?  Can I make it so it always uses the same value?

If I can't insert a shim, I can still write software to scan
your program as a text file and look for where it makes the
system calls, then rewrite the binary to make calls to something
I can intercept.

It would take some work, yes, but it only needs to be broken
once.  If it's embedded in common hardware that just means more
people will attempt to hack it even for fun.  For example, look
at the XBox Linux to see how people have figured out how to
break that protection system.  There's even a book on the topic:
   http://www.hackingthexbox.com/

Hardware supported copy protection has been tried many times
over the last few decades.  The approaches I outlined above
are some of the standard ways to break them and unless I
misunderstood your suggestion, they can easily be applied
here as well.

				Andrew
				dalke at dalkescientific.com