Re: Video streaming DRM



On 19/10/2010 16:18, Noob wrote:
I'm adding video streaming to a digital television receiver.

The CA operator (wanting to please content owners) suggests
that we implement something called DTCP-IP, a DRM system
created by Intel et al.

http://en.wikipedia.org/wiki/Digital_Transmission_Content_Protection
http://www.intel.com/technology/itj/2002/volume06issue04/art05_protection/vol6iss4_art05.pdf


In my opinion, DTCP's main feature is what Intel shyly calls
"renewability" which is described thus:

"Renewability is used to extend the viability of a content protection
solution. This is accomplished through a variety of mechanisms
including updating a Digital Rights Management (DRM) system via
online mechanisms and/or utilizing revocation. Either technique
ensures a system’s integrity is preserved in the event that a
licensed product’s authentication and/or encryption-related secrets
are compromised and distributed. When such a compromise is detected
and verified, the licensor of the content protection solution
(through a process described below) may request an update or
revocation of the compromised information. Revocable information
should be assigned as finely as possible, ideally with each licensed
product receiving unique information, thereby localizing the effect
of the revocation as narrowly as possible."

I'm not too fond of revocation. Not only would I have to spend time,
RAM, and NVRAM implementing it, it can be used to disable working
devices arbitrarily at some point in the future.

So I'm looking to roll my own proprietary (as in no interoperability
required) crypto, which would only need to be "good enough".

Here is my (rough) idea:

Have a 64-bit secret key shared by every device.
The client provides a 64-bit nonce in its streaming request to the server.

The AES key used to encrypt the video would be something like
PBKDF2(secret, nonce, 1000)
which both the client and server can compute.

The AES key is then used to encrypt the stream in ECB mode.

What are the glaring mistakes?


0) "Roll my own"; this is a complex domain where expertise in
the field helps.

1) Not stating your threat model and constraints precisely.

2) This is not adequate if the streaming to the digital television
receivers is one way or multicast (satellite is usually both),
since the nounce must be sent from client to server, and you
need one different encrypted data flow for each viewer.

3) No mean is described to blacklist a subscriber not paying
the bill.

4) As described, it is enough to capture a single pair of matching
nonce and PBKDF2(secret, nonce, 1000) to be able to request and
view any number of streams. Thus the whole use of secret and
PBKDF2 is pointless unless something not described is added.

5) After the obvious 3/4 is fixed, the shared key will become
a weak spot of the system, especially if you do not have it and
PBKDF2 in a secure device. At the very least, you want to have
a hopefully secure way to change that key when it gets
compromised.

6) If PBKDF2(..) and the encrypted stream can be sent to a fake
device, you're in trouble. A well known SAT TV fraud is based on
that, with one subscriber for a whole building/group of people.

7) Same thing if a fake device gets nounce and PBKDF2() from a
real device, and then pretends to be a genuine device that
generated that nounce, and gets its own stream from the server
(that's a variant of 4)

8) CTR mode has the advantage over ECB that the bulk of the work
can be performed without the data flow itself, including in
advance; this can improve latency of the decoder, allow evening
of processor load, and save a factor of 2 in the data bandwidth
between an hypothetical crypto device doing the AES + CTR
increment, and the decoder itself. On the other hand, ECB
survives loss of packets (multiple of 128 bit), CTR does not;
and the reduction of bandwidth by a factor of 2 can apply to
the fraudster in some scenarios. [ECB has small weaknesses (e.g.
a stream of constant ciphertext reveals constant plaintext) but
that is not much of an issue in the context]

9) While 64 bit for the global secret is unlikely to be a weak
spot thanks to additional security supplied by PBKDF2, there
seems to be no good reason to go for less than 128 bits. This
may increase the perceived security of the system which in most
case only helps.


Francois Grieu
.



Relevant Pages

  • Re: Help needed for usecase: encrypt 40 bit to 40 bit without IV
    ... I am running into a use case where I will have to encrypt 40bit to ... Since there is no space to store any meta information, ... consider using a stream cipher. ... and brute force attacks become a serious threat. ...
    (sci.crypt)
  • Re: FlushFinalBlock method was called twice on a CryptoStream ERROR MESSAGE
    ... and only requires the one CryptoStream object (one for encrypt and one for ... What I meant before is each 32 bytes string ... > TransformBlock to encrypt but haven't had much success unencrypting on the ... >> of the streamReader/writer to save another stream indirection. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Simple file encryption decryption problem in C#
    ... I've created an encrypt and decrypt function, ... The functions work if I send in FileStreams. ... If I send in a MemoryStream to it then write the stream to the ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: HDTV Connection
    ... |> But what if a plain 8VSB demodulator ... This would make the whole technology of 8VSB unusable for data transmission ... | device is free to encrypt in any way it wants. ... I wouldn't attempt to crack it by decrypting the stream it encrypts. ...
    (alt.tv.tech.hdtv)
  • Re: Rijndael Decryption not working
    ... Stream streamToConvert = ConvertStringIntoStream; ... CryptoStream kbsCryptoStream = new CryptoStream(streamToConvert, ... I can encrypt without any problem but while decrypting I got junk. ... Rijndael rijndaelAlgorithm = Rijndael.Create; ...
    (microsoft.public.dotnet.languages.csharp)