# Real time video stream AES encryption with authentication

I am now studying the AES encryption for real-time video stream. It seems that Netflix uses the AES-GCM (or CBC + MAC) mode for real-time video encryption and authentication. With MAC authentication, client can only get the MAC message after the whole video is encrypted and authenticated. After that, the client can verify and play the video. However, if the client want to play the video immediately (without receiving and decrypting the whole video), how can the client verify the MAC message?

I guess the video stream may be divided into many small slices. The server will encrypt and authenticate those slices one by one. At the receiving side, the client will verify, decrypt and play slice_1, then slice_2 ,then slice_3 and so on.

I am not sure whether my guess is right. Can any one give any advise? How does the real video provider's server do this kind of secure video stream transmission? If my guess is right, what is the typical size of video slices, or it is dynamic?

• You could easily observe the size of TLS records on actual connection(s) of interest, although that doesn't prove it's the same elsewhere. – dave_thompson_085 Nov 9 '18 at 6:28

## Currently Netflix Uses AES-GCM

1. I am now studying the AES encryption for real-time video stream. It seems that Netflix uses the AES-GCM (or CBC + MAC) mode for real-time video encryption and authentication.

2. With MAC authentication, client can only get the MAC message after the> whole video is encrypted and authenticated. After that, the client can only get the MAC message after the whole video is encrypted and authenticated.

This blog post, posted on Aug 8, 2016 by Netflix, mentions that;

Cipher Evaluation We evaluated available and applicable ciphers and decided to primarily use the Advanced Encryption Standard (AES) cipher in Galois/Counter Mode (GCM), available starting in TLS 1.2. We chose AES-GCM over the Cipher Block Chaining (CBC) method, which comes at a higher computational cost. The AES-GCM cipher algorithm encrypts and authenticates the message simultaneously — as opposed to AES-CBC, which requires an additional pass over the data to generate keyed-hash message authentication code (HMAC). CBC can still be used as a fallback for clients that cannot support the preferred method.

We needed to determine the best implementation of AES-GCM with the AES-NI instruction set, so we investigated alternatives to OpenSSL, including BoringSSL and the Intel Intelligent Storage Acceleration Library (ISA-L).

## How AES-GCM enables immediate playing

1. However, if the client wants to play the video immediately (without receiving and decrypting the whole video), how can the client verify the MAC message?

As mentioned in the blog, AES-CBC mode of operation requires an additional pass to generate the HMAC. Since the integrity must be performed on the whole data, the user must download all the data. Therefore, they preferred the AES-GCM over the AES-CBC.

AES-GCM is GCM mode of operation with AES. In very short, it uses AES in counter mode, with authentication.

For simplicity, an initial counter block ICB, used as plaintext for the encryptions.

$$Y_i = X_i \oplus Enc_K(ICB_i).$$

• This is the part that can be executed in parallel, whereas in AES-CBC there is no parallelization.
• If you have more than one core, each core can execute AES-NI independently. Each $$X_i$$ with $$ICB$$ can be sent to calculate $$Y_i$$ in parallel.

AES-GCM hash two kinds of hashes to verify the data

1. The hash of each block
2. A Final Hash $$T$$ that is defined to authenticate all of the data.

For the hash part, a block hash with key is used in chaining mode. $$Y_i = ( Y_{i-1} \oplus X_i ) \cdot H,$$ where the dot is multiplication in $$GF(2^{128})$$.

While the ACM-GCM standard only returns the Final Hash $$T$$. The server can send each hash to verify current blocks, this is really implementation problem if you see a benefit.

If the locally calculated $$T_{local}$$ is not equal to incoming $$T_{inc}$$, re-request current blocks data.

See : Nist 800-38D documentation for more details.

## Server Side

1. I am not sure whether my guess is right. Can anyone give any advise? How does the real video provider's server do this kind of secure video stream transmission?

Netflix used AES-CBC now AES-GCM. They developed a special TLS;

To retain the benefits of the sendfile model while adding TLS functionality, we designed a hybrid TLS scheme whereby session management stays in the application space, but the bulk encryption is inserted into the sendfile data pipeline in the kernel. This extends sendfile to support encrypting data for TLS/SSL connections.

see 1,2.

## Parameters

1. If my guess is right, what is the typical size of video slices, or it is dynamic?

This question is an implementation issue depend on the video container, bandwith, buffersize,... etc. There are two technical articals from netflix 1,2 that doesn't mention about this question.

• I've now read this answer three times, and I still have trouble understanding it. I've even trouble identifying which part I don't get. "For simplicity, an initial counter block ICB, used as plaintext for the encryptions." is this a sentence? $Y_i$ is given by two definitions, do you maybe mean $Y_0$ for the initial block? What do you mean with "before the final hash value $T$? Is this answer specific to video streaming or just an explanation of GCM? – Maarten Bodewes Oct 9 '18 at 13:54
• Let me check the answer, I' gave how AES-GCM can be parallel, the other issue, the typical size of video slices, or it is dynamic? is out of subject here, right? – kelalaka Oct 9 '18 at 14:06
• Both AES-GCM and AES+HMAC require receiver to verify before using the plaintext, but for SSL/TLS (and thus HTTPS) data is broken into records not exceeding 2^14 bytes which are encrypt-and-MACed separately; see 6.2.1 in RFC 5246 et pred, and 5.1 in RFC 8446. The first paper you cite mentions the need for TLS 'framing' but without giving specifics. SSL/TLS never sends any partial authenticator for either HMAC or GCM. – dave_thompson_085 Nov 9 '18 at 6:26
• @dave_thompson_085 thank you. I'll update the answer. – kelalaka Nov 9 '18 at 13:36