Johannes: All right, welcome everyone to today's webinar: Digital Rights Management (DRM) Demystified. For everybody who has joined a bit later, we are collecting questions throughout the presentation, and then we will answer those in a Q&A session after the presentation finished.

All right let's get started: on the call today we have Pieter-Jan Speelmans, CTO at THEO Technologies, and myself Johannes Jauch, CTO at Axinom.

Short introduction to Axinom: Axinom is operating Axinom DRM, our cloud-based DRM license service for more than 10 years now. We serve billions of DRM licenses to audiences worldwide. We do have large and small customers around the globe on every continent. Axinom DRM is a part of Axinom Mosaic. Axinom Mosaic is a set of backend services that our customers use to create and operate modern, highly scalable online video platforms. If you would like to learn more about Axinom, we would be happy to chat with you on axinom.com.

Pieter-Jan: And I am Pieter-Jan Speelmans, CTO at THEO Technologies, company aimed at making the best possible user experience available to all of the viewers out there, with of course known for our flagship product THEOplayer, but also with a lot of other initiatives aimed at improving this video experience. So, let's get started, Johannes.

Johannes: Alright, thanks Pieter-Jan. And now let's directly dive into our first topic. That is adhering to requirements of content owners. Lately, we hear more and more questions like how to implement different keys and configurations for different stream qualities.

So, what about this typical requirement from a content owner? I've written down it here. It's something from real life - consists of four different pieces: Audio, SD and HD tracks. must use separate encryption keys. Hardware-backed DRM is mandatory for resolutions of 180p and above. When video is displayed on an external screen, the system must enforce the use of the HDCP protocol version 2.2 or above. In any case, video display on external screens must be prevented for resolutions of 180p and above.

Why encrypt with multiple keys in the first place? To better understand this requirement, it makes sense to have a look at how DRM playback actually works today. If you buy a device in a shop, be it an iPhone or an Android device or a smart TV, these devices typically already have a content decryption module installed. A content encryption module comes typically in one of three flavours. It can support Fairplay, Widevine or PlayReady DRM. The content encryption modules are pieces of hardware or software that are built in a way that is tamper resistant. Anyone who would like to understand or change the inner workings of such a module by re-engineering it will have a really hard time.

That is the reason why the content decryption modules are trusted by studios and content owners and why they have very important responsibilities when it comes to protected video playback. These responsibilities are - creating DRM license requests, decrypting DRM licenses that are received from DRM services, enforcing the DRM policies that are contained within and then decrypting the encrypted content and displaying that content. So, if you think about it, these are all the responsibilities that somehow get their hands on the important pieces, the keys to decrypt, and on the other hand, the unencrypted content for displaying it.

The player application in between is merely a messenger between the DRM service and the content decryption module. The player application has lot of important things to do but it will never get its hand on either the keys for decrypting the content or unencrypted video frames or anything like that. That's not the business of the player application because it's considered not trusted.

This content decrypting module comes in two flavours: hardware-backed or software only. Hardware-backed is typically on Android devices, on Apple devices, Windows devices as well, Xbox, PlayStation, Smart TV, and so on. And they have this designation of Widevine Security Level 1 or PlayReady Security Level 3000. So, these translate to hardware-backed DRM. Whereas they're also pure software-based content decryption modules on devices. They have Widevine Security Level 3 and PlayReady Security Level 2000.

The purely software-based are typically less trusted than the hardware-based because they are a little bit easier. Because, well, easy is probably not the right word here, but less hard to attack than a hardware-backed content decryption module. Examples of pure software CDNs are the ones that come with an application, for example the Chrome browser or the Firefox browser. If you download that to your Mac or to your Windows PC, then those applications contain a software-only content decryption module.

Back to the question, why encrypt with multiple keys? Because it brings quite some flexibility. Let's have a look at a sample use case: let's say we want to provide HD or ultra-HD or high dynamic range content only to clients with hardware-backed DRM to take advantage of this improved security and protection. But on the other hand, we want to reach the broadest audience by providing content in low resolutions to as many devices as possible. So, the solution here could be - we use different encryption keys for encrypting different tracks in an adaptive bitrate asset. And we authorize devices based on their capabilities.

Let's look at that sample asset - so here we have a sample MPEG-DASH asset. Very typical, we have a representation in audio and a couple of video representations with different resolutions. For audio, we use one encryption key. For less than HD resolutions, we use a second encryption key. And for the HD resolutions, we use a third encryption key. And for the ultra-HD resolutions, we use the fourth one.

More often than not, a question arises that says - but wait, can't I just keep two versions each encrypted with just one key? Or I have enough storage, so I have one version for hardware-backed DRMs and the other one for the software-backed ones. Well, that's a good idea, but it has some issues, and actually, no, you cannot do that. And there are several reasons to that, but one is typically connected to how the CDNs are built. If you have an Android device, typically you have hardware-backed DRM there, but this only applies to the video portion - only the video playback is fully supported in hardware-backed DRM. And the audio track, for example, is still running through something that is less protected. Could be a software-only DRM, a CDN, content-encryption module, and that means that an attacker, if you have just one encryption key and all of your asset is encrypted with that key, that attacker could go against the software portion of the CDN and find out the key by this and then decrypt the video as well. So that doesn't help. Good idea, but no, that doesn't work.

