Wayland content-protection extension

[Pekka Paalanen]

On Mon, 18 Jun 2018 15:56:40 +0530
Ramalingam C <ramalingam.c at intel.com> wrote:

> On Monday 18 June 2018 03:52 PM, Pekka Paalanen wrote:
> > On Mon, 18 Jun 2018 14:32:32 +0530
> > Ramalingam C <ramalingam.c at intel.com> wrote:
> >  
> >> On Monday 18 June 2018 02:23 PM, Pekka Paalanen wrote:  
> >>> On Mon, 18 Jun 2018 13:38:09 +0530
> >>> Ramalingam C <ramalingam.c at intel.com> wrote:
> >>>     
> >>>> On Monday 18 June 2018 01:34 PM, Pekka Paalanen wrote:  
> >>>>> On Sat, 16 Jun 2018 12:50:52 +0530
> >>>>> Ramalingam C <ramalingam.c at intel.com> wrote:
> >>>>> The SRM table smells very much like compositor configuration,
> >>>>> especially because a) it is global state: you cannot program two
> >>>>> different tables to the same connector, and b) the compositor is
> >>>>> required to save it and use it later for all clients(?). One can also
> >>>>> envision a security issue, if a system allows third party apps: an app
> >>>>> could install a fake SRM table with a fake date.  
> >>>> Compositor is expected to store the latest SRM in the non-volatile and
> >>>> update with only newest versions.
> >>>> And it will supply the latest version to kernel(irrespective of what
> >>>> version is provided by app). This caching is not per connector.
> >>>> SRM table itself provides the version of it. and The validity of an SRM
> >>>> is established by verifying the integrity of its
> >>>> signature with the Digital Content Protection LLC public key, which is
> >>>> specified by the Digital
> >>>> Content Protection LLC. So no fake SRM will be accepted.  
> >>> Right, so I would propose to make that completely separate.  
> >> Ok. So how that should be implemented? As another protocol extension?  
> > I don't know. Is there a reason to do it by Wayland?  
> Yes. As we need to supply the SRM table through drm connector properties 
> to each ports HDCP authentication.
> At the least we need to receive the signature validated latest SRM from 
> client and program into drm connector property.
> Means storing SRM could be kept within the wayland client but only 
> drm_master can set the blob for the connectors.
> 
> And AFAIK signature verification also a crypto calculation with DCP LLC 
> public Key.

But nothing there requires the use of Wayland for it. Sure, the
compositor will have to program the SRM table via KMS, but it doesn't
mean the compositor needs to get it by Wayland.

The compositor does not care which process provides a SRM table,
because:
- the SRM table is global and cross-vendor
- the SRM table is signed, so no fakes can be provided
- the SRM table is versioned/dated, so always the most recent will be
  in use, regardless of which version a client might propose
- clients are happy to use a SRM table that is more recent than what
  they have themselves

Did I misunderstand something?

Let me put it in another way: we don't need to standardise a Wayland
interface, it could be DBus or something else since there is no
connection to window management.

I'm also concerned about the maintenance of an authenticated SRM table.
Would we have Weston link to a new library to validate signatures? How
does Weston load a guaranteed good DCP public key? Where will Weston
store and load the SRM tables?

I would assume the SRM table support to be both uninteresting to
upstream in general, and possibly quite specific to the system where
weston is running. Therefore, I would propose the following:

Have the SRM table verification, maintenance, and IPC in an external
Weston plugin. In upstream Weston, only add an API through the
plugin-registry to set up an already validated, single SRM table for
all connectors that support it. In other words:

int
set_srm_table(something);

libweston makes an internal copy of the data and programs the same data
to any connector that gets HDCP enabled, or it will fail to enable HDCP
at all for the connector. Calling set_srm_table() again will
unconditionally overwrite the earlier data.

This way upstream does not need to design for a use case they have no
idea about, a vendor can implement the SRM table management any way
they want, and once there is an actual working implementation suitable
for serious use, we can have a look at what it involves and whether it
would be suitable for Weston upstream.

I actually doubt whether vendors would even want the SRM table
management code open sourced.

For testing the API, we would probably need a dummy SRM table plugin,
which just feeds in a hardcoded table or from a file, without any
authentication or runtime updates, or even better, allows the user to
set the list of revoked devices so one can easily test revoking ones
own HDCP display.

How's that?


Btw. I would like to see (lib)Weston used in media devices and for that
at least IMHO I would be ready to take related features into upstream
Weston, so in general I would be quite positive about new features like
this. It just needs to happen at upstream terms.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180629/f04770f9/attachment.sig>