6 Security procedures

12.033GPPSecurity ManagementTS

This clause describes the procedures and covers the technical details of the concepts discussed in clause 4.

Some security procedures (e.g. authentication, TMSI reallocation, IMEI checking) are activated conditionally. The activation of these procedures is controlled by administrable security triggers. Security triggers are defined for the various type of subscribers (home, visiting, …). Each subscriber is assigned one of these subscriber types.

For each security procedure, security triggers can be assigned per subscriber type. For each subscriber type, the security triggers describe the condition on which the applicable security procedure is to be performed. The condition is defined in terms of predefined triggering events, e.g. the establishment of a mobile originating call, a periodic location update, … The predefined triggering events may be assigned to groups based on how often the operator wants the security procedure to be activated: never, always or after a frequency N that can be administered by the operator.

One or more events can be grouped so that the security procedure can be triggered when a certain threshold has been exceeded. The grouping of the events is left to the operator.

For each of these groups, a counter is to be maintained per subscriber. This initial value of this counter is 0, and it is increased by one each time a triggering event from this set occurs. On the Nth occurrence, the counter is reset and the appropriate security procedure is executed for this subscriber.

NOTE: It is administered on a per VLR basis when a security function is invoked. The execution of the security procedure will be applicable to the VLR area where the security function is administered. The associated counter when to invoke a procedure is defined in the VLR per subscriber and per event group.

6.1 Subscriber Identity confidentiality management procedures (TMSI)

As discussed in clause 4, the frequency of TMSI reallocation has an effect on subscriber confidentiality. The following management capabilities are necessary to control the reallocation frequency:

– The specification of the frequency of TMSI reallocation via the frequency of periodic location update.

– The selection of MAP procedures that should include TMSI reallocation.

6.1.1 Timer for Periodic Location Update

A parameter (Timer T3212) is conveyed to the MS via the BCCH (ref GSM 04.08 [4]). It is used in the MS for performing periodic LUs. This is security-relevant because during each LU, TMSI reallocation is performed, i.e. the frequency of LU determines the frequency of TMSI reallocation.

The attribute timerPeriodicUpdateMS is defined in GSM 12.20 [20] to contain the time values in tenths of an hour.

Reducing the value of this timerPeriodicUpdateMS will therefore improve the degree of IMSI confidentiality, but has the net effect of increasing the signaling load on the network, in particular when LU is used with Authentication.

6.1.2 Selector when TMSI reallocation shall be done

The frequency of TMSI reallocation depends also on how many MAP procedures require TMSI reallocation.

TMSI reallocation in the MAP process access request procedure can be enabled/disabled, based on the following CM service type values:

– MO call

– Emergency call establishment

– SMS

– SS activation

– MO call re-establishment

– MT call

TMSI reallocation in the MAP location update procedure can be enabled/disabled, based on the following types of LU:

– Normal Location Update

– Periodic Location Update

– IMSI attach

The distinction between the various types of location updates is lost in the MAP-procedures. Additional information needs to be supplied to allow the management of TMSI reallocation. This TS assumes that the MSC-VLR interface is manufacturer-dependent, and therefore the addition of such information is left open.

The attribute allocateNewTMSIWhen of object class vlr1203SubscriberIdFunction is available to select one or several of the cases listed above to include TMSI reallocation.

6.2 Subscriber Identity authentication management procedures

As discussed in clause 4, authentication security can be managed based on when authentication is done, when authentication is retried and when authentication vectors are reused. The following management capabilities are necessary to control these aspects:

– The selection of which MAP procedures shall include subscriber identity authentication

– The selection of which conditions subscriber authentication shall be retried by the network

– The control of the reuse of authentication vectors.

6.2.1 Selector when authentication shall be performed

Subscriber authentication may be initiated by the MAP (vlr1203AuthenticationFunction) procedure for the access request and by the MAP location update procedure. The same selection criteria used in TMSI reallocation are applicable.

Including subscriber authentication in more than one procedure will improve the overall protection of the PLMN against unauthorized use.

If encryption is not used, authentication should be included in every service access procedure, otherwise there will be no protection against unauthorized use of services. If encryption is to be used, it is not necessary to perform authentication for every call, as it is possible to refer to a previously used encryption key, by using the ciphering key sequence number. This number is sent to the MS by the network during authentication procedure (reference GSM 04.08 [4], subclause 4.3.2).

In subsequent calls, this number is sent to the network by the MS (PAGING RESPONSE and in several MM messages, reference GSM 04.08 [4]). The network may check this number against the CKSN sent during some previous authentication procedure and skip the authentication procedure for the current call if the two numbers are equal and use that previously-used key again for encryption.