Johannes: So how to achieve multi-key encryption end-to-end? There are several components in the delivery chain that need to support multi-key assets. The first one obviously is the encoder/packager that needs to be able to create the assets with the tracks encrypted with different keys. But then there's also the DRM key service. That is the component, that part of the DRM service that delivers encryption keys to packages, not to confuse with the next component: the DRM license service, this is the one that at playback time delivers DRM licenses to end user devices. This also needs to be capable and understanding of this requirement. And then last but not least, obviously the player also needs to support this and fetch several keys when switching from one rendition to another to provide buffer free playback. And the good news for all of this is that Axinom and THEOplayer may have you covered.

Johannes: Now let's have a look at how authorizing playback at runtime works.

It starts all with the player: let's say the end user is browsing some catalogue and now wants to watch some asset. And then the player, at that point in time, needs to send them a request to an entitlement service. This entitlement service, by the way, is the main integration point with Axinom DRM. So that's a component that our customers typically every time write, and it's integrated with the backend system. That entitlement service knows the user, knows who is logged in and what rights this user has to what asset. And so, in that point in time when the entitlement request arrives at the entitlement service, the service has the responsibility to create now a JSON structure and the content of this JSON structure says what rights that user should now get to that title he's asking for. And this controls everything that is later than translated into the DRM license. For example: playback duration, persistence of a license on the device, or also output protection, should this player be able to only play it on an internal screen, or is it allowed to display this on some external screen as well. Such information goes inside the entitlement message. So, when that entitlement service has created, the entitlement message informs a JSON web structure. And actually, it's a JSON web token that is signed by the entitlement message to make it tamper-proof, that goes to this player application again. And then the player can now finally turn to the Axinom DRM license service in the cloud, and while doing so, we'll attach the entitlement message it just received, and then the license service will translate this into the DRM license of the flavour that this device needs. So, it will create a DRM license either in FairPlay or in PlayReady or in Widevine. And return this back to the device and then the player can start playback.

Johannes: Let's have a look at the contents of an entitlement message, represented by this JSON Web Token: we start with content keys source, which in this case is inline, meaning that we now list next all the key IDs that we want to authorize. So, we have one key ID here, which we authorize and where we attach a usage policy called audio. Another key ID and we attach a policy called SD and another one with policy HD. And then further down the document, we define those usage policies.

The one with the name audio has no additional settings. So, this translates to being maximum permissive.

Then the next one is the SD policy. This has some restrictions. For a Widevine case, it requires device security level of software secure crypto, which translates to a software backed content encryption model is good enough to playback this content, and it requires HDCP 2.2 protocol. And essentially the same requirement translated into PlayReady language, minimum device security level 2000 and uncompressed digital video output protection level 300.

And then we have the HD policy, which is even stricter. In Widevine case, we require device security level of hardware secure all that translate to hardware backed CDN, and HDCP no digital output, which means that we do not allow output to connect external displays, but this will only play on an internal display. And the essential same thing translated to PlayReady language as well.

Johannes: Alright, now we have covered quite some background about DRM and all of those server-side interactions. One question remains, what about the player side? And to answer this in the best possible way, I now hand over to you, Pieter-Jan.

Pieter-Jan: Yes, and what about the player side? That is a very good question. As Johannes just already mentioned, DRM is mostly a story written between trusted components. That means - components in the DRM server and as close as possible to the client hardware, meaning inside the CDN. And if you look at it, it appears as if the player is just a component in the middle, having to pass through all of the relevant data, and that's what it appears like, but that's not really the case.

The player actually has quite a large impact, and the reason for that impact is because while the raw license data just has to be passed into the CDN, there is a major integration point with the different streaming protocols, such as like HLS, MPEG-DASH, which are some of the most popular streaming protocols today. And if we look at it, there is one thing which is a major responsibility of a player. And that's that - player must ensure smooth playback, it cannot stall. The user experience has to be kept on the level, meaning that you have to make sure as a player that your buffer is full, that you can continuously play, that you can adapt to network changes with ABR, switching between HLS variant streams and DASH representations.

And of course, if you have to keep in mind that you have to guarantee that buffer, then doing multi-key actually has a huge impact. And why? Well, when a player has to switch qualities, that's when the multi-key aspect comes into play. So, to dive a little bit deeper, let's have a quick look at the flow of a quality switch. And in its essence, a quality switch isn’t that hard. You download the playlist if that's even required, you download an initialization segment or a media segment and you add it to the buffer. And if that all went well then basically playback will start. But that's the way how this actually works without doing multi-key.

If you do multi-key, there's something else that will happen. And that is after step three or four, so after appending media data, or the initializer, you will get a license request from the CDN because of course it will notice that a key is needed to actually playback this content. So, there's an extra step needed. We need to use that license request, we have to issue it, send it to a DRM server, it will get you a response and we need to pass through that response into the CDN.

But there are multiple problems here. First problem is - what if you cannot get that license? Because you don't have authentication, or the authorization isn't right. Or what if your device that you're using doesn't satisfy the restrictions of the DRM license? In that case, you won't be able to play this content and that switch will need to be aborted. And all of that will take time. Even if it succeeds, that license request is an extra step in between, and it takes time. And all of those things it can add up. It can mean that your buffer is reduced, or it can even be drained completely. And as a result, the player will stall. That's not really good because we're kind of breaking the rules here.

