Adversarial Engineering

Steve Goeringer
Distinguished Technologist, Security

Jul 13, 2016

Security engineering is one of few technical endeavors in which you deal with an adversary. There are a few other domains such as electronic warfare or fire prevention. Working against an adversary in this way is like playing a twisted game of chess. As the game begins, the security engineer is aware of most of the board and most of the pieces. The attacker discovers the board and pieces as the game is played. Both players invent new rules or change old rules throughout the game without telling the other player. Either player may introduce new squares to the board, new pieces to the game, or remove them. The twisted advantage that the attacker has is that they can use the security engineer’s pieces sometimes.

Security engineering makes for a rough game. The stakes are very high. Revenue loss and brand damage to companies can be huge. Ponemon Institute released a study in June 2016 that indicates the average cost of a data breach is $4 million while the average cost per lost or stolen record is $158. Of course, the actual and incidental damages of each particular breach is unique. The largest security events impact many millions of customers. Information is Beautiful provides a fascinating interactive graphic showing the history of the world’s biggest data breaches since 2004.

All in the mindset

Ultimately, attackers hijack the intended user experience to achieve personal goals — financial gain, extortion, fame, fun, harm. How does the security engineer cope? The security engineer needs to approach work with the mindset of their adversary – the attacker. I like to call this approach adversarial engineering. An adversarial engineer focuses on how to misuse or change a service or product with an eye towards what attackers (various kinds of cyber criminals) may want to do. This way, the adversarial engineer can better integrate mitigations and controls to keep hackers out.

Tools and strategies for adversarial engineering

The adversarial engineer understands and identifies security problems by thinking offensively and creatively about how to get a network or IT resource to provide access to data that shouldn’t be available or provide functionality that isn’t intended. The adversarial engineer employs some great tools and strategies, including:

  • Threat analysis — The adversarial engineer creates models of the architecture used to provide services. Hacking techniques can then be postulated on how malcontents might try to access the network, servers, databases, and other resources used to provide services. Threat vectors are identified so they can be can be systematically addressed, ensuring each vector is faced with multiple controls and mitigations to prevent hackers from achieving their goals.
  • Misuse cases — Network and IT services are dynamic and fluid, reacting to events and changing state as users interact with resources. Service designers create use cases that define how resources should behave and be used. The adversarial engineer needs to consider these use cases and develop “misuse” cases for each one. Once misuse cases are crafted, multiple controls and mitigations are considered and integrated into the overall solution to foil bad actors from hijacking user experiences and doing unintended activities.
  • Vulnerability scanning — Even well designed services can be vulnerable. The adversarial engineer discovers what they may have missed the same way hackers might — they use a variety of tools to scan network interfaces and computer resources for vulnerabilities. Classic examples of such tools are nmap developed by Gordon Lyon, aka Fyodor VaskovichMetasploit developed by HD Moore (now available from Rapid7), and Nessus (from Tenable Network Security). There are dozens of other tools available, sometimes packaged into entire environments such as Kali Linux (offered by Offensive Security). Some very advanced scanners look for completely new kinds of vulnerabilities using code analysis or by performing fuzzing.
  • Penetration testing — Once vulnerabilities are discovered, the engineer needs to go one more step. They need to find how vulnerabilities might be exploited by doing penetration testing. This is where the craft of adversarial engineering can get deeply technical. Hand crafted investigation is often applied. However, many penetration testing tools are packaged in the same environments as mentioned above under vulnerability scanning.
  • Pervasive monitoring — Not all intrusions can be stopped – the Internet, by nature and design, is a fairly open environment. Pervasive monitoring keeps tabs on services and their associated resources, continually watching to ensure that things are being used as expected and performing as designed. This helps to minimize the time intruders are in systems or networks and potentially decrease the damage done by intrusions. Often, hackers will find vulnerabilities that were not discovered by the adversarial engineer and new controls and mitigations will be integrated into the service infrastructure.

Mitigations and controls

What are the mitigations and controls that adversarial engineers consider? There are literally hundreds. The US government identifies over 300 fundamental controls in the NIST Special Publication 800-53, Security and Privacy Controls for Federal Information Systems and Organizations (“800-53”). There are several families of controls, summarized from 800-53 in the table below. Not all of these are applicable to commercial services, and commercial services often need more than what is applied by the government. A more concise list is maintained by the Center for Internet Security, CIS. These provide a minimum framework for effective cyber defense and are available at the Center for Internet Security website.



Figure 1: NIST 800-53 security control identifiers and family names

