TSG-SA WG3 (Security) meeting #7		TSGS-WG3#7(99)388
Den Haag, 26-27 October, 1999	
Source:	3GPP TSG SA WG 3 (Security)
To:	3GPP TSG RAN WG 2	
Title:	Proposed LS about counter repeat in security algorithms

S3 has had liaisons with TIA TR-45, see attached document TSGS-WG3#5(99)391. S3 wants to ensure that the counter values COUNT-C and COUNT-I for ciphering and integrity protection are not repeated unless the keys are changed. RAN2 is kindly asked to check that there are no other cases where counter values are repeated, e.g. when re-synchronisation of the counter values is needed in mid-connections. In the case of re-synchronisation, the new synchronised value should be greater than the current value on each side. 
TSG-SA WG3 (Security) meeting #7		TSGS-WG3#7(99)391
Den Haag, 26-27 October, 1999	
Source:	Vodafone
Title:	Keystream repeat attacks
Document for:	Discussion
Agenda Item:	10.2

As with the 3GPP ciphering specifications, TR45.5 also use a stream cipher for encrypting user traffic on the radio interface. Within TR45.5, it is proposed that for connection establishment without authentication and following mid-connection loss of keystream synchronisation, the mobile would send the 24 least significant bits of the 32 bit cipher counter with an 8 bit digital signature generated using a session key. 
The motivation behind the signature is to defeat active attacks where an intruder forces the re-use of a particular section of keystream by modifying the cipher counter sent by the mobile to the network. Using two sections of ciphertext encrypted under the same keystream, the attacker will be able to recover both sections of ciphertext. Note that both sections of ciphertext must of course be encrypted under the same key for the attack to be successful. Bearing this in mind, the risk seems to be most apparent when authentication and key agreement is not performed at connection establishment.
Similar attacks should be considered in the context of the 3GPP ciphering specifications. Although the hyperframe number sent in the “initial layer 3 message” is not integrity protected, it is believed that the use of the COUNT value together with FRESH in the integrity protected security mode command means that we guard against this form of attack as part of the security mode control procedures. In more detail the scenario would run something like this:
-	For call establishment without authentication, an attacker would modify the “initial layer 3 message” to include an old value for the hyperframe number
-	The network would respond to the false “initial layer 3 message” message with the security mode command integrity protected using a new value of FRESH generated by the network and a COUNT-I value derived from the (old) hyperframe number. 
-	The mobile will only proceed with the call if it can correctly verify the security mode command. Since the COUNT-I value expected by the mobile will be different to the value used to generate the security mode command, the verification will fail.
-	The presence of the FRESH value means that the intruder cannot mount the attack by replaying an old security mode command.
S3 are asked to study this case and assure themselves that the security mode control procedure guards against keystream repeat attacks.
Another scenario should also be studied. That is, the possibility that an intruder can mount a similar attack by modifying the hyperframe number or any other frame number or count value used to synchronise the keystream that may be sent by the mobile. S3 should study whether such possibilities exist and if so whether the current 3GPP specifications guard against keystream repeat attacks in this scenario. Particular attention should be paid to loss of synchronisation at the MAC/RLC layer and whether procedures exist for resynchronisation.