Pieter-Jan: So, what should a proper player do? The first mistake is a player should really identify if another key is needed. In some cases, this is visible just in the manifest or in the playlist if you're using HLS. And once you have that updated playlist or manifest then you can actually see if a new key will be needed. And if it is needed you can of course  you can check that you already have a valid key, avoiding a potential invalid license. So, if you don't have that playlist or that manifest, you should get it as soon as possible. To extract the PSSH, identify the key that's being used and check if a different key will be in place.

Now, if you know that a different key is in place, of course, things can still go wrong. So, what else do you have to do? Next step is actually to make sure that you can switch without running out of buffer. If you know that you need to do a switch and you need to do a key request, then it's important to know two things: first of all, if you switch to a lower quality, which is usually the most urgent switch because your buffer is already draining, you're probably pretty safe. You will satisfy the requirements for DRM license so that's good. So as long as you have authentication, and you can get that license you should be fine. If you're switching up however, you're doing it because your buffer is likely full, you have ample bandwidth and well you think that you can increase the quality. So, in that case it's especially important that you check if you need to get a license. Also, something that a smart player can do is it can actually download that playlist manifest or even potentially an initializer, while still downloading the media data of the last quality. And that's also a pretty important one because doing this you can keep your buffer at the level while already anticipating a potential switch and potentially even already requesting an updated license before starting the download of heavy media data by just using the PSSH from a manifest or using a PSSH from a small initialization segment.

There's a last step or well, better said, actually a first step. Make sure that you always use the rule of the strictest requirements. If you need to switch up to a higher level of security, it might mean that you need all of a sudden hardware DRM. Well, previously you were on software DRM, but if it's available on your platform, you should start with hardware DRM from the start. If it then happens that you need to make a switch, it doesn't come at a cost because that pipeline is already set up. If you need to switch it while you were playing software DRM, reinitialize the entire pipeline, that will be noticeable. It will not just take time, but on some platforms, it even causes insertion of black frames or glitches or stalling just by switching the pipeline. So, if you really want to do it well, you should always use this rule of most strict requirements to make sure that if you change a key and if the license requirements change, that you can adopt to them as quickly as possible.

And if you keep all of this in mind and it's not common for players to do this today because doing multi-key isn't something that's used across the board yet, it's used for high quality content, but it's not used for all content yet. So, make sure that you do have a player that can handle this setup. But if you follow these steps, then you can ensure that all of the requirements that content owners are stating, that you can fulfill them and you can actually make sure that the user experience in the end is good as well. And I think that that's a pretty important note to close off this question.

Johannes: Thanks, Pieter-Jan for these very thorough insights into player considerations. Now let's turn to another question. Why is protecting live/linear streaming so hard?

A requirement that we see quite frequently is linear streams must rotate encryption keys every two hours or 24 hours or whatever. Or it might be something else, think of a linear stream where you have one program and then comes another program and these are two completely different beasts and with different DRM policies attached to it, more premium, less premium content. So, the consequence can be keys must and policies must rotate.

So, in a naive approach, how you could go about it is, in the MPEG-DASH manifest, announce a new period when the keys must rotate. And then let the end user devices find out and send license requests as needed.

I think this picture here illustrates well how it looks from the server side. Doing such an approach is probably one of the quickest ways how you can create your very own sophisticated distributed denial of service attack. You can see that without mitigation such a simple requirement like rotating an encryption key can cause something that I would call a perfect license storm. Many packets arriving at the license service in the very same point in time and that can, well, depending on how many of those are, cause problems in your infrastructure.

Let's do some math for this linear streaming case. Let's see you have an audience of 1 million people viewing some linear channel, and this is streamed with latency of 30 seconds, and now the keys rotate. This translates to 1 million license requests coming in within 30 seconds. And this means per second, you have more than 30,000 requests. That's quite a lot, it's definitely doable. However, there's more to it - latency is something that we typically want to reduce. Everybody wants to reduce latency. 30 seconds that I was mentioning is something that we consider quite average, but now we have higher aspirations, we want to go down to 10 seconds, five seconds, sub-second latency. If you have such goals, they directly work against service stability, in case you're following that naive approach without a mitigation strategy. And as a result, you will see something like this - playback error. Asking your end users to reload the stream or whatever, this is something nobody wants to ever see. So, we need to work on a solution.

And there are mitigation strategies that can help. Well, one obvious one is increased service capacity, this has limits and it's also expensive potentially. Another one is distributing license acquisition over time. And then there's live events, that is when stretching the distribution of licenses over time is not so easily possible. That is when a potentially large audience tunes in to your channel at the very same time, around the very same time, within just a few minutes. And everyone kind of needs a license now. Obviously, you cannot pre-deliver those before people arrive. So, that is something where you actually need quite some service capacity, but there are also things that can go wrong.

