2.1.1.2.5.6 Other Content Types
Content that is not encapsulated in MPEG-2 TS packets, is not in MPEG-2 elementary streams, and is not Windows Media-based, MUST be encrypted using the link encryption mode that is specified in section 3.1.5.2.11.
The encrypted data segments MUST be sent over HTTP using the Framing Headers mechanism as defined in section 2.1.1.2.1.
The link encryption procedure MUST use Advanced Encryption Standard (AES) [FIPS197] in counter mode. The procedure also MUST be conducted as defined in section 3.1.5.2.1. The data segment corresponds to the content data included within a single framing header.
A data segment descriptor MUST be included at the beginning of each frame. Both the key ID and the AES128 initialization vector extensions that are defined in section 3.1.5.2.3 MUST be included in the data segment descriptor. Transmitters MUST use a block ID of 0 for each frame. However, receivers MUST be able to handle different block ID values for future extensibility.
The data segment descriptor MUST be inserted immediately after the framing header, yet the data segment descriptor itself MUST NOT be encrypted. Only the content data that follows it can be encrypted.
Since a frame can only carry a maximum of 65535 bytes, the combined size of the data segment and the data segment descriptor MUST NOT exceed this limit.
The data segment descriptor MUST be added to the beginning of each frame and is present regardless of whether the content in a particular frame has been encrypted. Transmitters MUST encrypt all content; however, receivers MUST be able to handle unencrypted content for future extensibility.
Because the entity-body of the response to the GET request uses the HTTP framing header mechanism (section 2.1.1.2.1), control frames are interleaved with data frames, allowing the transmitter to perform the license update procedure as needed.