On Friday 02 November 2007 11:53, Andy wrote:
> 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.
Huh? Why I am a fool? (Not that I care about looking a fool. Being foolish is
often actually more about ignorance - which is an opportunity to learn why
you're wrong)
I pointed out that DRM in this context is based on two things:
* Using a mechanism to protect the main secret. That mechanism is usually
encryption. The main secret is usually something like a programme or
film.
* Any mechanism based on encryption has an achilles heel which is the key.
If you can find the key or you have tools that make it easier to attack
the key (source does _help_ in the DRM case) then the strength of the
encryption is irrelevant.
> > 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 didn't say you could. You can always do memory attacks and brute force
attacks (aside from anything else). I pointed this out when I mentioned that
libcss is used on Linux (and other similar systems) to attack the keys for a
DVD. What you are suggesting is that an open source solution is *more* secure
in the case of DRM. This patently isn't the case.
The exception is where you have a secure mechanism for key storage,
such as TCPA. That *can* be done. Linux Journal showed a few years back now
how to do this in the context of using the TCPA on an IBM thinkpad to
securely protect a loopback partition on Linux. (Something quite handy
really)
[1] http://www.linuxjournal.com/article/6633
Even then its debateable whether that works without a competely trustable (by
whom?) operating system on top. The TCPA chips themselves are in fact signed
as well, so knowing this you can identify if you are talking to a system with
a genuine TCPA chip or not. As a result simply emulating the hardware doesn't
work. (yes, I discussed this with experts in that field, I assumed it could
be easily faked in VMWare, or similar, but it can't)
What you *can* do though is break open the packaging of one of the chips, use
an electron microscope to scan the chip and extract the necessary information
that way. The tools needed to do that are actually pretty hard to come by to
say the least.
> 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.
Take a look at the TCPA in some detail, you'd be surprised.
> 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.
Chip and pin has been successfully attacked using a variety of approaches.
* http://www.cl.cam.ac.uk/~rja14/ is useful reading if you're curious about
some attacks
You may also wish to google for "chip and spin" if you're convinced chip &
pin is secure.
> I shall give you the gist and you can look them up (both are from
> Applied Cryptography
You mean the book damned by security researchers? (Last time I saw it publicly
damned at EuroOSCON 2 years ago)
Specifically by John Viega (then of Secure Systems Inc) in this talk:
* http://conferences.oreillynet.com/cs/eurooscon/view/e_sess/7409
ie this guy.
* http://www.viega.org/
(now Chief Security Architect at McAfee)
> An algorithm that depends on the secrecy of an algorithm is called a
> restricted algorithm.
> They are woefully inadequate in todays world.
Indeed. You have to rely on a restricted algorithm however if the user has
access to the keys. Hold on, the key is stored on the computer somewhere or
nabbed over the network. That means its easily interceptable. That means your
security DOES repend on a restricted algorithm . I'm not disputing that this
is a bad thing if you want "unbreakable" DRM.
I'm pointing out that the weak point is the keys and you've not shown
how to make it easy to hide the keys in a completely open system - where the
attacker has access to and controls the system where they are stored. You can
*try* to hide the keys in a closed system, but if you can run it with a system
call tracing facility it's easy to find the keys.
> 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.
Have you ever used a decompiler? (If you haven't, you should, it's fun :-)
I have. They're a real pain, but can as I say be fun. What you get out is
pretty hideous normally. However, yes, if you're desperate then you can do
this. Tracing through sourcecode you're unfamilar with with no real semantic
layer over the code is a real pain.
Heck, doing that for a non-insubstantial codebase in order to find out to
use it (cf libvorbis) is equally painful. (cf http://www.xiph.org/vorbis/doc/)
(As some of my colleagues will know. :-)
And that's before you're actually looking at a binary that's actually trying
to make your life hard.
(By comparison decompiled python bytecode is positively fun to work with which
is why I said a binary, not something compiled to bytecode)
> > (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!
I don't consider myself above anyone, I asked you to come back with reasoned
arguments pointing out where my reasoned arguments were wrong. You still
haven't said how you protect the key/and or algorithm in an open source
system.
You've decided to flame me instead. (quotes don't back up points. Reasoned
arguments do. After all, do you accept the paraphrasing of Viega's quote
above?)
*shrug*
> Much of your claims make no sense whatsoever.
Please enlighten me where.
> > 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.
Correct. However if I tell you the text below is encrypted (it is by the way -
base64 encoded to give you a head start on decoding it/ensure you receive it
intact :-) and that the key is "somekey!", you still have to identify the
algorithm used.
'SyT3t6WUPFGIVhak+0PdwRQKTOc2j5VHF043TMMNzuU=\n'
Simply knowing that I used an open source toolset (I did), simply knowing the
key (which I've given you), that I used a widely known algorithm (a
relatively weak one at that) doesn't help you. You still need the algorithm.
If I give you that (as I would have to in a completely open source system),
then you would realise that that to decode the above string you ... [snip]
> Unless of course there is no key and
> your using an unkeyed algorithm, in which case the problem is your
> implementation is extremely poor.
What's your example an unkeyed algorithm here? Simple replacement cipher?
> > 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?
Alice is using a DRM protected file. This gets sent to you via some mechanism:
* HTTP download
* Torrent distribution
* File distribution.
* etc
You take that data file that Alice supplies and then just decrypt, since you
know how and where the keys are stored.
> > 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?
Yes, I've written compilers.
I've also contributed back patches to the python project regarding the
decorator syntax debacle. You can find that patch here:
* http://bugs.python.org/issue1013835
You'll note its not insubstantial.
You can also find a generic language parser I've written here (intended as a
replacement for s-expressions, but never bothered taking further):
* http://cerenity.org/SWP/
(Was written entirely for fun, but parses some pretty wacky stuff)
The lightning talk I gave on that at euro python (and also the ACCU) a few
years back can be found here:
* http://www.slideshare.net/kamaelian/swp-a-generic-language-parser
I've created special languages for pre-compiling the context sensitive
grammars of a wiki into a context free grammar. (The reason is you reduce the
number of passes through the text when parsing for display. A context free
grammar can often be parsed in a single pass (especially well known ones like
LALR(1) and LL(1) grammars). Thus you gain a fairly dramatic speed boost for
complex wiki systems which have over a 1000 grammar context sensitive rules.
I've even worked on a compiler for compiling to silicon. (ie from a language
description to hardware) That kinda did my head in for a while, but was
rather influential on Kamaelia which in some (conceptual) respects directly
stems from working on that compiler.
So, yes, I know how a compiler works and what a binary is.
> If the key is in the source then you have all ready made a mistake.
If the key is not in the source that means its attackable on the system. If
you have access to the source, that means you can find the key.
Hiding the key in the binary is one place that's actually quite hard to search
*if* you can't do a correlation attack. (A memory based attack is simpler
then) You can then use that key to protect the others. That's where Media-S
goes wrong.
> 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.
The source tells you where the key is on the system. For example, if you read
the Media-S code you pointed at and the associated docs you have a concrete
example of this. (If you have done, my apologies, please point out the
mistake I've made here - to me it looks trivial to extract the keys) They try
to encrypt the keys on the system, but you can see how they're doing that
meaning you can work around it. (eg rename eth0)
> All you have showed is that no DRM scheme is secure.
> Well done, we knew that all ready!!!
:-)
I never claimed they were secure. I was noting that your point of a completely
open source DRM system being more secure than a closed one was bogus.
That said, they are secure from the perspective they do tend to *reduce*
casual copying since many people do not have the skills to remove the
DRM wrapper. Economically the value of any library is in the tail of the
zipf distribution. If you take that into account, you get some interesting
points.
In the head of the zipf distribution, if you can prevent copying that's where
you have real value due to sheer numbers. (eg through copying
being hard - eg 40 years ago) However, if copying is doable but hard then the
more people you have interested in something, the more likely it is for that
content to have the DRM removed. That reduces the potential value of the item
to next to zero due to the sheer numbers of people interested in attacking
the DRM.
However, all things being equal the real value is in the tail. The further you
get away from the head, the less likely you are to find someone who can
remove the DRM.
That means items in the tail are more likely to retain value in a world with
DRM. What does that mean? It means that economically the stuff in the head
becomes the advert for the stuff in the tail, but the real value is in the
tail, and that's where DRM is more effective because there's less people to
remove it.
Since you've decided to largely flame rather than answer the point I was
raising which was "how can a completely open source DRM system be as
effective as a closed or partially closed DRM system" I see little value in
responding if flamed further.
Bear in mind I'm a strong advocate for open source, aside from anything else
being on the organising committee for Pycon UK, on the advisory board of the
National Open Centre, recently chaired an FLOSS workshop at the EBU,
have given (approved!) talks about open source at the BBC at a variety of
conferences, and written many thousands of lines of code released into the
wild and run large scale services using open source.
However - unlike some I've never seen the need to impose my morals on
another [2] - I'm a pragmatist. You're making a claim for open source that
I'd personally never make and if its valid I want to understand what I'm
missing. If I'm genuinely wrong, I'm genuinely interested, but I'm
interested in reasoned response. I hope my response to you has been
respectful. If it hasn't, my apologies in advance.
[2] I don't mean you here, I'm sure you can think of some people who do
At the end of the day BTW, don't particularly like DRM and even own a CD I
can't play on my laptop (which runs linux) as a result. (Didn't realise when
I bought it and figured I'd only listen to it on the hifi anyway) However, at
present it is a reality we all have to deal with simply because the economics
of the business world adapts far slower than technology. Now I really should
be doing something else and was just writing this quickly to give my mind a
break from code.
Regards,
Michael
-
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]/