What you should, for example, not do, what we have actually seen in the wild - do not make everyone wait in the few minutes before the event starts without the possibility to send license requests in a kind of a waiting room. And then when the stream starts, let everybody ask for our license and in this way open the floodgates and produce the highest peak that you can produce with this audience, which will give you potentially trouble. So, it's better to have the stream already running five minutes before the event and let those clients that tune in, that come in the two, three minutes before the event, each of them acquire the license. This way you can at least stretch it over a few minutes and then you're safe and this can be definitely handled.

If you do have a big audience, when working with a DRM service provider, we would recommend that you verify a few things. For example, that your capacity needs can be met with some margin. And also, that those capacity needs can be actually met in that geography where your expected audience is. And yeah, then don't trust that. Do some load testing to be really on the safe side. With Axinom DRM, what we do, for example, we offer guaranteed capacity. So, this means that our service is guaranteed to be able to deliver X, and that's an X that you define, licenses every second for an extended period of time. And regarding geographies, we do have Axinom DRM license services in data centres across the globe, in South America, North America, Europe, Asia, Australia. So close to all the audiences worldwide, we do least latency routing to bring down the roundtrip times and to provide the best user experience. So, such things are important to not miss any timing threshold to take too long to deliver the license and already some buffering on the player side occurs. So, all of this should keep in mind, and tested, I think that's an important recommendation before going live with a really large audience.

Johannes: But wait a minute, we were discussing this multi-key topic, and a logical question is “Does this topic have an impact on the number of requests that get sent?” And this is actually the case. Let's look at the details a little bit more because it depends on the DRM technology involved. For example, in case of Widevine, it has been always the case that Widevine license request can get as a response several keys. And for PlayReady it's the case since 2015, PlayReady can deliver several keys within one license response. So, most of the devices that you find out there will be able to do that and will only send one license request to fetch all those keys that are needed for a multi key asset. But for Fairplay it's a different story because Fairplay needs to request keys one by one. So it will translate to several license requests. Keep that in mind when calculating needed capacity.

So having high service capacity is nice and that's all good, but there was a second mitigation strategy that I have mentioned, and I think there's a lot more to it. And with this back to you Pieter-Jan.

Pieter-Jan: Yes, there most definitely are other mitigation strategies. And one of the best ones, or one of the important ones to also keep in mind, is that you can actually spread the love. Or, well, better said, spreading the load. So, making sure that not all of those requests come in at the same point in time. The question is, of course, how do you do this? The answer is, well, quite simple, or, well, we can make it sound simple. by basically making the player smarter. So as Johannes already mentioned, if you have 1 million viewers and they all need a license in 30 seconds, that's a lot. But what happens if you only have a two second latency or a two second buffer on the player side, then it actually becomes a lot worse. Because that number, it goes up to 500,000 requests per second and that is a lot. You'll need a lot of infrastructure to handle this but that's not really the worst thing about this story. The worst thing about this story is it only is for two seconds. So, most of the time your infrastructure will actually be idle because if you rotate a key for example every two hours you have 7198 seconds in which your servers are handling next to no load and after that two seconds of load.

But still, I mean, if you look at this as a big picture, this means that, and I'm being nice here because I'm rounding up, this means that your server is active for 0.03% of the time. And that is not a lot. So, if you can actually spread this load, and if you can make sure that those 1 million requests would come in over the full two hours, that would actually mean only 140 requests per second. That's right, 140. We're not even talking about thousands here. And for 140 requests, you don't need the big infrastructure.

So how can you actually make this happen? And the answer is relatively simple - it is about making sure that the player knows. If a player knows that a new period is going to come up, for example, in DASH, with a new key, you can actually put that PSSH in the playlist up front or in the manifest up front and you'll be very quick to say - well hey yeah that sounds good and you have to do that but you don't announce your period that much up front so maybe instead of two seconds you'll have four seconds but I mean the problem is not solved, so what else do we have to do? because there are of course other steps to take.

The answer is quite simple: with multiple keys in one license, you can solve this quite easily. If you put in your PSSH, for example, multiple keys IDs, then you can use this to request multiple keys across representations and renditions, but also across time, so across multiple periods when you're rotating a key. And that's the fact that we want to leverage here. So, when a client requests a key, you can already provide the key for the next period as well. And that is very useful because at that point in time, it means that this client that already has the next key doesn't need the new key for the new period. That's very fun, because it means that you will have less license requests, but you'll again be pretty quick to notice that this isn't a complete solution. Because yet again, this just delays the problem. What it means is that half of your clients will actually know that they have the key, and the other half, statistically speaking, they will not have the key for the next period yet. So, they will all still request that one.

So, I mean, in an optimal scenario, it means that you will get a reduction of your license requests by half. But I mean, half of 500,000 license requests, that's still a lot. That's true, because there's a lot more to it.

One of the things, for example, that you can do is you can make sure as well that in your PSSH, the key for the period after the next period is already visible. The player will not see that it has both keys because one of those keys it doesn't have. As a result, it will actually issue a license request. But the nice thing is if that license request doesn't receive a response in time before the buffer runs out, it actually means that the player can just continue playback. That's one approach and it's a very good approach because it gives you more time. It will not spread out that license response or at least all of the license requests over two hours, but it will give you a little bit of stretch already.

