R.1 Encryption and Transport of Protected PSS Streams

26.2343GPPProtocols and codecsRelease 17Transparent end-to-end Packet-switched Streaming Service (PSS)TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

R.1.1 Overview

Streaming of content protected PSS streams according to this specification uses ISMACryp 2.0 [102] which is backward compatible to ISMACryp 1.1 [101]. Streaming content is either directly encrypted using content keys provided by a DRM system, or optionally with traffic keys transported in an additional key stream. This specification defines a mapping for traffic keys transported using the OMA BCAST Short Term Key Messages (STKM) format [103].

R.1.2 Stream format

RTP streaming of PSS content protected according to this specification shall use ISMACryp 2.0 [102] as detailed further in this clause, i.e. by encrypting elementary audio and video Access Units (AUs).Each encrypted AU has an ISMACrypContextAU as defined in [102].

R.1.3 Encryption

R.1.3.1 Encryption Algorithm

The encryption algorithm shall be AES (Advanced Encryption Standard) with 128 bit key size in counter mode, i.e., AES_CTR_128 as defined in [102]. Note that this is the default cipher mode of ISMACryp and that it is not recommended to signal it in the SDP according to [102]. Other encryption algorithms, key sizes or chaining modes shall not be used.

Note that ISMACryp counter mode increases the counter for each byte of data by one, i.e., the counter is increased by 16 for each block of 128 bits.

To allow for storage in file formats that do not support a salt key, the ISMACryp salt key k_s [102] should be zero. Note that this is the default value and that it is not recommended to signal this in the SDP.

R.1.3.2 Content encryption using a single key

All individual AUs of a PSS stream may be encrypted directly with a single content key, provided by a DRM system [out of scope of this specification] or alternatively signalled within the SDP, and used as encryption key according to [102]. A client implementing this specification shall support direct encryption of the AUs with a single content key. If no key stream is signalled in the SDP for a media stream, the client shall assume that direct encryption with a single content key is used.

For direct encryption, ISMACrypKeyIndicatorLength shall be equal to zero. Note that this is the default value for ISMACryp and that it is not recommended to signal it in the SDP according to [102].

R.1.3.3 Content encryption using a key stream

AUs may be encrypted with Traffic Keys transported in Key Messages in an additional key stream. Support for this mode is optional for clients implementing this specification. Key Messages, if used, shall use the OMA BCAST Short Term Key Messages (STKM) format for the OMA BCAST DRM profile as described in Section 5.5 of [103], with the following restrictions:

– traffic_protection_protocol shall be set to TKM_ALGO_ISMACRYP

– traffic_authentication_flag should be set to TKM_FLAG_FALSE

– access_criteria_flag should be set to TKM_FLAG_FALSE

– program_flag should be set to TKM_FLAG_FALSE

– service_flag should be set to TKM_FLAG_FALSE

Traffic Keys may be transmitted in the encrypted_traffic_key_material and next_encrypted_traffic_key_material fields as defined in Section 5.5 of [103]. It shall be indicated for each AU in the ISMACrypContextAU header which Traffic Key was used to encrypt this AU as specified in [103]. If OMA BCAST Short Term Key Messages are used, the keys in the STKM shall be encrypted with the content key from the DRM system.

OMA BCAST Key Messages, if used, are delivered in a separate UDP stream as specified in Section 5.5 of [103]. Key Messages are associated to ISMACryp streams via SDP signalling.

R.1.4 RTP Transport of Encrypted AUs

Content encryption modifies data before packetization of RTP packets, thus the various RFCs defining ways to encapsulate audio and video data do not apply. In addition, some signalling is necessary in the SDP in order to enable the decryption of the data. ISMACryp 1.1 [101] has defined encapsulation for some MPEG-4 codecs. For these codecs, the encapsulation as defined in [101] shall be used. For any other encrypted media that has a defined mapping to the ISO Media File Format, the encapsulation as defined in section 7 of [102] shall be used.

R.1.5 RTSP Signalling for key stream (STKM) setup and control

If STKMs are used as described in clause R.1.3.3, the RTSP session setup also needs to establish the STKM session, and a control URI as defined in [5] shall be present for each STKM media description in the SDP description.

R.1.5.1 RTSP SETUP Method

The control URI is used within the RTSP SETUP method to establish the described STKM sessions.

The RTSP transport protocol specifier for STKM as defined in [5] shall be "vnd.oma.bcast.stkm/UDP". One and only one UDP port is allocated for each STKM channel.

The following RTP specific parameters shall be used in the transport request and responds header for STKM sessions:

– client_port: This parameter provides the unicast STKM port(s) on which the client has chosen to receive STKM data.

– server_port: This parameter provides the unicast STKM port(s) on which the server has chosen to send data.

R.1.5.2 RTSP PLAY, PAUSE and TEARDOWN Method

The PLAY method tells the server to start sending data including STKM session data as defined in [5].

The PAUSE request causes the stream delivery including all STKM sessions to be interrupted (halted) as defined in [5].

The TEARDOWN client to server request stops the stream delivery including all STKM data delivery for the given URI, freeing the resources associated with it. Details for the TEARDOWN method are defined in [5].