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.