But of course, we want to aim for that two hour, we want to aim to smooth it out as much as possible. So, what can we do? What can we still do? And there is one option, but it's a little bit off standard. And that option is a player could identify or could be told that at least it should anticipate that a new period will come at a certain point in time and that it will use a new key. A player could learn this, for example, from seeing historic periods where it has seen key rotations, or with configuration, you could actually configure this in a player. And if a player sees that it has, or that will have an upcoming key change, then it can request a new license where the server can respond with multiple answers so with multiple keys.

Or you could provide to the player during a period through, for example, streaming metadata, PSSH for the next period already or for the next discontinuity or for the next key rotation and by providing that PSSH or that key ID the player can already issue a license request for the next period and for the next key while playing still the previous period. And doing this you can actually get this smoothed out and you can reduce that number of license requests quite significantly.

So, I think that the most important thing to note here is that with the right DRM partner, as Johannes said, you can scale to any number of license requests per second. With the right player partner, you can actually bring down the peak capacity of number of requests per second that you need and spread it out pretty nicely. There will still be peaks because people will join at specific times when shows start, but those peaks, they can be smoothed out quite significantly. And I think that's the way forward that people should be looking at for handling the multi-key and key rotation problems.

Johannes: Our last topic for today is integrating DRM in your content supply chain. How to get started with DRM implementation.

Now is the time for some hands-on demonstration. Let me take you to portal.axinom.com in order to show you how you can achieve protected video playback within just a few minutes. So now this is the Axinom Developer Portal, where you can register for a free evaluation account. Click on DRM, click the Request Evaluation button. And five minutes later, you will have your very own evaluation environment for Axinom DRM. Then you go and click on Axinom on My DRM. And you can enjoy all the services in the portal. This portal comes with comprehensive documentation, test and FAQ section, pricing, service agreements, and also access to support. That's all there. What I would like to show you now quickly is just a piece of it - the tools section. So, there are tools for BASE64 conversions, JSON web tokens, Widevine, speakey, entitlement message services, and so on. But there is the DRM video playback tool, which I would like to have a look at right now.

The video playback tool lets you play back any DRM encrypted video and lets you create and define the license that is needed for that. So, either when you start you have your own video that is protected already created, maybe using Axinom encoding or some other encoding service like AWS, Bitmovin encoding, or you name it. Or if you don't have your own video, you can also use some of the Axinom test vectors.

For example, here, I can pick one. And then, as you can see, it fills nicely the form with the respective values.

And now I picked one of these simple test vectors that we offer. Also, the key ID is also registered already that is needed for playback of this asset. And here, the communication key section, that's an important one that's essentially authenticating against our service. This is the communication key ID and the communication key itself. These are used to signing the JSON web token later.

And now I've prepared that. Now I can generate a license service message. And I can look at that in plain text over here. This is a JSON message. It's an Axinom license service message. And to be more precise, in it is an entitlement message. And it authorizes this key ID. This is the minimum configuration that you can do to authorize an asset.

Alright, so now we have done that and okay now I can click this button from the license service message converted to assigned JSON Web Token with the credentials I provided above.

Next what I can do to try out this - I can select which environment I'm in. I'm in a test environment so that's fine. I have for PlayReady Widevine and Fairplay. And then finally, I pick a player, and this case THEOplayer is here, and let's click get player link.

Then this page creates a player link for me. That's a link to THEOplayer's demo page, and it has URL parameters. So, the manifest URL and also the JSON web token, these get transferred to THEOplayer’s demo page, I click this launch player button.

So now we can see the page on the side of THEO. And as you can see, the manifest URL has made it here. And the entitlement message JSON Web Token is also here, I suppose, because otherwise playback would not work.

So, let's try and hit that button and see - playback successfully works. And as we are now back on the THEO page, I hand over to you, Pieter-Jan.

Pieter-Jan: Yes, thank you. And well, as everybody can see by this demo, it is actually very easy to add DRM to your flow. No reason not to do it, especially not because, well, in a lot of cases, this is just a requirement that you have if you want to distribute premium content or if you want to protect your own content.

Pieter-Jan: So, if you have any questions, don't hesitate to reach out to us. We're always happy to help, both from Axinom's side and from THEO's side. And I really hope that you all enjoyed this webinar. Because of course it is limited in time and there are a lot of mysteries that we didn't demystify, I'm pretty sure that there are some questions. So, let's dive into the Q&A portion of this webinar.

Johannes: Yes, all right. Let's start with the first question that I've been seeing. The question was:

“Is the CDN responsible for decoding the content as well?”

So, I think the question is about this is not just for decrypting but also decoding and playing it. And the short answer to this is yes, modern CDNs, they take all the responsibility for decrypting, decoding, displaying the content. So, the essential idea is to not have the CPU or code that you as an application control to advocate its hands on unencrypted pieces. So, the decoding is part of the verified media path where the media goes through to reach the display. So yes, that's a responsibility of the CDN. It will take advantage of the hardware, typically decoding nowadays, is supported in hardware. And so that's what the CDN does here. There are some ancient CDNs out there where the work is maybe a bit different. But this is, I would say, today a rare exception. So typically, yes, CDN is responsible for decoding.

We have another question. Regarding license request upon key switch quality based:

“Why can't you get a license for all authorized keys in advance?”

I think Pieter-Jan, that's for you to answer best.

