On 12/06/07, Richard Lockwood <[EMAIL PROTECTED]> wrote:
>
> Implementation of an (insecure) DRM scheme is not difficult. If the
> BBC is willing to pay me £1 million (less than they spent on Windows
> iPlayer) I could write up a nice specification for you and then you
> would have a truly platform agnostic system.

Ah yes.  An insecure-by-design DRM scheme.

Your current implementation is insecure by design!

I am mearly being honest and admitting the system is flawed.
Should I lie and tell you it is secure?
I can use encryption that is stronger than the stuff banks use for
credit card transactions. That make you feel it's more secure?
Happy now?

 A Digital Rights Management system that doesn't actually allow
you to manage anything.

None of them do.

How can you not get such a simple concept?
THEY CAN'T WORK DUE TO THE WAY YOUR CPU WORKS!!!!!!!

A program is a sequence of instructions. Things like
- Add 10 to this value
- Save this value here
etc.

These need to be readable by the CPU, they are encoded specially. When
you put these instructions together you get what we call binaries.
This is what most DRM is shipped as.

If the CPU can read the instructions it follows that we to can read
the same instructions, fair enough.

But can we understand them? Well I said they where specially encoded.
These encodings are published. They need to be or no one would have
been able to create the encodings in the first place.

The binary needs to have the ability to decode your DRM'ed file so it
can play it for you. The problem is we can see precisely what it does
thus we can do the same things it does. We can however omit certain
things such as omitting checks against expiry times.

Short of redesigning every CPU what more do you want? Seriously?

Your claim appears to be I should produce a secure DRM system, yet you
allow Microsoft to use an insecure one?

Mine will be more secure, it's used by less people and therefore the
reason to attack it is less.


And now a quote:
compare a DRM system with a financial model that doesn't care about copying.
The former is impossible to secure, the latter easy.
From: http://www.schneier.com/essay-142.html

That's from Bruce Schneier, one of the most respected computer security experts.
Notice him saying DRM is impossible to secure.
Are you more knowledgable in this area than him and everyother security expert?
No?
Then stop asking me for "secure DRM", it ain't possible.
You accepted Microsoft's insecure DRM. What's wrong with an openly
specified insecure DRM? It's still DRM, it still locks things from
people how don't know how to crack it.


And someone said it would take a long time to build such a system. Untrue.
It is not a coincidence I mentioned many other specifications and
technologies. Yes implementing DRM (including a video and audio codec)
would take a long time. Fortunately tools already exist for this.

For a lists who "glue" together technologies why can't you seem to
grasp that DRM can be built a similar way.

Need a video codec, we have those.
Audio codec, yeh there are a few of them.
Need to encode restrictions, XML does a fine job here (infact key
value pairs would suffice).
Need to scramble the video content, we have AES (a synchronous
cryptographic algorithm).
Need to exchange a key, we have HTTP, could even use XML to attach
restrictions onto the key itself.
If we want to go ridicoulus in terms of pointless security we can do
things like signing the restrictions with a cryptographic hash to stop
someone going into the file and changing the expriray date (well
actually we can't stop them changing it, but we can detect that it
changed and refuse to play the file).

Notice I haven't mentioned which restrictions to include. That's not
difficult to do. Put the individual restriction in the XML and simple
write an if statement.

if (res.exists("ExpiryTime"))
{
   if (res.get("ExpiryTime") < now)
   {
       showMessage("Sorry but this file has expired!");
   }
}

Add an if statement for each different restriction you have.
Obviously you would check different things.

Might need to do things like adding a play counter in the XML to do
limits on when it's played.

Not more than a months work at the most.
And once the spec is released all you have to do is starting pushing
out the content someone will make you a nice player for it.

Andy


--
First they ignore you
then they laugh at you
then they fight you
then you win.
- Mohandas Gandhi

-
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/backstage@lists.bbc.co.uk/

Reply via email to