Applications must be considered as well. A good starting point is the Open Web Application Security Project (OWASP) who, similar to CIS, maintains a top 10 list as well.

The challenge in applying network and application controls is achieving defense in depth. Achieving a robust security strategy requires deploying controls and mitigations in multiple dimensions — in line, at multiple layers, and even in time. The adversarial engineer assumes controls may be compromised, so they will try to contain or at least slow perpetrators so they can be recognized and stopped.

Pervasive monitoring enables an agile operations strategy referred to as “kill-chains”. This is a “special forces”-inspired approach where you design multiple areas in your strategy where adversaries can be monitored, intercepted, and stopped. The idea was initially documented by Lockheed Martin to proactive detect and respond to persistent threats. Today, this is an increasingly applied strategy to provide an agile response to the ever-evolving tactics and strategies of hackers.

Its not ALL about bad actors

Network equipment fails. Applications do not always behave as designed. Mistakes are made. Sometimes, network attackers will at least partially succeed. Consequently, good networks are actually designed to fail well. The adversarial engineer also considers how resilient the network and security controls must be to achieve design goals. Systems and software will be deployed redundantly, sometimes to extreme levels, so that if something does fail, it doesn’t completely take down services. And, because things do break in the real world, graceful recovery after disruptions and outages must be designed.

What about CableLabs?

CableLabs ensures cable operators have multiple tools to apply adversarial engineering practices. For example,

  • DOCSIS® technology includes three areas of control and mitigation: authentication, encryption, and integrity. And, DOCSIS implementations allow for controls both in the network and also at the home or business.
  • CableLabs is developing new specifications that also provide for secure devices in the home, including access points, home routers, and even IoT devices.
  • CableLabs is developing extremely high speed wireless environments to extend the reach of network operators into communities, cities, and campuses, and security is a core consideration of these emerging technologies.
  • CableLabs is considering new ways to secure applications and hardware in virtualized environments and clouds.

Security engineering is challenging given the adversarial nature of the Internet and cable technology is meeting that challenge.

Technical Blog

Content Creation Demystified: Open Source to the Rescue

CableLabs Admin

Jun 9, 2015

There are four main concepts involved in securing premium audio/visual content:

  1. Authentication
  2. Authorization
  3. Encryption
  4. Digital Rights Management (DRM)

Authentication is the act of verifying the identity of the individual requesting playback (e.g. username/password). Authorization involves ensuring that individual’s right to view that content (e.g. subscription, rental). Encryption is the scrambling of audio/video samples; decryption keys (licenses) must be acquired to enable successful playback on a device. Finally, DRM systems are responsible for the secure exchange of encryption keys and the association of various “rights” with those keys. Digital rights may include things such as:

  • Limited time period (expiration)
  • Supported playback devices
  • Output restrictions (e.g. HDMI, HDCP)
  • Ability to make copies of downloaded content
  • Limited number of simultaneous views

This article will focus on the topics of encryption and DRM and describe how open source software can be used to create protected, adaptive bitrate test content for use in evaluating web browsers and player applications. I will close this article by describing the steps for how protective streams can be created.

One Encryption to Rule Them All

Encryption is the process of applying a reversible mathematical operation to a block of data to disguise its contents. Numerous encryption algorithms have been developed, each with varying levels of security, inputs and outputs, and computational complexity. In most systems, a random sequence of bytes (the key) is combined with the original data (the plaintext) using the encryption algorithm to produce the scrambled version of the data (the ciphertext). In symmetric encryption systems, the same key used to encrypt the data is also used for decryption. In asymmetric systems, keys come in pairs; one key is used to encrypt or decrypt data while its mathematically related sibling is used to perform the inverse operation. For the purposes of protecting digital media, we will be focusing solely on symmetric key systems.

With so many encryption methods to choose from, one could reasonably expect that web browsers would only support a small subset. If the sets of algorithms implemented in different browsers do not overlap, multiple copies of the media would have to be stored on streaming servers to ensure successful playback on most devices. This is where the ISO Common Encryption standards come in. These specifications identify a single encryption algorithm (AES-128) and two block chaining modes (CTR, CBC) that all encryption and decryption engines must support. Metadata in the stream describes what keys and initialization vectors are required to decrypt media sample data. Common Encryption also supports the concept of “subsample encryption”. In this situation, unencrypted samples are interspersed within the total set of samples and Common Encryption metadata is defined to describe the byte offsets where encrypted samples begin and end.

