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?
updated per comments;
Currently Netflix Uses AES-GCM


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&gt; 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


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


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;

Optimizing TLS for High–Bandwidth Applications in FreeBSD
Improving High–Bandwidth TLS in the FreeBSD kernel.


Parameters


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.