Technical FAQ
Specifications and Documentation
Import and Export
Nodes and Links
Content and Licenses
Broadband Specification
Content Sharing
Certificate Policies
Trust Model
Specifications and Documentation
| Does the Marlin specifications bundle contain the complete set of available specifications? |
| Please describe some of the main Marlin specifications |
Here is a brief description of some of them:
- Marlin Core System Specification—Defines the basic components and protocols that form the basis of most Marlin implementations.
- Marlin Broadband Delivery System Specification—Defines additional capabilities that are unique to clients that can take advantage of an interactive IP-based communications channel. Among other items, includes protocols for obtaining licenses and reporting usage data for subscription-based services.
- OMArlin Specification—Specifies how to enable interoperable download, streaming, sharing and consumption of content between OMA and Marlin DRM systems.
- Marlin IPTV End-point Service Specification—Defines support for “end point” devices, such as TVs with IP capabilities.
| Is other documentation available? |
Yes, a lot of documentation is available. For example, there are several white papers:
- Marlin Architecture Overview. Provides an introductory-level overview of the Marlin DRM architecture and its application to common implementation use cases.
- Marlin Broadband Architecture Overview. Provides an overview of the architecture for a complete Marlin DRM system that includes utilization of Marlin Broadband protocols. It describes the key components of such a system, their responsibilities, and how they interact. It also discusses example components that have been implemented and that are expected to be commonly used: the Marlin Client SDK (Sushi) and the Marlin Broadband Server (BlueWhale).
- The Role of Octopus in Marlin and The Role of NEMO in Marlin. These papers provide overviews of two platform technologies utilized in most Marlin DRM implementations to support flexible consumer usage scenarios and business models.
- Refusal, Remediation and Renewability in Marlin. This paper describes the rich set of security mechanisms Marlin provides to mitigate threats that arise from attacks and compromised devices, applications and services. It also describes circumstances in which it is appropriate to apply a given countermeasure, and the complementary renewal mechanisms for informing systems of the failed entity and for remediation of the ostracized entity.
Additional components documented include the following:
- The Marlin Client SDK (Sushi) API and its example programs
- The Marlin Broadband Server (BlueWhale)
- The Fishnet Conformance Test Tool
- See the Marlin Developer Community download pages for additional documentation information.
| What are your recommendations for initial navigation of the specifications and documentation? |
- Marlin Architecture Overview white paper.
- Marlin Broadband Architecture Overview white paper.
- The Role of Octopus in Marlin white paper.
- The Role of NEMO in Marlin white paper.
- Octopus Objects Specification.
- Chapter 3 of the Marlin Core System Specification. This documents Marlin DRM objects, which are Octopus objects with Marlin-specific attributes, extensions, and encodings.
- Scuba Key Distribution Specification.
- Marlin Broadband Delivery System Specification. This ties all concepts together. It specifies additional protocols and usage rules above and beyond the Core specification.
Import and Export
| Can Marlin export content to other technologies? |
| Does Marlin provide some mechanism to implement protection of the transmission link between devices? How does that relate to Marlin export? |
In Marlin, export and transmission link protection are treated the same. For example, DTCP is a link protection technology, whereas MG-R is a content protection technology. They are very different, but a Marlin License can grant the right to export to either of them. Section 11 of the “Core” specification enumerates the various technologies that all Core Marlin implementations should be able to export to:
| If content is already protected by non-Marlin technology, will it still work on Marlin-compliant devices? |
| What about the legacy problem? |
| If content is protected using DRM X, will it play on Marlin devices? |
| What are the media file formats used within Marlin? |
Nodes and Links
| What is a Node? |
Both Octopus and NEMO use the term Node to represent attributes of system entities. Therefore, whenever Nodes are described, it is critical to qualify whether the Node is a NEMO Node or an Octopus Node. Note: Whenever the term “Node” is used by itself in this FAQ, it refers to an Octopus Node.
NEMO Nodes are used to encapsulate security properties of communications endpoints. NEMO Nodes are active, in contrast to Octopus Nodes, which are passive. A NEMO Node is an object analogous to the trusted “host” of a particular functional component. The NEMO Node acts as a trusted entity with which other components can send and receive authenticated messages. For example, a License Service would use its NEMO Node credentials to send and receive messages between it and another NEMO Node representing a Marlin Client.
Octopus Nodes are an abstraction used to represent
system entities. Octopus Nodes are encoded in XML and encapsulate
attributes about themselves, such as secrets and type
information.
| What do the different Octopus Node types represent?> |
In Marlin, Octopus Nodes representing logical
entities or “principals” within the system are
defined. For example, Personality Nodes represent devices, User
Nodes represent users, and Subscription Nodes represent
subscriptions.
| What is a Link? |
Links are self-protected Octopus objects that represent relationships between devices, users, and subscriptions, forming a directed graph, an example of which is shown in the following figure.
In the figure, Nodes are illustrated as
circles, and Links between Nodes are shown as arrows. The actual
semantic of a Link is a function of the business model the Link
issuer is enabling. For example, for many issuers, the presence
of a Link (or arrow) between two Nodes may indicate that there is
a relationship between the two Nodes, and this relationship may
be described as representing that a particular Node
“belongs to” or “is a member of” the Node
that the arrow is pointing to. Using this interpretation, the set
of Nodes and Links in the figure indicates that Device A
“belongs to” user “Bob Smith”, and that
Bob Smith “subscribes to” the “Video”
subscription service. Similarly, Devices B and C “belong
to” both “Bob Smith” and “Carol
Smith”.
| What is the graph of Nodes and Links used for? |
This system of Nodes and Links is integral to
managing where, how, and when content can be used in a Marlin
system. When a License is created, the control program within it
will typically include a requirement that a certain Node, such as
a User Node (e.g., one representing “Bob Smith”) be
reachable by the device attempting to access the content. Being
reachable means that the Marlin Client running on the device in
question contains a valid set of Links from the Personality Node
representing the device to the specified Node. This can be a
direct Link from the Personality Node to the specified Node (such
as from Device A to user “Bob Smith” in the figure
above) or a series of Links (such as from Device B to “Bob
Smith” to “Video”). This process of indicating
in the License’s control program that a particular Node
must be reachable is referred to as targeting to that Node.
| What is Scuba? |
Scuba is a key distribution mechanism that works
in concert with Octopus’ graph-based object model. Scuba
takes advantage of the Link objects representing relationships. A
Link contains the private key or symmetric secret key belonging
to the destination Node (the “to” Node). The key is
encrypted using the public key of the source Node (the
“from” Node). The encrypted key can only be decrypted
using the private key of the source Node. Consider the following
example: If a device is registered to a user, the device
Personality Node is linked to the User Node. Only that
Personality Node’s private key can be used to decrypt the
User Node key contained in the Link. That fact enables the device
to access content that is encrypted using a content key which is
itself encrypted with the User Node’s public or secret key,
as illustrated in this question.
| Are the NEMO and Octopus Nodes cryptographically bound together and, if so, how is this done? |
Not usually. Octopus Personality Nodes and User
Nodes are both passive. There is one important difference:
Personality Nodes are owned by, managed by, and permanently
associated with a physical device, which also has NEMO keys. User
Nodes may be owned and managed by different entities in the
system. Typically, a User Node is owned and managed by the
service provider/rights issuer which created and manages the
“user account.” A User Node is not permanently
associated with a physical entity with NEMO keys, etc.
A NEMO Node assigned the role of a DRM Client may temporarily bind to an Octopus Personality Node. This binding may occur during certain protocol interactions. For example, during the DRM Client Information protocol exchange described in Section 5.7.2 of Marlin Core, the NEMO Node signs the response, to bind itself to the Octopus Personality Node it is acting on behalf of.
A loose (temporary) binding is the only one ever needed. In
all cases, the “public” part of an Octopus Node (a
User Node or a Personality Node) can be freely exchanged in the
system, as it is essentially a signed attribute bundle. Octopus
Nodes are “owned and managed” by entities (devices,
account managers, etc.). The “private” part of an
Octopus Node (e.g., the Scuba private keys) is under control of
the entity that owns or manages the Node. These secrets only
travel in the system via Links issued by this managing
entity.
| Who creates User Nodes and Links? |
User Nodes and Links can be acquired via a
number of protocol interactions with entities authorized to issue
such objects. User Nodes and Links must be signed. They can only
be issued by entities that have signed certificates containing
appropriate policy terms. A User Node must be signed by a key
whose certificate has the
“id-cp-octopus-marlin-signing-node” policy term, and
a Link must be signed by a key whose certificate has the
“id-cp-octopus-marlin-signing-link” policy term.
Examples of entities that are authorized to issue User Nodes and
Links are DRM Object Providers and the Marlin Broadband
Registration Service.
Note: A signed Link object includes the unique identifiers of
the Nodes that it links.
| Is it only NEMO Nodes that can, and have to, authenticate themselves? |
Yes. Octopus Nodes are passive entities, so
authentication does not apply to them. (However, please note that
an Octopus Node is signed, so an entity receiving it can verify
its authenticity.)
| How are Nodes and Links stored? |
Marlin relies upon Octopus’ XML
serialization/deserialization feature for the encoding and
decoding of Octopus objects. Because the objects are
self-protected, an implementation has a large degree of latitude
in how it manages the serialized objects.
| How big are Node and Link and related objects? |
Each object has different size characteristics.
For example, Link and Node objects generally include
cryptographic secrets or certified keys. The size of public key
certificates will vary depending on whether the certificate chain
is included, and the size of the key itself. Control programs are
very compact, but also vary based on the amount of logic they
implement.
XML-encoded objects are generally large. However, an
implementation is free to deploy space-saving strategies, such as
compression, to conserve space if needed. Once Octopus objects
have been de-serialized, they are very compact.
Content and Licenses
| How is access to Marlin content controlled? |
Via Licenses and Links, as described in the
following.
| What is a License? |
A (Marlin) License is an XML document containing
a set of Octopus objects that govern the use of content and
convey the conditions necessary for allowing access to the
content key, which is the key used to encrypt the content.
At a minimum, a License will include at least one of each of the following objects:
A License contains one or more content keys
(at least one per stream of data that is protected), one or more
Control objects that express the usage rules (multiple streams
can share the same control), and some linking information, such
as a Controller object indicating which Control applies to which
content key, and a Protector object indicating which stream is
encrypted with which content key. The Content object in a License
is simply a reference to the content, which can either be in a
separate file or grouped together in the same file as the
License.
| A License can be separate from the content it applies to? |
Yes. Since content is encrypted, it can be distributed separately from the License that governs its usage and enables its decryption. The Marlin specifications do not say anything about whether content and its corresponding License should travel together. They can either be a unit or be obtained separately. Combining the content and the License into a single file may be commonly done, for management convenience and efficiency. For example, if the content is transferred from one device to another, and the License is in the same file, then the second device does not have to do a License acquisition. If the content and the License are not in the same file, the second device has to acquire the License in order to be able to render the content.
| How is the content key in the License protected? |
It is encrypted using a key of the entity that
the content is considered to be bound to. For example, if the
content is considered bound to a particular User Node, the
content key is encrypted using either the public key or the
(symmetric) secret key for that User Node.
| When would the content key be encrypted with the secret key, as opposed to the public key? |
The most flexible approach, and one that is
always possible, is for the content key to be encrypted using the
public key of the Node to which the content should be bound. This
is always possible because the public parts of Nodes can be
freely distributed. When the content key is encrypted using the
public key, any Links to the Node to which the content is bound
include the corresponding private key so that the private key can
be used to decrypt the content key. Such Links are protected by
encrypting them with the public key of the origin Node.
If the License Service creating a License has access to the
private portion of the Node, which includes the secret key, the
License Service can encrypt the content key with the secret key
instead of the public key. One reason this might be done is to
save on client License processing time, since secret key
cryptography is faster than public key cryptography. In this
case, Links to the Node to which the License is bound must
contain the secret key rather than the private key.
| How does a License specify who can access the content? |
The Plankton byte code of a control program in
the Control object in the License specifies the usage rules. This
frequently includes, for example, a requirement that one or more
particular Octopus Nodes be reachable (via Links) by the device
attempting to play the content. The License is said to be
targeted to those Nodes.
| What is the difference between targeting a License to a Node and binding a License to a Node? |
Targeting and binding represent two different,
yet closely related processes. In Marlin, binding is primarily a
cryptographic process, concerned with protecting the content key,
the key that was used to encrypt the content. When a License is
“bound” to a User Node, for example, it means that
the content key is encrypted with the public key (or secret key)
associated with the User Node. Therefore, only devices that have
access to the private (or secret) key of that User Node will have
the necessary key to decrypt the content. (Any device having a
Link or chain of Links between its Personality Node and the User
Node has such access.) Note, however, that simply having the
correct key only indicates that the device has the capability to
decrypt the content—if it is permitted to do so.
Whether or not a device is permitted to access the content is
determined by the control program in the License, and
specifically, how the License is targeted. Within the control
program, the service provider will typically specify that a
particular Node or Nodes—referred to as the target
Node(s)—must be reachable via a Link or chain of Links from
the device attempting to play the content to the target
Node(s).
| Why might multiple Nodes be required to be reachable? |
In some instances, for example, a service provider may wish to indicate that not only a particular User Node must be reachable, but also a Subscription Node. In other words, the device must not only possess a valid Link (or path of Links) to the User Node, but must also possess a path of Links to a particular Subscription Node, including a valid (e.g., unexpired) Link from a User Node to that Subscription Node.
| Is it possible for a License to be targeted to one Node, but bound to another? |
Yes. Although frequently a License will be both
bound and targeted to the same Node, it is possible for a License
to be bound to a different Node than the one to which it is
targeted. For example, sometimes Licenses that are targeted to a
Subscription Node are bound to a User Node. That is, the control
program in the License requires that the Subscription Node be
reachable, and a key of the User Node is used to encrypt the
content key.
Actually, in this scenario where a License is targeted to a
Subscription Node and bound to a User Node, it is recommended
that the License be targeted to that User Node in addition to the
Subscription Node. This ensures that the necessary Link(s) are
available to decrypt the content key in the License.
| How do you know which content a License applies to? |
The License indicates which content it applies
to by specifying the Content ID(s). A piece of content (either
the entire content or each of the streams in it) contains a
globally unique ID. It also contains the content data (e.g.,
audio or video data streams), which is encrypted using the
content key stored in the License.
| Is there a way of ensuring that an entity publishing content is not rogue? |
Yes, by verifying the signature on the License
objects.
Top
| Is ownership (or rights) for a given content item represented by a Link from a User Node to the content item? |
No. This semantic is represented by the Control
object that is a component of a License. The Control object has
byte code (the control program) within it which tests for the
reachability of the target Node. The result of this test is a
function of whether there is a valid path from the Personality
Node (of the device attempting to play the content) to the target
Node.
| If I’m a publisher and want to integrate Marlin into my system, what do I need to do in the absence of a rights language? |
First, Marlin does not preclude the use of a rights language. A possibility is to choose an existing rights language (ex: ODRL), and compile it to Plankton byte code. A content publisher needs to be able to describe the set of actions that can be performed on a given content item.
If a publisher chooses to use a rights language, then a translation process, from the rights language to Plankton byte code, must result in stipulating the reachability conditions under which the action is permitted. For example, the PLAY action may be constrained by the ability to reach a particular Node (which may represent a user).
Another approach that a publisher can use is to populate a well-defined template. Once populated, the template can be run through a Plankton assembler that will generate the byte code. The byte code is then packaged within an Octopus Control object.
| Why does Marlin approach rights expression the way it does, rather than by using a declarative language Rights Expression Language (REL) like ODRL or XRML? |
The byte code engine at the heart of Marlin makes it easily extensible. Marlin can respond to new architectures, business models, and distribution models by organically building new profiles. The byte code itself is compact and easily extensible, thereby future-proofing the specification. The byte code is also easier for small devices to process than an XML REL expression.
| What is the result of executing the Plankton byte code? |
The result of running the Plankton code is a
data structure that indicates whether the requested action is
granted or denied, along with optional parameters that can
indicate further obligations, etc. The code may use the
information from the Octopus Node/Link graph, but typically also
uses other data (such as time, or stored state) to make that
decision.
| Can a License Service provided by one service provider issue Licenses bound and targeted to a user that is registered with a different service provider? |
A service provider can opt to issue Licenses to
another provider’s users, if the other provider provisions
its Octopus Nodes with a public Scuba key (and not just a
symmetric Scuba secret key). The License Service can encrypt the
content key with a Node’s public key and thus bind the
License to the specified Node.
| What does a device need in order to be able to play a particular piece of content? |
All of the following are required:
- A License for the content, which may or may not be embedded within the content file itself.
- The private or secret key of the Node to which the License is bound, so that the key can be used to decrypt the key with which the content was encrypted. (The content key in the License was encrypted with the public or secret key of the specified Node, so it must be decrypted using the private or secret key.) The private or secret key, as appropriate, is available in a Link to the Node to which the License is bound. Thus, the device can obtain the private (or secret) key if it contains a path of Octopus Links from the device to the Node to which the License is bound.
- Satisfaction of all the usage rules
specified in the control program in the License. Typically,
those usage rules include a requirement that a particular Node
be reachable from the device via a path of valid Links from the
device’s Personality Node to the target Node (the Node
that must be reachable). Validity is determined by a
combination of verification of the Link signature and execution
of any controls carried in the Link. The verification of the
signature over a Link includes checking whether the signing
certificate adheres to the
“id-cp-octopus-marlin-signing-link” certificate
policy. If the Link contains a control program, said control
must be executed to determine validity as well.
50.
| Please give an example explaining exactly how a device gets access to the content. |
Suppose that a License is targeted and bound to Peter’s User Node. A device could play the content that the License references if the device contains a Link between itself (its Octopus Personality Node) and Peter’s User Node, as described in the following.
Let
Pu = public key of Peter’s User Node
Vu = private key of Peter’s User Node
Pd = public key of the device’s Personality Node
Vd = private key of the device’s Personality Node
Ck = content key
E(k, m) = Encrypt m using key k
D(k, n) = Decrypt n using key k
Suppose the License carries
R = E(Pu, Ck)
that is, the result of using Peter’s (User Node’s)
public key to encrypt the content key.
The Link carries
N = E(Pd, Vu)
that is, the result of using the device’s public key to
encrypt Peter’s User Node’s private key.
With the above elements, the device would use the Link and its private key, Vd, to recover the private key of Peter, Vu. Then the device would recover the content key, Ck, using Vu. These steps are depicted by the following:
D(Vd, N) = Vu
D(Vu, R) = Ck
Once the device has the content key Ck, it can use that key to
decrypt the content.
| Does the target User Node need to be physically present on the device? |
No. As you can see from the previous example, the device does not need the User Node, but it does need the private (or, in some cases, secret) key of the User Node, which is distributed to it in a Link.
| Is there a Marlin policy that ensures that a Link can only be created by the owner of the destination Node? |
There is no policy per se enforcing or suggesting that the creator of a Link be the issuer (creator) of the target Node. It is essentially a best practice, and in the case where a Scuba secret key is carried in the Link, then the Link issuer will need knowledge of the private part of the Link destination Node. Typically, only the Node creator would have such information.
Broadband Specification
| What is registration? |
Registration in Marlin involves grouping devices so that they can share access to content. Currently in Marlin Broadband, for example, a device is registered with a user, and the collection of devices registered with a user is called a domain. More specifically, when a device is registered with a user, a Link is generated between the device’s Personality Node and the user’s User Node. (Note: Devices could be linked to other types of Nodes in the future.) A device may be registered with multiple users, and multiple devices may be registered with any given user. Many Licenses contain a requirement that a particular Node, often a User Node, must be reachable by a device attempting to render content. This condition is satisfied if the device contains a Link or chain of Links to that Node.
| What is deregistration, and why is it needed? |
Deregistration removes a particular device
from a domain (group of devices) with which it was grouped when
it was registered. The purpose of deregistration is to support
models where the number of registered devices or applications is
limited. When the maximum number is reached, a user can
deregister some devices (for example devices that are lost, no
longer in use, etc.) in order to be able to register new ones.
When a device is deregistered, the Link established during
registration (e.g., a Link from a Personality Node to a User
Node) is invalidated. This prevents the device from using that
Link to access content whose License specifies that that
particular User Node must be reachable from the device.
| What service is responsible for registration and deregistration? |
In Marlin Broadband, the Registration Service is responsible for various operations, including registration and deregistration. More specifically, a Registration Service is responsible for
- Issuance of Nodes (e.g., User Nodes and Subscription Nodes)
- Issuance of Links, e.g., from a Personality Node to a User Node (in other words, registration) or from a User Node to a Subscription Node
- Deregistration
| Does a Registration Service return the User Node? |
The User Node does not necessarily need to be
distributed in order to govern the content usage; only the Link
is needed for that. However, the User Node may be needed by the
Marlin Client for other purposes, for example, in License
acquisition requests, which require an Octopus Node to be
supplied. Normally, the registration process will include two
requests: one to acquire the User Node and the other to acquire a
Link from the device Personality Node to the User Node. In
response, the Marlin Broadband Registration Service returns,
respectively, the public portion of the User Node and the
requested Link. The User Node can subsequently be used to
subscribe to a catalog of content, by acquiring a Link between
the User Node and a Subscription Node. In addition, a User Node
must be passed to a License Service in order to acquire a License
bound to that Node.
| What is metering? |
Metering is the reporting of usage data to
the backend service. It was orginally designed to allow a service
not to have to pay royalites on each piece of content downloaded
by the consumer, but rather to only pay royalties on the actual
content consumption. It can also enable business models where the
service charges the consumer retroactively for usage. The
consumer may pay per play or per use of a snippet, such as some
pages of an encyclopedia.
| What is a subscription, and how does subscription work in the Octopus graph topology? |
A subscription allows time-limited access to a
catalog of content, such as all episodes of a particular
television series or all issues of a particular online magazine.
A subscription is represented as a Link between a User Node and a
Subscription Node. The Link has a specified expiration. For
example, it may
only be valid for 30 days. After a Link has expired, it can no
longer be used to provide access to the content subscribed
to.
| The Data Certification Service in the Broadband spec seems to be one example of providing certifiable secure time stamps, metering, etc. Are these elements architecturally critical? |
Yes, the data certification mechanisms are one
of the renewability techniques designed into Marlin.
| What about offline use of eBooks? Can you only read eBooks when connected? |
No. Offline business models are at the heart of
the Marlin technology. Marlin enables several approaches for
this. In a subscription model, it is possible to provide for
grace periods in the License constraints. Also, if the business
model dictates, metering data can be collected and reported the
next time the device is online.
A License issuer may choose to craft the License to take the data
certification status into consideration. In so doing, it is
important to balance the user experience with the License
requirements.
Content Sharing
| What kinds of content sharing does Marlin allow? |
Unlike many other DRM systems, Marlin
- gives users the freedom to exchange and transfer content directly between any two devices that they own (without the need to synchronize licenses)
- allows multiple family members to share their devices and content
- allows temporary use of an individual’s content on “guest” devices (those owned by other individuals)
Marlin’s unique architecture permits this degree of user flexibility while still protecting content owners’ interests and guarding against widespread copyright abuse and piracy.
| How can Peter play his content on multiple devices? |
He can register each of his devices (see
this question), so that each device contains a
Link (or path of Links) from it to his User Node. That enables
each device to access any content whose License is targeted and
bound to his User Node.
| How can a family or other group, play all content obtained by any group member on any devices owned by the members? |
Currently, in Marlin Broadband, devices are registered directly with users. If each member of the family has their own user account and thus their own User Node, then in order for all the family members to be able to play content belonging to any of them, each device must be registered multiple times, once per family member. As a result of these registrations, each device obtains Links from its Personality Node to all the family members’ User Nodes, as illustrated in the following figure.
If, on the other hand, all the family members share an account (and thus a single User Node), then the family devices only need to be linked to that User Node in order for any content purchased through that account to be able to be played on the family devices, as illustrated in the following figure.
| How are Marlin Licenses, Nodes and other objects moved between devices in a domain? |
License objects are delivered in License bundles
(collections of objects) that are either embedded into the
content in structured container formats (such as MP4), or
transported as standalone Licenses (e.g., sent from a License
Server).
Since content is protected by encrypting it with the content
key that is in the License, media files (with or without embedded
Licenses) can be shared using any mechanism the user has
available (e.g., ftp, cifs, nfs, e-mail, USB mass storage,
etc.)
The public part of an Octopus Node is communicated in the
registration protocols defined in the delivery system
specifications and in the Marlin Core services of the
peer-to-peer framework, e.g., as in the Provide DRM Objects
protocol.
The Link objects, which are the only objects needed to enforce governance, are communicated in the response of certain peer-to-peer protocols. Link objects are also delivered in profile-specific ways, such as the Broadband Registration protocol. Note that Link objects, being self-protected, could be delivered and shared in other ways, too.
A variety of different sharing scenarios are possible between
devices, including superdistribution (receiving content from a
third party, typically another user), superdistribution of
subscription content, and shared streams (temporarily using
content on a device in the presence of a valid owner of that
content).
| Is an active protocol required to move media (content) files, or is it enough to simply transfer the media files, e.g., over a Marlin-agnostic memory card/USB stick between devices? |
No active protocol is necessary for content
bound to a user. If the content is device-bound, as is the case
for Broadcast content that signaled Copy One Generation during
delivery, then the License Transfer protocol is required. (Copy
One Generation is a broadcast Copy Control Information attribute
indicating that the content can only be played on a single
device. Thus, it can be played only on the device receiving the
first-generation copy, unless the copy is moved such that only
one copy still exists.)
| Where is the Transfer protocol defined? |
The License Transfer protocol is defined in
the Marlin Core System Specification.
| How can content that Peter has access to be played by his friend Paul on his (Paul’s) Marlin-enabled device? |
Suppose the License is targeted/bound to Peter’s User Node. Since there is no Link between Paul’s PC or other device and Peter’s User Node, the content will not play on Paul’s device. However, there are ways in which Peter may be able to share or even give away some of his content. Please note that Peter does not have the authority per se to give content away. Doing so would normally require the participation of an authorized entity, such as the original License issuer or a License Transfer Service.
Since content is protected (encrypted), it can be freely copied, e.g., from one of Peter’s devices to one of Paul’s devices.
Paul always has the option of purchasing content that he has obtained, by contacting the service provider, making the purchase, and then receiving a License to play the content (if the License is not embedded in the content file). Other ways Paul may be enabled to play content obtained from Peter include the following:
- Allowing access via a temporary Link Peter’s service provider could allow for a temporary Link to be created between the friend’s device and Peter’s User Node. For example, Peter could authenticate to the service provider and request a time-limited Link to be created (say for 12 hours). The temporary Link would make the content key (for all of Peter’s content) available to the friend’s device.
- Transferring the License to a particular piece of content via the License Transfer protocol
This is effectively a move
operation using the License Transfer protocol, so after the
transfer Peter will no longer have the right to play the content,
unless another License transfer is later done to return the
License to Peter. Note: The License Transfer protocol is intended
for content that is bound to a device (as opposed to a user). So,
the expectation is that the License Peter was initially issued
was also device-bound.
|
How does Marlin guard against content sharing abuse and piracy? |
Marlin guards against these in various ways. For
example, the system can enforce a limit on the number of devices
that may belong to a single domain (user). Individual devices are
also limited as to the number of domains they may belong to at
any given time.
Certificate Policies
| How are certificate policies used in Marlin? |
They are used throughout Marlin. Here are some examples:
- A DRM Object Provider that issues Link objects must sign them. Links are evaluated for trust independent of their acquisition. The fact that a system entity with the role “DRM Object Provider” was engaged in the acquisition of the Link may be lost when the Link is used to build the Node/Link topology. Therefore, an additional mechanism must be in place to evaluate the Link for trustworthiness. This information is conveyed via the certificate policy of “id-cp-octopus-marlin-signing-link”. Before a Link is relied upon to form the Node-Link topology, the signature over a given Link object must be validated. One step in the validation process is to see if the intended policy terms are in the end entity certificate.
- When a License is issued, a Controller object (and the Control it refers to) must be signed by a key that adheres to a specific certificate policy (see the Trust Management section of Marlin Core, 9.1.3.6). When a License is evaluated for validity, one of the criteria to determine that the License is trustworthy is whether the end-entity certificate for the key which signed the controller object has a certificate policy of “id-cp-octopus-marlin-signing-controller”.
- Rights issuers can be assured that compliant implementations must have certified keys that are intended to be used according to very specific certificate policies. Compliant implementations must demonstrate their ability to validate signed objects by following the guidance given in PKIX, which includes the formulation of certification paths, taking into consideration the intended certificate policy terms.
Trust Model
| There are two specific and distinct authorization policies. |
First, Marlin relies on NEMO’s trust management model to
authenticate communicating peers and to determine whether a peer
is authorized to participate in a particular service interaction.
For example, the Provide DRM Objects service must be able to
authenticate itself to a client and demonstrate that it has been
assigned the role of “DRM Object Provider”.
Secondly, in Marlin we define a set of certificate policy terms
that must be applied to the process of certificate path
validation. That is, a system implementation must ensure that the
required certificate policy terms are present in the certificate
path as part of signature validation. So, for example, an entity
that generates Octopus Links must sign each Link object, and in
order for an application to trust a Link, (minimally) the
certificate for the key that signed the Link must have a
certificate policy of
“id-cp-octopus-marlin-signing-links”.
What we achieve by this design is a separation of concerns. The
authorization of the entity which participated in the delivery of
a signed object is orthogonal to the trustworthiness of the
signed object itself.
You could also say that we have a mixed authorization model,
where the protocols between NEMO Nodes convey authorization with
SAML, and the creation of Octopus objects relies upon certificate
policies.
The certificate policies add granularity to the actions system
entities are trusted to perform.
Note: The Marlin Trust Management Organization (MTMO) contracts
Seacert Corporation to manage the root keys of the Marlin
Broadband and IPTV-ES Public Key Infrastuctures (PKIs), and to
provide sets of Common Test Keys (CTKs). The MTMO Common Test
Keys lay out a hierarchy of certificate authorities (CAs),
devices and services. Seacert also provides services as a
Provisioning Data Center (PDC) to Marlin adopters, creating
certificates and credentials for Marlin CAs, devices and
services. The PKI hierarchies produced by Seacert in its PDC
function mimic the hierarchies of the Broadband and IPTV-ES
CTKs.
| What kind of help is available to satisfy the MTMO robustness requirements? |
The Marlin Client Adopter and Service Provider agreements define
robustness requirements for client and service implementations,
respectively. Depending on the client deployment platform and the
level of experience of the implementers, it may be advisable to
seek support from commercial tamper-resistance providers. To meet
server-side robustness requirements, the MTMO lists trusted
service providers who can provide the option of supplying client
and server provisioning material that may otherwise require a
significant investment in infrastructure and operational
mechanisms to safeguard highly sensitive key material. Seacert is
an entity that is equipped to securely generate the Marlin trust
objects (certificates, keys, CRLs, role assertions, etc.)
How is Marlin right for your business? Find out how to Get Started.