BCi supports Hosted Marlin Service

New Hosted Marlin Service will need specialist integration

The new Hosted Marlin Service provides a fast, simple and scalable means to add Marlin DRM to an on demand platform. Cloud based services are proving to be a key element in the deployment and operation of OTT TV (Over the Top TV) platforms. The Hosted Marlin Service will allow OTT TV stakeholders (content owners, subscription operators, content aggregators, etc) to add DRM protection to content.

Cloud based services bring a range of benefits and many offer great interoperability to other platform components. Despite this it is inevitable that these platforms will require a level of integration into an existing system or with the components of a new deployment.

BCi is a systems integrator with unrivalled experience in the integration and testing of on demand platforms, OTT TV and Marlin DRM technologies. We can help stakeholder bring their Over the Top TV platforms into reality.



Marlin MS3 Apache Model

MS3 Apache Module in standalone mode

Part of our ongoing activities at BCi has been the evaluation of various Marlin technologies within our test lab. Given the current level of interest in the Marlin MS3 (Marlin Simple Secure Streaming) protocol, we’ve been looking at setting up a demo system in the lab to evaluate the various configurations of this technology. Of particular interest is the MS3 Apache module running in standalone mode.

The attraction of using Apache is that this offers a solid and reliable means of hosting the MS3 functionality. The architecture of Apache scales well, offers good security and good stability.

Apache runs on multiple processes. A supervisor process looks after the spawning of new processes as and when required by the demand on the server. This supervisor process can also take care of destroying these processes when they are no longer needed and can also cull them when they reach an old age (not something to be tried in general society!) This mechanism protects against runaway processes or memory leaks.

In order to host MS3 functionality, the Apache server must first be configured for HTTPS as per general Apache setup guidelines. The Marlin MS3 module is available as an Apache module. This is compiled from source, this being part of the SDK supplied by Intertrust. Once compiled, the resulting module is copied into Apache’s modules directory.

One possible complication when running the Marlin MS3 module under Apache is that of logging. In operation, it is essential that there is some way of accessing log data from failed MS3 access attempts since analysing failed attempts without log data is impossible. Some complications arise due to the way that Apache runs sub-processes; these are run as an unprivileged user and thus are not able to write their own log files. Unfortunately, any such attempt results in a silent failure as the logging failure can’t be reported. The solution is to use the UDP logging functionality built into the Neptune libraries that are linked into the Marlin MS3 module. Neptune is a set of C++ libraries for common functionality used heavily within Marlin MS3. Neptune libraries are used here as the Neptune framework can be compiled under a wide variety of architectures allowing the Marlin MS3 components to be ported easily to other targets.

With the UDP logging enabled, it is possible to successfully run the Marlin MS3 module within Apache and have easy access to logging information when required. The Itertrust SDK includes a simple log client that can be used to display the UDP logging information emitted by the logging package. With these tools configured, it becomes a much easier task to debug problems with the Marlin MS3 setup.


Marlin MS3 Architecture Options

Flexibility for Marlin MS3 Architecture

Looking through the Marlin MS3 (Marlin Simple Streaming Server) specifications, it is apparent that there are a number of ways of setting this up. The chief difference would seem to be whether or not to run the MS3 server as a standalone server or integrated into another server. Once again, within these options, there are still other variants in the way the service is set up.

In principle, Marlin MS3 provides a simple, lightweight way for a client application to access protected content. The client and server elements use parts of the Marlin codebase to ensure that the client and server are valid devices (as attested by the credentials in their respective certificates) and to securely transfer the decryption key and usage rights from the server to the client.

In all cases, the service provider decides on the usage rights and the back-end systems process the content to add encryption and identification metadata. The content can be served by either streaming or file serving from a traditional edge device. The implementation differences manifest themselves most clearly in the mechanism used to transfer the rights information to the client.

In the standalone model of deployment, the Marlin MS3 server runs as an entirely separate server (or cluster of servers), separated from the business logic manifested in the portal server. At first, this might seem somewhat odd: how could a completely standalone server know what rights to embed in the access statement? The somewhat ingenious answer is that it doesn’t, the business logic (rights, etc) is still managed by the portal server and passed to the Marlin MS3 server via the client. In this scenario, the portal server makes the decision to grant access to the client and the terms under which this is done and wraps this up in a business token which it then passes to the client. The business token effectively contains instructions, encrypted and readable only by the Marlin MS3 server, on the type of access statement to produce. The client can then present the business token to the Marlin MS3 server and in return receives a stream access statement SAS. The Marlin code in the client can then decrypt this SAS and obtain the decryption key and usage rights.

In integrated mode, there is a direct coupling between the Marlin MS3 server components and the business logic. In this mode of operation, the portal server issues a SAS directly to the client without going through the business token exchange step. Such a setup requires that the Marlin MS3 SAS generation code be included in the portal’s implementation.

There are still more variations on how to implement the Marlin MS3 server in standalone mode. The SDK supplied from Intertrust comes with test standalone implementation, an Apache module and a CGI module that can be used in any web server that supports the common gateway interface.

Ultimately, the most suitable type of Marlin MS3 implementation will depend on the scale of the deployment, the level of integration required and the amount of engineering effort available to implement the solution. The standalone approach can offer an easier path to deployment but has the overhead the extra server/client exchange. The integrated approach would ultimately result in a more elegant implementation but requires more integration effort. With both approaches, there are a number of ways in which the solution can be scaled.


Marlin DRM White Paper

Marlin DRM White Paper

This Marlin DRM White Paper discusses the key drivers in the adoption of DRM for Over the Top TV (OTT TV) solutions and whether the Marlin DRM will be adopted wider following the recent decision to use it for the UK’s YouView service (formerly Project Canvas)

Marlin DRM White Paper