The attribute authenticationNecessaryWhen of object class vlr1203AuthenticationFunction contains the selection when the authentication procedure shall be mandatory.

If the abovementioned ciphering key sequence number check (which is done at the beginning of a call) does not allow to perform encryption, but encryption itself is not disabled (reference subclause 6.3.1), then authentication shall be included in the call, irrespective of the setting of the attribute.

6.2.2 Open Identification of MS (authentication retried)

Authentication could fail due to the following reasons:

– The TMSI of an MS is not known in the VLR

– The TMSI is allocated with a different IMSI (due to TMSI reallocation with TMSI reuse).

In order to obtain the identity of an MS in these cases, the network has to retry authentication with open transfer of the IMSI (reference to GSM 09.02 [5], macro Process_Access_Request_VLR). The attribute authenticationRetriedAllowed of object class vlr1203AuthenticationFunction will allow/disallow this.

Open identification of IMSI will make the subscriber traceable for one call or until the next handover. Additionally, if encryption is not used, the IMSI will be traceable until the next IMSI detach.

6.2.3 Parameters for generation and use of authentication vector

The following parameters influence the generation and use of the authentication vector:

– number of authentication vectors per subscriber to be kept in VLR. If for a subscriber the number of authentication vectors in the VLR is less than this number, new authentication vectors will be requested from the HLR/AuC for this subscriber (reference GSM 09.02 [5]: MAP‑SEND‑AUTHENTICATION‑INFO service) until a manufacturer-dependent (maximal) number of authentication vectors in VLR is reached.

This parameter only affects the computing and signaling load caused by the subscriber authentication and encryption security service.

– Authentication vector reuse allowed.

By reuse of RAND and SRES, the level of data confidentiality and authentication can be degraded as it potentially makes it easier to guess or compute Kc or even Ki. If no encryption is used, SRES should not be reused, as it would make possible a security attack by masquerade. If no unused authentication vectors are available in the VLR and authentication vector reuse is not allowed, then calls shall be cleared.

The attributes numberOfAuthenticationVectorsKept and authenticationVectorReuseAllowed of object class vlr1203AuthenticationFunction control the various authentication vector reuse options.

6.3 Encryption and algorithm management procedures

The use of encryption is a network option subject to the restrictions of GSM 02.09 [1]. The service and procedures to be managed are described in GSM 09.02 [5] (MAP-SET-CIPHERING-MODE service). The various versions of the ciphering algorithm supported by the ME are signaled to the network over the air interface and an appropriate encryption algorithm or not encryption has to be selected by the network (reference GSM 04.08 [4], subclause 3.4.7, ciphering mode setting procedure).

6.3.1 Encryption Management Procedures

For the management of the existing encryption options, an attribute, encryptionControl, with the following values is defined:

– noEncryption;

– encryptionSupported (i.e. to be used where possible);

– encryptionNecessary (i.e. call shall either continue in encrypted mode or shall be cleared if encryption is not possible).

The value of this attribute shall be tested at the beginning of the call (the exact implementation is left to the manufacturer).

If the attribute value is noEncryption, no encryption will be used for the call. If it is one of the other two values, the network will negotiate a feasible algorithm with the BSC. The result of this negotiation will be either an encryption algorithm which is supported by both the network and the MS or no encryption.

If the attribute value is encryptionNecessary, and no encryption has been negotiated, the call shall be cleared by the network. Otherwise the call shall proceed as negotiated.

6.3.2 Algorithm management procedures

For the management of the ciphering algorithm two, possibly single element lists, must be defined. The MSC must select from the list of ciphering algorithms indicated by the ME. This selection would be based on a managed list of algorithms permitted in the network. The intersection between this list and the list from the ME is passed in signaling to the BSS. The BSC must then select from this list based on an administered priority and based on the capabilities of the relevant BTS to support the various ciphering algorithms.

For the MSC, the attribute algorithmListMSC will be provided to allow the OS to set the list of ciphering algorithms allowed in the network.

For the BSS, the attribute algorithmListBTS will be provided, per BTS, to allow the OS to set the list of ciphering algorithms supported by the BTS and to indicate the priority order of their use.

6.4 IMEI management procedures

Equipment identification is done by requesting the IMEI from the ME (reference GSM 04.08, [4] CIPHERING MODE COMMAND MESSAGE and GSM 09.02 [5] MAP_PROCESS_ACCESS_REQUEST).

To control this identification, the attribute checkIMEIWhen has been defined in the present document. It is used to select which MAP procedures shall include the request of the IMEI .