In addition to encryption-based metadata, Common Encryption defines the Protection Specific System Header (PSSH). This bit of metadata is an ISOBMFF box structure that contains data proprietary to a particular DRM that will guide the DRM system in retrieving the keys that are needed to decrypt the media samples. Each PSSH box contains a “system ID” field that uniquely identifies the DRM system to which the contained data applies. Multiple PSSH boxes may appear in a media file indicating support for multiple DRM systems. Hence, the magic of Common Encryption; a standard encryption scheme and multi-DRM support for retrieval of decryption keys all within a single copy of the media.

The main Common Encryption standard (ISO 23001-7) specifies metadata for use in ISO BMFF media containers. ISO 23001-9 defines Common Encryption for the MPEG Transport Stream container. In many cases, the box structures defined in the main specification are simply inserted into MPEG TS packets in an effort avoid introducing completely new structures that essentially hold the same data.

Creating Protected Adaptive Bitrate Content

CableLabs has developed a process for creating encrypted MPEG-DASH adaptive bitrate media involving some custom software combined with existing open source tools. The following sections will introduce the software and go through the process of creating protected streams. These tools and some accompanying documentation are available on GitHub. A copy of the documentation is also hosted here.

EME Content Tools

Adaptive Bitrate Transcoding

The first step in the process is to transcode source media files into several, lower bitrate versions. This can be simply reducing the bitrate, but in most cases the resolution should be lowered. To accomplish this, we use the popular FFMpeg suite of utilities. FFMpeg is a multi-purpose audio/video recorder, converter, and streaming library with dozens of supported formats. An FFMpeg installation will need to have the x264 and fdk_aac codec libraries enabled. If the appropriate binaries are not available, it can be built .

CableLabs has provided an example script that can be used as a guide to generating multi-bitrate content. There are some important items in this script that should be noted.

One of the jobs of an ABR packager is to split the source stream up into “segments.” These segments are usually between 2 and 10 seconds in duration and are in frame-accurate alignment across all the bitrate representations of media. For bitrate switching to appear seamless to the user, the player must be able to switch between the different bitrate streams at any segment boundary and be assured that the video decoder will be able to accept the data. To ensure that the packager can split the stream at regular boundaries, we need to make sure that our transcoder is inserting I-Frames (video frames that have no dependencies on other frames) at regular intervals during the transcoding process. The following arguments to x264 in the script accomplish that task:

[highlighter line=0]

-x264opts "keyint=$framerate:min-keyint=$framerate:no-scenecut"

We use the framerate detected in the source media to instruct the encoder to insert new I-Frames at least once ever second. Assuming our packager will segment using an integral number of seconds, the stream will be properly conditioned. The no-scenecut argument tells the encoder not to insert random I-Frames when it detects a scene change in the source material. We detect the framerate of the source video using the ffprobe utility that is part of FFMpeg.

framerate=$((`./ffprobe $1 -select_streams v -show_entries stream=avg_frame_rate -v quiet -of csv="p=0"`))

At the bottom of the script, we see the commands that perform the transcoding using bitrates, resolutions, and codec profile/level selections that we require.

transcode_video "360k" "512:288" "main" 30 $2 $1
transcode_video "620k" "704:396" "main" 30 $2 $1
transcode_video "1340k" "896:504" "high" 31 $2 $1
transcode_video "2500k" "1280:720" "high" 32 $2 $1
transcode_video "4500k" "1920:1080" "high" 40 $2 $1

transcode_audio "128k" $2 $1
transcode_audio "192k" $2 $1

For example, the first video representation is 360kb/s with a resolution of 512x288 pixels using AVC Main Profile, Level 3.0. The other thing to note is that the script transcodes audio and video separately. This is due to the fact that the DASH-IF guidelines forbid multiplexed audio/video segements (see section 3.2.1 of the DASH-IF Interoperability Points v3.0 for DASH AVC/264).


Next, we must encrypt the video and/or audio representation files that we created. For this, we use the MP4Box utility from GPAC. MP4Box is perfect for this task because it supports the Common Encryption standard and is highly customizable. Not only will perform AES-128 CTR or CBC mode encryption, but it can do subsample encryption and insert multiple, user-specified PSSH boxes into the output media file.

To configure MP4Box for performing Common Encryption, the user creates a “cryptfile”. The cryptfile is an XML-based description of the encryption parameters and PSSH boxes. Here is an example cryptfile:

The top-level <GPACDRM> element indicates that we are performing AES-128 CTR mode Common Encryption. The <DRMInfo> elements describe the PSSH boxes we would like to include. Finally, a single <CrypTrack> elements is specified for each track in the source media we would like to encrypt. Multiple encryption keys for each track may be specified, in which case the number of samples to encrypt would be indicated with a single key before moving to the next key in the list .

