On 02/11/2007, Michael Sparks <[EMAIL PROTECTED]> wrote:
> If you disagree with me,
It's not just me who things your a fool! There are experts in the field.
> I _am_ genuinely interested in hearing how you
> think you can prevent an attacker from accessing the keys they needs in order
> to use the decryption algorithm that's protecting the content such that the
> key can't be captured and such that the decrypted data can't be siphoned off
> when I have complete access to the source code and can recompile my own
> interoperable player.
I would like to know how you intend to protect the algorithm in
proprietary software when I have complete access to the binary, OS and
access to the hardware underneath both. I can simple drop down to the
lower layer and all your security is gone.
You can't protect either using proprietary software. It is not doable.
There are techniques to protect the key. I can achieve this very
simply using an open standard.
In fact I use this regularly. I'm not sure if you've seen the gold
part on your Debit/Credit card. It's a chip. It is in fact a tamper
resistant chip. It is simple to protect your key, put it on a tamper
resistant smart card (provided it is secured against the many attacks
that can be launched on such a device), Your key is secure. Job done,
you are wrong.
Of course secure the key doesn't stop one intercepting the decrypted
stream, but that's a problem with open and closed software. It is also
a problem with *ALL* current hardware implementations. The *ONLY* way
around this is to insert a chip with decryption capabilities directly
into the brain, do you want to volunteer to be the first to try this?
I wrote down some quotes from the relevant literature on some paper
(to avoid having to carry round all the books) and have consequently
left the paper with the books, which is not where I am now. Damn
I shall give you the gist and you can look them up (both are from
Applied Cryptography, I had one from a DRM conference but I forget
which so I am not including that)
An algorithm that depends on the secrecy of an algorithm is called a
restricted algorithm.
They are woefully inadequate in todays world.
The other one was along the lines of:
If you think nobody will decompile your program and reverse engineer
your algorithm then you are naive.
> (actually, some of these comments are getting a bit long, maybe I should put
> them on my blog instead... :)
Maybe you should actually read text from some security experts, and
even better learn to actually quote it to back up your points, instead
of just being so arrogant you consider yourself above everyone in the
field!
Much of your claims make no sense whatsoever.
> The question here is can you have a *completely* open source DRM mechanism
> where the keys & algorithm used are protected. (ie hidden)
There is no reason that you need the algorithm itself to be hidden,
only the keys need to be secured. Unless of course there is no key and
your using an unkeyed algorithm, in which case the problem is your
implementation is extremely poor.
> The case where you (Eve) can recompile the code yourself, and merely take
> data from Alice which includes the keys.
How do you "take data from Alice"? If you can take data from Alice
surely it would be easier just to take the data prior to, or after
Alice has done the encryption/decryption?
> Suppose a key is embedded in the source as a literal and this is used
> during initial handshaking with Alice and to protect keys before storage
> on disk. Furthermore, suppose that you are supplied with a precompiled
> binary. Sure you can compile your own version, but you can't use your own
> compiled version to decrypt the data.
Do you even understand what a binary is and how a compiler works?
If the key is in the source then you have all ready made a mistake.
If it is in the source and not transferred to the binary (e.g. if it's
in a comment) then you can delete it from the source with no damage to
the generated binaries. And thus the source is now secure for release.
If it is transferred to the generated binary it can just as easily be
extracted from the binary.
The attacker now has the key. They also have the binary that means
they must have the algorithm (the CPU gets the algorithm from the
binary, we know how a CPU does that, thus we can extract the same
algorithm ourselves.).
All you have showed is that no DRM scheme is secure.
Well done, we knew that all ready!!!
Andy.
--
Computers are like air conditioners. Both stop working, if you open windows.
-- Adam Heath
-
Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.
Unofficial list archive: http://www.mail-archive.com/[email protected]/