6.4.1 Selector when IMEI check shall be performed

The attribute checkIMEIWhen is provided to select whether the network will issue an identity request and perform the IMEI check. IMEI check may be initiated by the MAP (VLR-) procedures for access requests and location updates. The same selection criteria used in TMSI reallocation are applicable.

The identity of a ME is required for identifying (white-, grey- or black-listed-) equipment and tracing black- or grey-listed equipment.

The security of this mechanism against attacks (e.g. masquerade) is not influenced by the network; it depends entirely on the implementation of the IMEI and related reporting functions in the ME.

The attribute checkIMEIWhen of object class vlr203EquipmentIdFunction contains the selection when IMEI check shall be performed.

6.5 Use of counters for security purposes

6.5.1 Open transfer of IMSI

Counters on the occurrence of the open transfer of the IMSI, provide information about the quality of the subscriber confidentiality service. The following such counters have been defined in GSM 12.04 [10]:

– "Successful transactions on the MM-Layer where subscriber was identified with TMSI"; and

– "Successful transactions on the MM-Layer where subscriber was identified with IMSI".

6.5.2 IMEI related counters

Several counters provide information on the number of IMEI-related transactions. These counters, (listed below) have been defined in GSM 12.04 [10]:

– "Number of transmitted IMEI check request" in MSC;

– "Number of white answers" in MSC;

– "Number of grey answers" in MSC;

– "Number of black answers" in MSC;

– "Number of unknown IMEI answers" in MSC;

– "Number of received IMEI check request" in EIR;

– "Number of white answers" in EIR;

– "Number of grey answers" in EIR;

– "Number of black answers in EIR;

– "Number of unknown IMEI answers" in EIR.

6.5.3 Authentication failure

Authentication failure may occur in the following situations:

– different SRES values, reference GSM 04.08 [4], AUTHENTICATION REJECT message;

– timeout (SRES not received in time), reference GSM 04.08 [4], timer T3260;

– The TMSI of an MS is not known in the VLR;

– The TMSI is allocated with a different IMSI (due to TMSI reallocation with TMSI reuse).

Counters to measure these events are specified in GSM 12.04 [10]:

– "attempted authentication procedures in the VLR";

– "successful authentication procedures in the VLR".

6.5.4 Additional security counters

The following counters for security purposes are currently defined in this recommendation (Annex B), but they will eventually need to be integrated in GSM 12.04 [10], along with other counter objects in the future.

Three counters are defined in the MSC to provide information on the use of encryption:

– "Encrypted connection used" in MSC;

– "Unencrypted connection used" in MSC;

– "Connection cleared due to incompatible encryption" in MSC.

The following counter is defined to measure the unsuccessful authentication due to the loss or the unavailability of authentication vectors from the AuC:

– "Authentication vectors unavailable" in VLR.

Counters are defined in several network elements to measure the level of possible unauthorized intrusions in the network:

– "Subscriber unknown in HLR" in VLR;

– "Subscriber unknown in HLR" in HLR;

– "Subscriber unknown in AuC(HLR)" in HLR.

6.5.5 Security-related scan reporting

The following tables list all recommended security related counters, available to scan reports relevant to specific GSM Network Elements.

Operators shall also be able to generate these scan reports on demand or at regular scheduled intervals.

MSC

– Subscriber identified with IMSI on radio path;

– Subscriber identified with TMSI on radio path;

– Encrypted connection used;

– Unencrypted connection used;

– Connection cleared due to incompatible encryption;

– Number of transmitted IMEI check requests;

– Number of white answers;

– Number of grey answers;

– Number of black answers;

– Number of unknown IMEI answers.

VLR

– Attempted authentication procedures in the VLR;

– Successful authentication procedures in the VLR;

– Subscriber unknown in HLR;

– Authentication vectors unavailable.

HLR

– Subscriber unknown in HLR;

– Subscriber unknown in AuC(HLR).

EIR

– Number of received IMEI check requests;

– Number of white answers;

– Number of grey answers;

– Number of black answers;

– Number of unknown IMEI answers.

6.6 Security reporting

6.6.1 Security alarm reports

The following security related alarms shall be generated and presented to operating personnel of a GSM network, immediately after the cause which triggered them is identified.

The generated alarms can be stored in a log in the NE and/or forwarded to an OS. The storage of alarms in the NE is modeled through the managed object class "log" as specified in CCITT X.735 [17]. The forwarding of alarms is modeled via ‘Event Forwarding Discriminator (EFD)’ objects, defined in CCITT X.734 [16]. Additional information can be found in GSM 12.00 [6].

