0

What does the storage data I/O and decryption process look like in a device encryption context when you play a random middle portion of a big movie file (e.g. 50 GB). Does the whole file have to be decrypted first?

BACKGROUND

I am afraid I understand very little about either encryption or (unencrypted) video file I/O and cannot phrase the question in a highly informed way.

But I imagine that, when I load a 2 hr movie file and take the pointer to the 1:00:00 point, the player app goes directly to the right point, whether by means of some markers or some calculation (based on frame rate etc.). But if the file is encrypted, such markers or other information would be unavailable to the player app and would only become available when the whole file has been decrypted? The player app might request such decryption and get it (before it can start playing), but I suspect this would be inefficient and probably not how it is done. (A small device may not have 50 GB of RAM to hold the decrypted file and may have to write it to storage.) It is possible that the problem that I imagine does not even arise because it is based on a misunderstanding (from my experiences of using things like 7zip to encrypt and decrypt, which should be no model for understanding device encryption).

I do not know if the answer depends on encryption type. I would like an answer that explains generally applicable principles. But if a more specific question is desirable please choose one of these for your answer: Android, iOS, or Veracrypt.

In general, if in spite of the way the post currently stands there is a beginning of a substantive question in it, please feel free to edit and improve it.

2 Answers 2

1

That depends entirely on the encryption mode and video container format used.

Regarding the Video Container Format

You see, a computer playing back a video file doesn't see the video file in the same way a person does. People think of a video file as having some length in seconds, whereas computers think of files in terms of bytes. Unfortunately, these two don't correspond 1:1. That means, someone trying to jump to the middle of the video doesn't mean a computer can just jump to the middle of the file and begin reading.

The way some video container formats work is by prepending a so-called index. In simple terms, it's a dictionary, linking specific timestamps to byte indices in the file.

For example, if the user wants to access the timestamp 00:43:27, the index is consulted for the closest previous timestamp. Say, the closest is 00:43:27, which corresponds to byte 721,660,832. The video player can then go through each frame from 00:43:20 to 00:43:27. So instead of parsing half the video file, one "big" jump can be made, and then only a couple of seconds worth of frames need to be parsed.

So in order to create an encrypted stream format, you would need some form of index, which is always accessible. This wouldn't be that much of an issue in terms of confidentiality, as merely knowing how long a video file is and which timestamp corresponds to which ciphertext block doesn't give you any information about the contents.

Regarding the Encryption Mode

An encryption mode determines how the blocks are interlinked with each other. The simplest way is so-called "ECB", also known as Electronic Codebook Mode. This method is generally considered insecure, as it allows an attacker make pretty good guesses about the contents of the file. How good? Well, you'll never guess what the contents of this picture are:

ECB Penguin

Source: https://blog.filippo.io/the-ecb-penguin/

So while ECB would allow you to independently decrypt each block, this isn't quite what you want. Luckily, there are other options. If you think about it, hard drive encryption is a very similar problem - you want to decrypt the sectors as you need them, not decrypt an entire 4 Terabyte worth of disk.

One possible encryption mode is XST, also known as "Xor–encrypt–Xor with Cipher Text Stealing". Explaining this mode is beyond the scope of this answer, but Wikipedia's article on Disk Encryption Theory explains that pretty well.

Do I have to implement this all myself?!

No, luckily not! You're not the first person to want to stream some encrypted video content. Netflix had this problem before, and they found a solution: MPEG-DASH, also known as "Dynamic Adaptive Streaming over HTTP (DASH)". MPEG-DASH can employ the Encrypted Media Extensions, which is built into most modern browsers, to decrypt streams on-the-fly. It means your application doesn't need to worry about all of the complicated stuff I mentioned previously.

While I personally hate EME with a burning passion for a variety of reasons, it is a possible solution for your problem, and it could be worth looking into that further.

1

Encrypting a payload of fixed length is usually a use case for Block Ciphers. A Block Cipher is used to divide the payload into a set of fixed-length blocks which are encrypted individually (it is a really bad approach to just encrypt each block with the same key individually, as the same input leads to the same ciphertext, see Modes of Operation for more information). In practice certain blocks' ciphers are taken as input to decrypt another block, resulting in a single ciphertext for the whole input with little insight on how the individual blocks initially looked like.

As you correctly pointed out, this is infeasible for streaming scenarios as you can't grab certain blocks and decrypt them (unless you are using the not recommended approach of encrypting blocks individually). Thus, Stream Ciphers are used to encrypt a payload of arbitrary length. The general approach is to produce a keystream which serves as an arbitrary length key, that encrypts the input bitwise. With knowledge about how the keystream is produced, you can now jump to an arbitrary cursor inside your input stream and start decrypting the bits form that starting point. I highly recommend Dr. Pounds elaborations on the topic as well.

2
  • Thank you. A followup question on "With knowledge about how the keystream is produced." Would this knowledge be highly specific to the file type? E.g. would the decryption engine (or whatever is responsible for decrypting/feeding the right portion to the player app) have to know, "This is a movie file at 24 fps; so 1:00:00 means that point in the encrypted data." I can imagine this becoming quickly impractical because the person creating the engine would have to take into account thousands of file types.
    – Catomic
    Nov 8, 2021 at 9:20
  • Unfortunately, I am not too familiar with how specific implementation apply this in practice. Generally I would assume that it is the application layers task to determine a suitable key frame of the requested timestamp to retrieve and settle information like compression format, resolution and fps in prior with the client until the actual raw data is encrypted and streamed through the wire. The client obviously need too know how to process the information.
    – Beltway
    Nov 8, 2021 at 9:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.