1

The documents just don't seem to provide an answer..

Microsoft tried to explain the subject clearly, but it is still ambiguous. At least in our case.

We have an encrypted MP4 stream. It contains "SampleEncryptionBox"es or "PIFF" boxes, which contain 8-byte = 64-bit Initialization Vectors for encrypted blocks. BUT: The actual "counter block" for decrypting the "AES-128 Counter Mode"-encrypted video data is 128-bit. I don't know where exactly to put the IV in it!!

  • PIFF document says 16-byte IV is the entire counter block (obviously) for AES-CTR mode. Also, 8-byte IV is put at the beginning of the counter block, for AES-ECB mode (page 17). But for 8-byte IV in AES-CTR mode, it says nothing!

  • This RFC document says that the 128-bit should comprise 4-byte Nonce + 8-byte IV + 4-byte counter. And the Nonce value should be taken from the extra 4 bytes supplied for the main 128-bit AES key. I can only obtain the 128-bit key by the Protection Header, where should I get the 4-byte Nonce??

Any bit of extra knowledge will be highly appreciated.

Community
  • 1
  • 1
uluorta
  • 133
  • 1
  • 8

2 Answers2

1

Try NIST SP 800-38A instead, section B.2. Note that this document is the first one that is referenced by the Microsoft document:

A second approach to satisfying the uniqueness property across messages is to assign to each message a unique string of b/2 bits (rounding up, if b is odd), in other words, a message nonce, and to incorporate the message nonce into every counter block for the message. The leading b/2 bits (rounding up, if b is odd) of each counter block would be the message nonce, and the standard incrementing function would be applied to the remaining m bits to provide an index to the counter blocks for the message. Thus, if N is the message nonce for a given message, then the jth counter block is given by Tj = N | [j]m, for j = 1...n. The number of blocks, n, in any m message must satisfy n < 2 . A procedure should be established to ensure the uniqueness of the message nonces.

Note that you would need 2 ^ 64 blocks of data to get to the next "message nonce" or IV. This is just a sample method of generating a counter; unfortunately NIST does the bad habbit of not specifying any default ones. So it depends on the protocol as well, but above is most common.

Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263
1

Ok, I found the explanation.. It is written clearly in "ISO/IEC JTC 1/SC 29 N" document.

If the IV_size field is 8, then its value is copied to bytes 0 to 7 of the InitializationVector and bytes 8 to 15 of the InitializationVector are set to zero. The IV_size field shall not be 0 when the IsEncrypted flag is 0x1.

AES-ECB Mode has nothing to do with it.

uluorta
  • 133
  • 1
  • 8