Pieter-Jan: Yeah, and it's definitely something that you can do, but not in every case, I fear. So, as you also mentioned, Johannes, you can only do this for recent versions of PlayReady. You can do it for basically every version of Widevine and you cannot do it for FairPlay. So, if you do identify that there are multiple keys being used across different qualities, then well, you will need to get in some scenarios, you will need to get all of those keys individually with separate license requests. So, while for most cases, it's yes, something you can do, in some cases, it's not. Also do note that if you do get a license with the keys of the higher qualities, it might be that you're not entitled or  that you're not able to play a higher quality fee.

Imagine the scenario where you have also a 4K feed, which of course gets a lot higher protection or a lot stricter protection. It might be that you don't satisfy all of the requirements there. And in those cases, well, you will not get back that authorization key upfront. So that's definitely one that's quite important to do.

I also noticed that one of you did send a second question in the configuration in the form when you registered, which was about handling key rotation with the prefetch of keys and how to transition  from protected content to clear and back to protected content without needing to reacquire the DRM license.

I don't know if it's one that you want to discuss, Johannes, or if I will take it. For me, there is fine.

Johannes: Yeah, you go for it, Pieter-Jan!

Pieter-Jan: So, this is something that definitely is possible. The core thing that you will need to do here from a player perspective, at least, is you will need to make sure that you keep that license alive. So, if that license, of course, was configured, that it was like a one-time usage license, or if the license has expired by the time that you get back to encrypted content, you're kind of out of luck, and you will have to re-request that license. But if you don't have that problem, so if that license is still valid. If you don't reset the full decoding pipeline, then you don't have to request a new license. And that license will still exist in the current pipeline.

This is not something which is straightforward to do from a player perspective at least. It actually means that you need to feed that unencrypted content into that encrypted pipeline as well. And while it is not easy, it is definitely something that can be done from a player perspective as well. So, if you have any additional questions on that, well, you have my email address, I assume, so just ping me and happy to discuss because there are some asterisks, of course, depending on the platform that you're planning to use, but in most cases, it's not a problem to avoid getting a license request there.

Pieter-Jan: The next question I see the mention of ad insertion and the impact there on DRM. We did actually not manage to get that topic in anymore. I don't know if you want to say anything about it, Johannes?

Johannes: Well, ad insertion and its impact on DRM playback. Yes, unfortunately, I think it was not on all channels be published that we will not have this topic in this webinar anymore. But essentially, I think it's about the topic that you have been addressing, Pieter-Jan, just in the question before how to switch forward and back between portions of a live feed that are encrypted versus that are not encrypted. And well, it’s a huge topic, probably, if we deserve a webinar by itself. Depending on how you do that, there is a server-side ad insertion that can be done where there's a lot of functionality needed and a lot of tricky things to consider getting it right in order to have smooth playback without interruptions. And client-side all of this can be handled. It is doable, but the tricky part here is being able to, what Pieter-Jan said before, acquire licenses and use them for encrypted content and have a break playing non-encrypted content and then using the licenses acquired earlier, continue that, and have a smooth playback.

Pieter-Jan: I think it's especially on the smooth playback that's important for ad insertion, by the way. So both for client side and for server side, we do notice that, well, most players don't handle it perfectly. What you see and what is very common is that players need to tear down their entire playback pipeline. On some platforms, that's not a problem. For example, on a Chrome browser, there are usually pretty powerful machines underneath, which mean that switch is barely noticeable and it's like a black flip frame that's inserted. But especially if you start looking at platforms which are lower powered, think Android TV devices, smart TV devices, then it becomes very important that you recycle and that you reuse that same pipeline. So, it's indeed something where we could probably spend an entire webinar focusing on only that point, but happy to discuss if you have any specific questions, feel free to reach out to either of us and we'll get you going and get you some more insights there as well.

Pieter-Jan: The next question on multiple decryption modules, something I can tackle or something you want to tackle Johannes?

Johannes: Well, I can take that one. So, the question was:

“Is there a case for multiple decryption models, so CDNs, on a single device?”

I would say that's something that is really rarely seen. However, it is definitely the case. It exists. So, there are, take the Microsoft Edge browser that supports Widevine, as well as PlayReady with just one client. And there are other devices in the market that have several CDNs. Typically, Smart TV tend to support more than just one flavour of DRM technology. But typically, in most cases, you just pick one of the technologies on a per device basis and implement that. So that either go for PlayReady or Widevide. So PlayReady or Widevide are the ones that coexist. FairPlay is kind of an outlier because it's supported by Apple's devices only. But yes, it does exist. And it just gives you more freedom of choice depending on what you want to achieve on those platforms. Maybe you want to add anything, Pieter-Jan, to this question?

Pieter-Jan: No, I think you answered it perfectly. The only other CDN that's widely available across almost every platform is like the ClearKey CDN. But that's not real DRM, of course. That's more an encryption flavour. And of course, there's a significant difference between DRM and just normal encryption. Wherefore, normal encryption, like well, in the name of ClearKey, you can just get the key out of your network tab or anything else. So yeah, you answered it quite nicely.

And the next one I will definitely leave to you. It's the one on the cost of Axinom. I don't know if you even want to answer that or if that's something that you should rather discuss in person given that there's probably some flavour needed there, or some context needed there.

