Encryption and ATSC 3.0

Recently there’s been a lot of chatter about ATSC 3.0 broadcasts going encrypted in the not-too-distant future. We’ve actually been hearing murmurs about this for quite a while, however what seems to have set things into a flurry is a notice from Nuvyyo (i.e. Tablo) indicating that their much-anticipated ATSC 3.0 version of Tablo is being delayed – because they need to implement A3SA. A3SA is the security architecture for handling encrypted ATSC 3.0 broadcasts. Apparently Nuvyyo learned a number of broadcasters were going to flip the encryption switch at the end of summer, and (kudos to them) elected not to release a product which wouldn’t handle those encrypted services.

(Now you actually can receive and watch an encrypted service due to the way ATSC 3.0 and common encryption works.  It won’t exactly be what you expect, but the psychedelic melange of greens and fuschias can be quite, well, entertaining in its own right…)

Why are broadcasters doing it?

Quite simply, content owners want to prevent piracy. Quite a bit of sweat and and cash goes into producing shows and its somewhat understandable that networks and studios will want to recoup that. They could license the content to third parties – either to networks who want to broadcast it (perhaps years) later, or streaming services. The shows could also sit in their owners’ VOD catalogues which may themselves be either of the free/ad-supported variety or behind a more traditional paywall.

So what does this mean for viewers?

If all you want to do is watch live TV – or even recorded TV – linearly then you should see no difference. Your TV or ATSC 3.0 receiver will need a software update to enable A3SA security and all should be right with the world.

Things start to get a little more interesting for receiver/device makers once the receiver starts manipulating the content. For example trick modes. Fast forward and rewind aren’t generally done by shoving the show down the playback pipe at 10x or 100x (not to mention that the player would be rather confused if you sent it backwards!). Instead select frames are sent to the player to provide the illusion of fast-forward or reverse. It is probable that this can be achieved with A3SA (and we have some ideas around that for Project Entangle, though it means implementing a new, dedicated pipeline just for ATSC 3.) This issue doesn’t apply to a single jump – for example a 10 second jump backwards “instant replay” or 30 second forward “commerce skip.” You’re still watching the show linearly in these cases, even if in “linear segments.”

Where things hit the proverbial fan is where a receiver manipulates the decrypted stream. For example ATSC 3.0 is unique (to put it kindly) in using an fMP4-based container rather than the MPEG-2 transport stream. A natural approach to allowing existing software and hardware architectures to work is to “re-container” from fMP4 to MPEG-2 TS. (It’s possible to preserve all of the features in 3.0 such as A/344 interactivity. We’ve actually done this in Project Entangle.). However fMP4 to MPEG-2 TS conversion must be done on the decrypted stream (due to Annex B conversion).

Another aspect which has somewhat larger implications are applications which manipulate the decrypted and uncompressed video. There are any number of reasons to do this. The original Tablos for example didn’t record shows as-broadcast. They would instead store a transcoded version – which involves decoding and re-encoding the video. There are pluses and minuses to this approach (you save on hard drive space and certain technical aspects like bitrates can be managed. However transcoding can reduce quality as well.)

Once a receiver starts manipulating the decrypted (and perhaps uncompressed) stream a window is opened for bad actors (i.e. pirates) to steal that stream. So any part of the system – either hardware or software – that manipulates the decrypted stream needs an adequate level of security surrounding it. Having worked on securing platforms we can say this is non-trivial and likely outside the scope of open-source type projects and would even give pause to commercial entities. Just think CableCard. Its intent was to open up cable systems to third party receiver manufacturers. Devices would interact with the CableCard – which end customers would get from their cable company – to decrypt the broadcast. The result wasn’t exactly a flood of receivers and the platform security requirements and certification weren’t exactly trivial.

For our own Project Entangle, A3SA will likely remain out of scope – which means (even if we implement a new ATSC 3.0-specific trick play pipeline) out-of-home streaming will not be available for 3.0 sources. The as-broadcast bitrate is simply not suitable for out-of-home streaming, and adaptive bitrate (which implies transcoding) is a necessity for handling fluctuations in internet bandwidth. Another casualty will be support for devices which cannot handle HEVC. H.264 is a lowest-common-denominator in the mobile space. While newer devices can handle H.265/HEVC, many older devices such as the iPad Mini 1 do not. But they make for great small “TVs” you can place on your desk or the kitchen counter. Lastly, a not-so-obvious benefit of transcoding is management of bitstream errors. OTA-received content will inevitably contain errors. Sometimes quite a bit. Decoders in mobile devices tend not to handle these well and we’ve often seen them crash or behave in other undesirable ways. This isn’t terribly surprising since the broadband content they’re intended to consume arrives error-free. If not always in a timely manner. To bridge the broadcast-broadband gap an appropriately chosen transcoder can handle impaired signals (just as TVs and set-top boxes do) during decoding, apply error concealment to attempt to mask undesirable video artifacts, and then encode the resulting video into a fully compliant bitstream acceptable to any decoder.

So the general effect is that encryption may stifle innovation in receivers/gateways and limit the players who will innovate to those able to secure their platforms.  Oddly it may turn out that viewers may find ATSC 1.0 “superior” to ATSC 3.0 when it comes to how and where content is consumed.

We still hold out some small sliver of hope that broadcasters will deploy A3SA for high value or value-added services and not those which are presently broadcast free and in the clear as ATSC 1.0. For example if a broadcaster were to carry ESPN or HBO it would be appropriate – and arguably expected – that it would be protected. And it wouldn’t be surprising if they were behind a paywall just as they are for other delivery methods such as cable or streaming. Similarly it would not e surprising if new service and revenue opportunities such as datacasting were protected. And one could argue that if a broadcaster were to provide a 4K premium offering via SHVC that an ATSC 1.0 base layer should remain free and clear while the enhancement layer would be protected, and possibly behind a paywall.

A last thing to keep in mind is that A3SA content protection is coming at a time when content owners are rethinking their strategies as they consider their own streaming services. A recent example is Disney’s decision to move Dancing With the Stars from broadcast to Disney+ and raises a question of the type of content we will see in OTA TV in the years to come.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.