Since PSSH boxes are really just containers for arbitrary data, MP4Box has defined a set of XML elements specifically to define bitstreams in the <DRMInfo> nodes. Please see the MP4Box site for a complete description of the bitstream description syntax.

Once the cryptfile has been generated, you simply pass it as an argument on the command line to MP4Box. We have created a simple script to help encrypt multiple files at once (since you may most likely be encrypting each bitrate representation file for your ABR media).

Creating MP4Box Cryptfiles with DRM Support

In any secure system, the keys necessary to decrypt protected media will most certainly be kept separate from the media itself. It is the DRM system’s responsibility to retrieve the decryption keys and any rights afforded to the user for that content by the content owner. If we wish to encrypt our own content, we will also need to ensure that the encryption keys are available on a per-DRM basis for retrieval when the content is played back.

CableLabs has developed custom software to generate MP4Box cryptfiles and ensure that the required keys are available on one or more license servers. The software is written in Java and can be run on any platform that supports a Java runtime. A simple Apache Ant buildfile is provided for compiling the software and generating executable JAR files. Our tools currently support the Google Widevine and Microsoft PlayReady DRM systems with a couple of license server choices for each. The first Adobe Access CDM is just now being released in Firefox and we expect to update the tools in the coming months to support Adobe DRM. Support for W3C ClearKey encryption is also available, but we will focus on the commercial DRM systems for the purposes of this article.

The base library for the software is CryptfileBuilder. This set of Java classes provides abstractions to facilitate the construction and output of MP4Box cryptfiles. All other modules in the toolset are dependent upon this library. Each DRM-specific tool has detailed documentation available on the command line (-h arg) and on our website.

Microsoft PlayReady Test Server

The code in our PlayReady software library provides 2 main pieces of functionality:

  1. PlayReady PSSH generator for MP4Box cryptfiles
  2. Encryption key generator for use with the Microsoft PlayReady test license server.

Instead of allowing clients to ingest their own keys, the license server uses an algorithm based on a “key seed” and a 128-bit key ID to derive decryption keys. The algorithm definition can be found in this document from Microsoft (in the section titled “Content Key Algorithm”). Using this algorithm, the key seed used by the test server, and a key ID of our choosing, we can derive the content key that will be returned by the server during playback of the content.

Widevine License Portal

Similar to PlayReady, our Widevine toolset provides a PSSH generator for the Widevine DRM system. Widevine, however, does not provide a generic test server like the one from Microsoft. Users will need to contact Widevine to get their own license portal on their servers. With that portal, you will get a signing key and initialization vector for signing your requests. You provide this information as input to the Widevine cryptfile generator.

The Widevine license server will generate encryption keys and key IDs based on a given “content ID” and media type (e.g. HD, SD, AUDIO, etc). Their API has been updated since our tools were developed and they now support ingest of “foreign keys” that our tool could generate itself, but we don’t currently support that.


The real power of Common Encryption is made apparent when you add support for multiple DRM systems in a single piece of content. With the license servers used in our previous examples, this was not possible because we were not able to select our own encryption keys (as explained earlier, Widevine has added support for “foreign keys”, but our tools have not been updated to make use of them). With that in mind, a new licensing system is required to provide the functionality we seek.

CableLabs has partnered with CastLabs to integrate support for their DRMToday multi-DRM licensing service in our content creation tools. DRMToday provides a full suite of content protection services including encryption and packaging. For our needs, we only rely on the multi-DRM licensing server capabilities. DRMToday provides a REST API that our software uses to ingest Common Encryption keys into their system for later retrieval by one of the supported DRM systems.

MPEG-DASH Segmenting and Packaging

The final step in the process is to segment our encrypted media files and generate a MPEG-DASH manifest (.mpd). For this, we once again use MP4Box, but this time we use the -dash argument. There are many options in MP4Box for segmenting media files, so please run MP4Box -h dash to see the full list of configurations.

For the purposes of this article, we will focus on generating content that meets the requirements of the DASH-IF DASH-AVC264 “OnDemand” profile. Our repository contains a helper script that will take a set of MP4 files and generate DASH content according to the DASH-IF guidelines. Run this script to generate your segmented media files and produce your manifest.

Greg Rutz is a Lead Architect at CableLabs working on several projects related to digital video encoding/transcoding and digital rights management for online video.

This post is part of a technical blog series, "Standards-Based, Premium Content for the Modern Web".