Johannes: I'm happy to address that really quickly. We do have published pricing in our portal. Essentially, it starts, it depends on how much consumption you have, but it starts at 195 euros on a monthly basis with the software as a service offering. And then depending on how much you use, we have business models based on consumed licenses or consumed or users that use it, monthly active users. But have a look at the portal register and you can see all the information there.

And we are getting close to the end. There's. What questions do we have here?

Pieter-Jan: Yeah, there's the one on the preferred way for a single key or multiple keys. I think you do have a pretty good opinion on that one. And then as a last one, let's also take the one to reduce CDN load using CMAF for HLS and DASH together with DRM. Do you want to pick the multiple key, single key one? Then I'll pick up the other one.

Johannes: All right, yes. So,:

“What's the preferable way of encryption, single key or multiple keys?”

So that really very much depends on content owners’ requirements. And it's just becoming more and more common that multiple keys become a requirement. And it's just, I would say, that's the way how to go in the future. It's future proof. It's what's being asked more and more. Depending on what kind of content you have, you may or may not have to use that already today. It's definitely the most secure and most protective way you can go about content protection, and so, if you haven't done so, I would take a look and consider it, especially if you have HD or think about Ultra HD, HDR, any kind of such content that you will very quickly run into this and have multiple keys to protect. It's also quite supported across devices today.

All right. And the last one you want to pick, Pieter-Jan.

Pieter-Jan: Yeah, I'll take that one. So, the question was also:

“How to reduce CDN loads by using CMAF for HLS and DASH along with DRM?”

That's a very good question. And I think it could also be its own complete webinar, to be honest.

The tricky thing that you will have there is that there are multiple flavours of the encryption which is being used by DRM. Being of course CTR mode and CBCS mode, or well CBC mode, but often referred to as CBCS. And the problem is that FairPlay historically has been using the CBCS mode and that Widevine and PlayReady historically used CTR mode.

Now the good news is that CBCS mode has also been implemented by PlayReady and Widevine. So as a result, yes, you can today reduce your CDN load when you are using CMAF in combination with CBCS encrypted segments, because those can be used by Fairplay, Widevine, and PlayReady.

But a very big asterisk there is actually that not all devices support the CBCS mode of PlayReady and Widevine today. All popular browsers, they do support it, because while they get software updates quite regularly. But if you want to do this on smart TVs, then it will become a lot more tricky. Simply put every smart TV that wasn't sold this year, but is older than one year more or less, is not able to actually play the CBCS mode of PlayReady and Widevine. So, if you have a focus on mobile devices and browsers, you can simply put the content protection configurations for PlayReady, Widevine and FairPlay in your DASH stream, or you can put the EXT-X-KEY tags for HLS for PlayReady, Widevine and FairPlay in your HLS stream. And then that will work. But as mentioned, there are some notes to be made if you also want to tackle some other platforms.

Johannes: All right, thanks Pieter-Jan. We have collected a few questions and let me start with the first one. The first one is about PlayReady:

“Where can we find documentation on the PlayReady content key usage policies, and specifically the meaning of the values you can specify for instance, compressed digital audio output protection levels and related?”

This is a good question, and it’s actually, Microsoft publishes PlayReady compliance and robustness rules on their website. So, if you Google for PlayReady compliance and robustness rules, you will end up finding a link to a document. It has, I think, it's about 80 pages or something. Don't be afraid. It is just a portion of that document that exactly explains all the settings.

So essentially, the question you asked about compressed digital audio output protection levels, that is a setting that sets the protection level and the higher the protection level is, the more restrictive the output will be. So, for these settings, you can control if an output is possible to analog audio or digital and so on.

All right, Pieter-Jan, I think you also have a question.

Pieter-Jan: Yeah, so I can see that there's also a question out on that can be really troublesome. And then the question is:

“Would it be feasible to have per viewer keys?”

Of course that would be possible, but if you would have a key for every viewer, that would mean that your content would need to be re-encrypted for every viewer. And that would be quite troublesome, just to say the least. Why would it be quite troublesome? Simply because, well, then you won't be able to reuse basically the content, you will need to have unique content for every viewer. The other question, however, would be - why would it really be needed? When those keys are wrapped, of course, in a DRM license, well, then it will be a unique license that will be sent to every viewer. So that does, does take away the real need there to do these kinds of things, I think. Unless if you have something to add still, Johannes.

Johannes: No, that covered it pretty well. Thank you.

I think we have a few more questions, so I think I'll just move on to the next one. That's also an interesting question:

“Are you seeing any demand or motion back towards multicast content, particularly multicast protected by one of the major OTT DRM options?”

I would not say a motion back towards multicast content, But I think we see this requirement from time to time. It's more about coexistence of DRM solutions with typical multicast conditional access systems solutions. And in that regard, there is interest in these kinds of solutions protected with DRM technologies. However, the standardization around streaming protocols and DRM has mostly focused on Unicast and the streaming protocols around Unicast. So that's perfectly standardized today and very interoperable and works really nicely.

