8.1
Content Control Key refresh protocol
8.1.1
Initialization and message overview
The following Figure 8.1 is provided for informative purpose:
[1] CCK (re)keying required
[2] generate key Kp
[4] send CC_sac_data_req(Kp+CICAM_ID+keyregister)
[5] Verify CICAM_ID [6] confirm CC_sac_data_cnf(Host_ID+status)
[8] derive CIV and/or CCK
[9] send CC_sac_sync_req()
[10] confirm CC_sac_sync_cnf(status)
CICAM Host
[3] derive CIV and/or CCK
[7] verify HOST_ID
NOTE : This diagram does not suggest that any behaviour be specifically (un)synchronized / (un)blocked.
Figure 8.1: CCK material computation sequence diagram
Table 8.1: CCK Computation (normative)
No. Description Refer to
1 When the CICAM detects that a refresh of the CCK is required, the CICAM shall start the process of CCK initialisation. The exact conditions for (re)keying are specified in the referenced subsection.
Section 8.1.2
2 The CICAM generates a nonce to generate Kp as follows:.
)
(
256nonce
SHA
Kp
Section Annex A.13 The CICAM may immediately start to compute the CIV and/or CCK. Section 8.1.4
4 The CICAM shall send a cc_sac_data_req APDU to the Host, carrying the following parameters:
Kp.
CICAM_ID as extracted from the CICAM device certificate. selection for odd or even register.
Section 11.3.3.4
5 The Host shall check that the received CICAM_ID is equal to the previously stored CICAM_ID (See Note 5). If they are the same the Host may start computing the CIV and/or CCK.
A CICAM_ID verification failure shall constitute in a response of ”no CC support”.
Section 8.1.4
6 The Host shall confirm with the cc_sac_data_cnf APDU to CICAM, carrying the following parameters:
HOST_ID as extracted from the Host device certificate.
Failure to respond with cc_data_cnf constitutes a failure of the copy control system.
Section 11.3.3.4
7 The CICAM shall check that the received HOST_ID is equal to the previously stored HOST_ID (See Note 5). If they are the same the CICAM may use the computed CCK and CIV.
A Host answer of CC_no support or a HOST_ID verification failure constitutes a failure of the copy control system. See Note 6.
Section 8.1.4
8 The Host may compute the CIV and/or CCK. Section 8.1.4
9 The CICAM shall send a cc_sac_sync_req APDU to the Host, indicating a CCK refresh.
When the CICAM has completed initializing the scrambler, the CICAM shall send a synchronization request to the Host. This informs the Host that the CICAM is ready to start using the newly computed CCK.
Section 11.3.3.4
10 The Host shall use the cc_sac_sync_cnf APDU to confirm to the CICAM to indicate that it is ready to start using the newly computed CCK.
Failure to respond with cc_sac_sync_cnf constitutes a failure of the copy control system. See Note 6.
Section 11.3.3.4
Notes:
1. Once computed, the new key material shall be stored in the appropriate register of the (de)scrambler. Refer to section 5.6 for details.
2. The conditions for CCK refresh are specified in section 8.1.2. 3. Refer to Annex H for an overview of parameters involved.
4. The APDUs that are required in the CCK refresh protocol shall be sent via the SAC; refer to section 7. 5. Previous HOST_ID / CICAM_ID is stored in the 'Authentication Context'. Refer to Section 6.3
8.1.2
Content Control Key re-keying conditions
The Content Control Key (CCK) refresh is initiated by the CICAM, whereas the Host is passively replying. The CCK refresh shall be triggered under any of the following conditions:
After both the authentication and the SAC initialisation process have successfully completed. When triggered at the discretion of the CAS.
When triggered periodically (maximum key lifetime parameter). See Section 8.1.3. When block counter limit is overrun (only for AES mode).
At every reboot.
At every reset of the CICAM.
The following Figure 8.2 explains the CICAM operation for CCK refresh.
(1) CC initialisation
(2) CICAM initializes CC key refresh timer to zero seconds.
(4) CICAM starts calculating CIV and/or CCK. yes Yes (between 10 and 30 s.) (16) CICAM disables network CA descrambling (14) CICAM received sync confirm? (15) Key refreshtimer: 10 > t > 30 sec? No yes (17) CICAM enables CA descrambling and CC scrambling operation. (12) Key refresh timer
> 9 sec? No No (18) CICAM starts block_counter = 1. yes no
Successful (re)authentication and/or (re)boot and/or reinsertion
(19) CA requests key refresh ? yes (20) key_lifetime expired ? (21) block_counter expired ? no no No (<10s.)
(5) CICAM receives host confirm. (3) CICAM sends key Kp.
(13) CICAM sends sync request. (6) Initial
Key_lifetime period?
(7) Key refresh timer
<= 9 sec? yes (9) CICAM received sync confirm within timeout? (10) Key refresh timer <= 10 sec? No (11) Wait 1 second yes
(8) CICAM sends sync request yes no yes (22) CICAM disables network CA descrambling No (retries < limit) No (>30s.) yes
NOTES: 1. The key refresh timer is the timeout upon computing a new CCK; refer to Figure 5.15 for details.
2. The key lifetime is described in Section 8.1.3 3. The block counter limit is defined in Table 8.2
4. The initial key_lifetime is defined as the first key lifetime period (i.e. CCK computation) after SAC (re)initialisation.
5. Start of CC scrambling operation is subject to any URI data associated with the selected service.
Table 8.2: Scrambler Block Counter Limits
Scrambler Selection Block Counter Limit Comment
DES N/A not used
AES 232
Note: The block counter limit is the number of cipher blocks that have been processed since the refresh of the CCK.
Figure 8.3 explains the Host operation for CCK refresh.
(4) Host calculates CIV and/or CCK
(1) Wait for CICAM key refresh
Successful (re)authentication and/or (re)boot and/or reinsertion
(2) Host receives key Kp
(3) Host confirms
(5) Host receives sync request (6) Host confirms and
starts using (newly) calculated CC keys
Figure 8.3: Host operation for CCK refresh (informative)
8.1.3
Content Key Lifetime
The maximum key lifetime parameter is controlled by the CA system, which is out of scope of this specification. The countdown from this value is maintained by the CICAM which triggers the CCK refresh process.
The countdown proceeds ONLY whilst the CICAM is scrambling content. This ensures that the Content Key is not recalculated when it is not being used.
8.1.4
Content Control Key Computation (CCK)
The scrambler requires a content key (and an IV if required) for its operation: the Content Control Key (CCK) and a Content Initialization Vector (CIV). Computation of CCK (and CIV) proceeds in two steps:
Key precursor calculation. CCK and CIV key derivation. These are defined as follows:
(nonce) SHA256
Kp Eq. 8.1
Where:
Input parameters are defined in Table 8.3.
Table 8.3: Input Parameters in Key Computation
Key or variable Size (bits) Comments Refer to
nonce 256 Random nonce of 256 bits generated by the CICAM. Annex A
Notes:
1. Input is padded according to SHA-256. Refer to FIPS 180-3 [3]. It is advised that SHA implementations adhere to the SHS validation list. See SHS Validation List [11].
2. The requirements on the random number generator for the nonce are given in Annex A
Step 2: Key Material computation.
The Key Material Km is 256 bits long and is used for the derivation of the Content Control Key (CCK). The Key Material Km is calculated as follows:
)
(
,CIV
f
CC
Kp
CCK
Eq. 8.2Note: the function f-CC is not defined in this document and may be obtained from the CI Plus Licensee Specification [33].
After successful authentication the system will have determined whether the AES or DES cipher will be used to protect the CA-unscrambled content returning to the Host (refer to section 6). The Content Control Key (CCK) and Initialisation Vector (CIV) are derived from the Key Material (Km) in different ways for the AES-128 scrambler and for the DES-56 scrambler.
8.1.5
Content Key for DES-56-ECB Scrambler.
The DES-56 Content Key (CCKDES) is 64 bits. The CCK material from the f-CC is padded with parity bits in the
same way as SCTE41 [5], Appendix B into the resultant CCKDES. The CCKDES shall be changed as specified in
section 5.6.1.
When DES is used, the CCK shall be used to descramble a TS packet as follows:
)
_
}(
{
_packet
D
56CCK
Ts
Packet
clear
DES ECB DES Eq. 8.3 NOTE: Refer to section 5.6.2.2 for the detailed specification of the DES (de)scrambler.8.1.6
Content Key and IV for AES-128-CBC Scrambler.
The AES-128 Content Key (CCKAES) is 128 bits long. When AES is used, the CCK and CIV are applied to AES to descramble a TS packet as follows:
)
_
}(
}{
{
_packet
D
128CCK
CIV
Ts
Packet
clear
AES CBC AES Eq. 8.4 Where: The CCKAES shall change as specified in section 5.6.1. Additionally, the CCKAES shall be changed after
processing 232 AES blocks.
The CIV is fixed for every key lifetime period and shall change when the CCK changes. The current CIV shall be re-used at the start of every MPEG2 TS packet.