# Real time video stream AES encryption with authentication

I am now studying AES encryption for real-time video streaming. It seems that Netflix uses the AES-GCM (or CBC + MAC) mode for real-time video encryption and authentication. With MAC authentication, the 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 wants 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. Could someone please give me some advice? 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?

AES-GCM mode requires the receiver to verify the tag before using the plaintext. Since Netflix uses SSL/TLS there is a limit of a record in SSL/TLS, see RFC-5246 section-6.2.1. The amount is given as $$2^{14}$$ bytes or less. $$2^{14}$$ bytes is just ~16 kB. This amount is easy to verify the tag and decrypt the data even the user jumps on the movie.

## 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. As mentioned in the blog, AES-CBC mode of operation requires an additional pass to generate the HMAC. AES-GCM, however, can perform encryptions and authentication the message simultaneously. This is good for the server-side for reducing the data access. With the usual numbering of the data, the server can feed the client with many records at once. On the server-side they use AES-NI, ISA-L, and BoringSSL

Note that; 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 the two technical articles from Netflix developers;

## Parameters

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

The Netflix articles don't exactly mention this. This paragraph from the article 1;

When the keys were ready, have the TLS library send them to the kernel and let the kernel do the encryption part, while all the other parts of TLS would continue to be executed by the TLS library. The TLS library would continue to frame its messages and submit framed but un-encrypted messages to the kernel.

implicitly implies that they are bound to TLS record size, $$2^{14}$$ bytes.

• 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 finally, updated. Thanks. – kelalaka Aug 15 '19 at 20:06