If you're looking for a multicast solution and want that to protect that, for example, with PlayReady or Widevine, then with PlayReady, you would have to have a solution that considers this on the encryptor and on the player side and be compatible in a way so that both ends work together. So that's a tricky part here. And with Widevine, there's an exception to this because Widevine also does not only have Widevine DRM as a product, but there's also Widevine CAS, which is their bridging solution essentially between the multicast requirements and in the IPTV world where you typically have a network that is controlled and where multicast is enabled and bridging the gap to this TV Everywhere solutions based on DRM. So, there is a solution that aims for enabling that.

However, that's, of course, a Google product and works with Android TV. And that might also be something that you might want to look into. Happy to discuss this. Just reach out to me, and we can continue. Yeah, that's about that. If you want to add anything, Pieter, otherwise, we can also move to the next question.

Pieter-Jan: No, we can move to the one which Thomas asked:

“Which components in the client or which component in the client is responsible for enforcing the usage policies specified in the entitlement message?”

And actually, the answer here is pretty straightforward. The component which is responsible is actually the CDN. So, this is something that you really want to handle as close as possible with the hardware. So, this is something that the CDN, so the content decryption module is responsible for. So, these are the modules which are developed by Google, Apple, Microsoft for Widevine, Fairplay and PlayReady, or of course for other DRM flavours, if you're still using those. There are vendor there who actually built this. And it's those modules that enforce this. So, this is not something that, for example, a player does, or the application does. In order to make this tamper proof, this is really happening in the CDN itself.

And then there's another question. I don't know if you want to take it, Johannes:

“If I'm using a DRM provider and want to switch to another, does it mean that I have to re-encode my videos that were created with the first provider?”

That sounds like a fun migration question that you will probably have a very good answer for.

Johannes: Yes, we have seen this. Re-encode, repackage. Essentially, typically, the answer should be, no, you don't have to do that. The question is, do you have control, or can you get from your current DRM provider all those encryption keys? It depends a bit on how the storage of the encryption key was solved. Typically, that's inside the DRM provider's service somewhere. There is probably a service that is handing the keys out to some package component and another service that hands out the DRM licenses to end user the devices. And somewhere in between, these secrets must be stored. And the migration, one of the main pieces here is you will have to have access to those keys that were used to encrypt the content. If you have that, you can even import those and then even no repackaging is necessary. Re-encoding is typically not necessary. You might need to package the content again if you have to encrypt it again and can't get access to those keys. But that's typically something that is workable. With Axinom, for example, if you have Axinom as a service provider, you will have full control over the encryption keys and you can access those for migrating to somewhere else so that the new provider can still create licenses based on the keys that were used to encrypt the content. And I think I hope I have answered that one.

I think I will just continue directly with another one if we still have a few minutes left. So, one question came in that says:

“Interested to know about anti-screen recording DRM solution.”

So, screen recording is quite a topic. And there are different ways how to achieve it most common is the distinction between the security service level, security level one versus security level three in Widevine or 2000 and 3000 for PlayReady because that enforce a hardware backed CDN. And typically, when you have hardware backed CDN, then screen recording is not possible. Then it's an out of the box feature. So, for example, for Fairplay DRM, always have on Apple devices, you always have hardware backed CDN. Screen recording is always controlled and prohibited and not possible. In case of Widevine and PlayReady, you have these two flavours, and if you download a popular browser that contains a software only CDN, then the chances are high that screen recording is still possible with this. And to avoid this, you can enforce hardware backed DRM. Of course, it will limit your audience. So, you have to think it very well through if you want to enforce this for all content that you have or if you want to own the parts of it. And there's also one exception to this rule that in browsers like Firefox or Chrome and so on that are able to do a screen recording on desktop PCs and the Macs, not essentially on Android devices, Android devices in the Chrome browser, hardware-backed DRM is supported, you can use hardware backed CDN there and this way, protect against screen recording. But I think the Microsoft Edge browser also prevents it for PlayReady DRM. So that's also something that is covered. But other than that, desktop browsers tend to be still vulnerable against this screen recording.

Pieter-Jan: Yeah, I was just going to add that one thing which is important here, but it depends a little bit on the content that you're distributing and the requirements regarding safety that are linked to it. But something that we often see is that when people have high quality content and real premium content,  and you can even see this with Netflix and other popular streaming services, they usually limit the bandwidth and the quality, the maximum resolution that you can see when using, for example, a Chrome browser. So, if you're on a Mac, for example, if you're watching Netflix in the Chrome browser or Disney+ or any of the others, you'll actually get a lower quality compared to when you would go to the Safari browser. And the same you see on Windows, for example, as you just mentioned, Johannes, when you use PlayReady on basically when you use the Microsoft Edge browser, it will use hardware backed PlayReady, which will give you access to that higher quality. And the important thing here is that this is where doing multi-key becomes extremely important. And this is also why companies, of course, want to do multi-key. It's because they can then add a stricter entitlement policy and a stricter usage policy to those keys which are protecting the higher quality streams. So, I think that that's a very important thing to note as well when you're talking screen recording solutions.

Johannes: Yes, thanks for adding this. And I think, well, time's up. I think we had the very interesting session with interesting questions. Was really cool to be on this webinar today. And I want to thank everyone for attending. Thanks, and have a good day, evening, whatever.

Pieter-Jan: Yeah, enjoy the rest of the day, everyone. And take care!