75
4.5.6.4
ETSI EN 300 392-7 V2.3.1 (2006-06)
Change of security class to security class 3 with GCK
The SwMI may use the D-CK CHANGE DEMAND PDU to inform the MS that the security class of the cell will change to security class 3 with GCK. In this instance, the SwMI shall identify the active CCK-id and GCK-VN. The change of security class may be immediate or occur on a specific IV/network time. The SwMI shall set the "Change of security class" element of D-CK CHANGE DEMAND to "Transition to security class 3", and set the "Key change type" element to "Class 3 CCK and GCK activation".
4.5.7
Notification of key in use
When the D-CK CHANGE DEMAND PDU is used to indicate an active cipher key, the "Change of Security Class" element shall indicate "No change of Security Class ", and "Time Type" element shall be set to indicate "Currently in use". This may be used by the SwMI to indicate the following information to the MS: •
the current GCK-VN for all GCKs;
•
the current SCKN and SCK-VN of a fallback SCK for the SwMI;
•
the current SCKN and SCK-VN of a DM-SCK(s) associated with DMO; or
•
the current subset of SCKs for a subset of DM-SCKs associated with DMO.
4.5.8
Notification of GCK Activation/Deactivation
When the D-CK CHANGE DEMAND PDU is used to indicate activation or deactivation of GCKs in the cell, the "Key Change Type" shall be set to either "GCK Activation" or "GCK De-activation" respectively. This shall be synchronized with the change of the "GCK Supported" information element in SYSINFO.
4.5.9
Deletion of SCK, GCK and GSKO
Prior to key deletion using the mechanisms described in this clause there should be no associations to groups for those keys that are to be deleted. The SwMI should be authenticated by the MS before keys or key associations are deleted, this may be explicit or implicit. The deletion of the TM-SCK in a class 2 SwMI using the mechanisms described in this clause should be carefully considered. NOTE:
EN 300 812 [5] does not support a delete mechanism.
The SwMI may delete SCKs, GCKs or GSKOs currently contained within an MS by an explicit Key Delete command. The SwMI shall send a D-OTAR Key Delete Demand PDU to the MS. The PDU shall be sent to MSs individually, it shall not be sent to groups of MSs. If a single or a list of SCKs is to be deleted, the SwMI shall set the "Key delete type" element to "Individual SCK(s)", and shall list the SCKNs of the keys to be deleted. The MS shall delete the required key(s) and shall respond with a U-OTAR Key Delete Result PDU listing the SCKs that have been deleted. If the MS cannot delete one of the keys, for example if it does not possess the requested key, it shall not include that SCKN in the responding PDU. Therefore, if deletion of a single SCK was requested, but the MS does not possess the SCK, the "number of SCKs deleted" element shall be set to zero and no "SCKN" element shall be included in the PDU. If the SCK set is divided into subsets for DMO use, and a complete KAG is to be deleted (for example to remove all keys associated with a particular GSSI), the SwMI shall set the "Key delete type" to "SCK subset", and shall indicate the number of SCKs to be deleted per subset in the "Number of SCKs deleted" element (which is also the number of SCKN elements to be provided in the PDU). The SCKN elements shall only correspond to the SCKNs in the first subset of SCKs, i.e. the subset with SCKN = 1 as its lowest value. Therefore if multiple SCKNs are included in the PDU, the MS shall delete a number of SCKs equal to the "Number of SCKs deleted" element multiplied by the number of subsets in use.
ETSI