[gst-devel] Does GStreamer has a plan to support DRM (e.g.OMADRM)?

Gruenke, Matt mgruenke at Tycoint.com
Tue Oct 26 07:48:43 CEST 2010


I was referring to the general concept of having a secure path to
memory, so that the CPU + memory could be treated as a black box.
Again, depending on your requirements, this might be overkill.

I don't have specific knowledge about any systems which implement this
technique.  I was simply using it as an example of how the security
problems might be solved only at the hardware level.  This makes every
very easy, at the software level.

If you can't solve the security at the platform level, then you could go
the route of having a black box in your pipeline, in order to prevent
access to the unencrypted data.  Unfortunately, this means that you
can't use GStreamer's standard elements to do parsing and decoding.

This isn't really just a GStreamer issue, but rather an issue with any
LGPL code you might want to use for processing of your media streams.
The problem is that the license requires you to link LGPL code as a
shared library, which anyone can replace with a modified version.
Therefore, if you're concerned about platform security, then you really
need a hardware or proprietary software solution (which you can
statically link) for all your handling of the decrypted media.

So, the answer is that you cannot secure links in a GStreamer pipeline.
Anyone can replace certain GStreamer libraries with modified versions
and gain access to the data.  The only option is a black box element
that is either a sink or one that re-encrypts any data going out of it.


Matt



-----Original Message-----
From: Lin, Mengdong [mailto:mengdong.lin at intel.com] 
Sent: Wednesday, October 20, 2010 02:37
To: Discussion of the development of GStreamer
Cc: Gruenke, Matt
Subject: RE: [gst-devel] Does GStreamer has a plan to support DRM
(e.g.OMADRM)?

Could you give me more information about a " encrypted memory
interface"?

And it seems that I have to write a big DRM sink plug-in that do all the
following task: 
- detect & removing OMA DRM wrapper, -
- decryption 
- original media format parsing (mp3, AAC ...)
- decoding 
- rendering

The decryption/parsing/decode shall occur in a secure hardware. 
It means I can no longer use the open source file parser plug-ins and
there is only two plug-ins (filesrc & DRM sink)  in the pipe line :-(

Is this the only way to build a secure path in GStreamer?

Many Thanks!
Amanda

-----Original Message-----
From: Gruenke, Matt [mailto:mgruenke at Tycoint.com] 
Sent: Tuesday, October 19, 2010 12:25 PM
To: Discussion of the development of GStreamer
Subject: Re: [gst-devel] Does GStreamer has a plan to support DRM (e.g.
OMADRM)?

-----Original Message-----
From: Michael Smith [mailto:msmith at xiph.org] 
Sent: Tuesday, October 19, 2010 00:13
To: Discussion of the development of GStreamer
Subject: Re: [gst-devel] Does GStreamer has a plan to support DRM (e.g.
OMADRM)?

<snip/>

> Of course, then the output of the DRM wrapper filter is the
> unencrypted original file, so a user could trivially set up
> a pipeline like filesrc ! drmremover ! filesink, and just get
> rid of the DRM permanently. This is great for the user, but
> probably not what you actually wanted.
>
> Providing a _secure_ path for decrypt/decode/output is a much
> more complex task. You'll need to do a lot of thinking about that.

Depending on the security requirements and how accessible the platform
will be, that might be an issue.  For instance, if the platform-level
security requirement is low or the security issues have already been
solved at the platform level (e.g. an embedded process with an encrypted
memory interface), then you don't need to worry about security at the
gstreamer level.

The way this problem is usually solved is by having the decryption &
decode occur in secured hardware (like a GPU), which is either built
into the display device or uses another secured channel (e.g. HDCP) to
send the decoded output to the display device.

What this would look like, from a GStreamer perspective, is having a
different sink for the device that's doing the decryption & decoding.
Depending on how that sink works (i.e. whether or not it needs to tell
the hardware that the stream is encrypted), you might need special caps
to indicate encryption.


Matt


------------------------------------------------------------------------
------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that
run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel




More information about the gstreamer-devel mailing list