6.6.1.1 Authentication failure in VLR

An authentication failure (mismatched or missing SRES) is reported by the VLR as a security alarm. The following information should be available (in addition to VLR id and time stamp etc.):

– IMSI;

– IMEI (optional, only if available);

– type of failure (missing or mismatched SRES);

– location information.

The security alarm notification type shall be the "Security service or mechanism violation", as defined in X.736 [18]. authenticationFailureInVLR is defined as a new security alarm cause for this alarm notification with its own object identifier. The alarm info parameter in the alarm notification has as ASN.1 syntax definition AuthenticationFailureInVLRSecurityAlarmInfo.

6.6.1.2 IMEI check violation in VLR

An alarm shall be reported when the VLR receives a "non-white-listed" response from the EIR. The following information should be reported in this case:

– IMSI;

– IMEI;

– type of failure (black-listed, grey-listed, unknown, no response from EIR);

– location information.

The security alarm notification type shall be the "Security service or mechanism violation", as defined in X.736 [18]. imeiCheckViolationInVLR is defined as a new security alarm cause for this alarm notification with its own object identifier. The alarm info parameter in the alarm notification has as ASN.1 syntax definition ImeiCheckViolationInVLRSecurityAlarmInfo.

6.6.1.3 IMEI request failure in VLR

The MS does not send its IMEI to network when requested. The alarm shall contain:

– IMSI;

– TMSI if available;

– location information.

The security alarm notification type shall be the "Security service or mechanism violation", as defined in X.736 [18]. imeiRequestFailureInVLR is defined as a new security alarm cause for this alarm notification with its own object identifier. The alarm info parameter in the alarm notification has as ASN.1 syntax definition ImeiRequestFailureInVLRSecurityAlarmInfo.

6.6.1.4 IMSI request failure in VLR

The MS does not reveal its identity (IMSI) when requested after the identification with TMSI failed. The alarms contain only the TMSI and location information. The security alarm notification type shall be the "Security service or mechanism violation", as defined in X.736 [18]. imsiRequestFailureInVLR is defined as a new security alarm cause for this alarm notification with its own object identifier. The alarm info parameter in the alarm notification has as ASN.1 syntax definition ImsiRequestFailureInVLRSecurityAlarmInfo.

6.6.1.5 Unknown subscriber in HLR (VLR)

The VLR receives a request from an MS that is not identified in the HLR. The only available information is the IMSI, the identity of the HLR and the location of the attempt. The security alarm notification type shall be the "Integrity violation", as defined in X.736 [18]. unknownSubscriberInVLR is defined as a new security alarm cause for this alarm notification with its own object identifier. The alarm info parameter in the alarm notification has as ASN.1 syntax definition UnknownSubscriberInVLRSecurityAlarmInfo.

6.6.1.6 Unknown subscriber in HLR

The HLR receives a request from a VLR with an IMSI that is unknown in the HLR. The information available is the IMSI and the identity of the VLR. The security alarm notification type shall be the "Integrity violation", as defined in X.736 [18]. unknownSubscriberInHLR is defined as a new security alarm cause for this alarm notification with its own object identifier. The alarm info parameter in the alarm notification has as ASN.1 syntax definition UnknownSubscriberInHLRSecurityAlarmInfo.

NOTE: This reports the same event as in subclause 6.6.1.5, but is kept separate to account for the case of the event occurs in a different network.

6.6.1.7 Unknown subscriber in AuC(HLR)

The Auc(HLR) receives a vector request for an IMSI that is unknown in the AuC(HLR). The only information available is the IMSI. The security alarm notification type shall be the "Integrity violation", as defined in X.736 [18]. unknownSubscriberInAuCHLR is defined as a new security alarm cause for this alarm notification with its own object identifier. The alarm info parameter in the alarm notification has as ASN.1 syntax definition UnknownSubscriberInAuCHLRSecurityAlarmInfo.

6.6.1.8 IMSI confidentiality failure In MSC

If the number of IMSIs used for subscriber identification on a radio path increases over a threshold during the reporting period, this alarm should be generated.

The security alarm notification type shall be the "Security service or mechanism violation", as defined in X.736 [18]. subscriberIdentityConfidentialityFailureInMSC is defined as a new security alarm cause for this alarm notification with its own object identifier. The alarm info parameter in the alarm notification has as ASN.1 syntax definition ImsiConfidentialityFailureInMSCSecurityAlarmInfo.

6.6.2 Security audit trail reports

No security audit trail reports are defined in the present document.