[Tutor] Need help with encoder & decryption keys
Andreas Kostyrka
andreas at kostyrka.org
Mon Mar 3 14:28:11 CET 2008
And if it's a string constant, in many cases running strings (Unix
program) on the pyc file will reveal it too.
All this basically turns down to the problem, that it's hard to embed an
encryption key in a program, so that it's not possible to extract it.
Notice the the current crop of HDDVD/Blueray decrypters, that tend to
derive their copy of the key by extracting it from legal software players.
(Hint: it's a basically unsolvable problem, notice how the industry
"solved" it by making that kind of analysis illegal, DMCA is the hint here.)
If you want to have "typical" C program security for embedded key data,
the only thing that you can do is to make a Pyrex module (Which gets
compiled to C, and is loaded as an .so shared library).
As pointed out above, this is not really safe, it just makes it slightly
harder to extract the data.
Some thoughts:
1.) the data cannot be made accessible to Python, or else you can read
it out. That means decryption/encryption needs to be done in Pyrex/C.
PLUS Pyrex should not use any Python functions/modules to achieve the
goal. (import secretmodule ; print secretmodule.value. OR: import md5 ;
md5.md5 = myLoggingMd5Replacement )
2.) the stuff done in your C module cannot be to trivial, or an attacker
that is determinated can easily remove references to the module.
So to summarize: Your idea usually makes no sense. It clearly falls into
the "know what you are doing and why" ** n category, with n > 1 ;)
There might be technical or legal reasons to do that, BUT they are
really, really seldom.
And this category question is usually not really appropriate for a
tutoring mailing list :)
The only way to make sure something is not compromised is to avoid
giving it out completely, and put it on your own servers. Again, the
above thoughts apply. Plus consider that your program is running in an
environment that you do not control: E.g. even if you communicate via
SSL and check certificates, and embed the CA certificate into your app
so that it cannot be easily replaced. Consider loading a small wrapper
for SSL_read/SSL_write via LD_PRELOAD. Oops, the user just learned the
complete clear text of your communication. Worse if it's to simple he
can just replace the data, worst case by loading a wrapper around
openssl that mimics the server.
It's no fun, and the easiest way is to give your users the access (e.g.
the source code). This stops the crowd that has to prove itself for the
fun of breaking a security system. (And yes, there are people that do
that). Then put your rules into the LICENSE. That lays out the rules
what is allowed. And in some cases, add some lines that check
"licenses", so a customer cannot claim that he ran your program
unauthorized by mistake. Not much more you can do here, sorry.
Making it hard to remove the license check means just that the fun crowd
might get motivated into breaking it. Leaving out at least some checks
means that users can claim that they ran a copy of your program by
mistake. That might have legal ramifications, and worse, in many cases
(if you are not a member of BSA), you wouldn't want to sue a customer
anyway, right? (Nothing surer to piss off a customer than to sue him.)
Andreas
Kent Johnson wrote:
> Trey Keown wrote:
>> is it
>> possible to decompile things within a .pyc file?
>
> Yes, it is possible. There is a commercial service that will do this,
> for older versions of Python at least.
>
> To figure out a secret key kept in a .pyc file it might be enough to
> disassemble functions in the module; that can be done with the standard
> dis module.
>
> And of course if you stored the secrets as module globals all you have
> to do is import the module and print the value...
>
> Kent
> _______________________________________________
> Tutor maillist - Tutor at python.org
> http://mail.python.org/mailman/listinfo/tutor
More information about the Tutor
mailing list