Вы находитесь на странице: 1из 30

Information

Security

AC Security Management and Communication


A50016-E1113-C3-1-7629

AC Security Management and Communication

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation. The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products are given "as is" and all liability arising in connection with such hardware or software products shall be defined conclusively and finally in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document. Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT. This documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws. The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG. Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only. Copyright Nokia Siemens Networks 2006. All rights reserved

Important Notice on Product Safety


Elevated voltages are inevitably present at specific points in this electrical equipment. Some of the parts may also have elevated operating temperatures. Non-observance of these conditions and the safety instructions can result in personal injury or in property damage. Therefore, only trained and qualified personnel may install and maintain the system. The system complies with the standard EN 60950 / IEC 60950. All equipment connected has to comply with the applicable safety standards.

The same text in German: Wichtiger Hinweis zur Produktsicherheit In elektrischen Anlagen stehen zwangslufig bestimmte Teile der Gerte unter Spannung. Einige Teile knnen auch eine hohe Betriebstemperatur aufweisen. Eine Nichtbeachtung dieser Situation und der Warnungshinweise kann zu Krperverletzungen und Sachschden fhren. Deshalb wird vorausgesetzt, dass nur geschultes und qualifiziertes Personal die Anlagen installiert und wartet. Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Angeschlossene Gerte mssen die zutreffenden Sicherheitsbestimmungen erfllen.

Id:0900d805806f2119

A50016-E1113-C3-1-7629

AC Security Management and Communication

Table of Contents
This document has 30 pages. Change History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1 2 2.1 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6 2.2.7 2.3 2.4 2.4.1 2.4.2 2.4.3 2.5 2.5.1 2.5.2 2.5.3 2.5.4 2.6 2.7 2.7.1 3 3.1 3.2 3.2.1 3.2.2 4 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Mode of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authentication Vectors and Ciphering Vectors . . . . . . . . . . . . . . . . . . . . 9 Key Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authentication Key Ki. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Master Group Key V_Ki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Session Key K4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Storage Key K2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Public, Secret and Modulus Key K7. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Increased Key Lengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 K10 Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Key and Algorithm Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Key Management Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Public Key Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Master AC Key Set Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Session Key Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Security Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Secured Logging for AC Subscriber Data . . . . . . . . . . . . . . . . . . . . . . . 19 Secure Regeneration of AC Database. . . . . . . . . . . . . . . . . . . . . . . . . . 20 Reencryption of the AC Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Security Records and Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Operational Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Secure Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 SAS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MML Commands at the SC or CTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inputs at the PCS and SMC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Primitives at the PCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Primitives at the SMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 25 28 28 28

Compatibility with other Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

A50016-E1113-C3-1-7629

Id:0900d805806f2119

AC Security Management and Communication

List of Figures
Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Transport via file and storage of Ki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Encryption mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Challenge/response mechanism. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Signature mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Secret key transmission from SMC to AC. . . . . . . . . . . . . . . . . . . . . . . . 14 Secure regeneration of AC subscriber database . . . . . . . . . . . . . . . . . . 20 Organization of SAS sublayer in the AC . . . . . . . . . . . . . . . . . . . . . . . . . 24

Id:0900d805806f2119

A50016-E1113-C3-1-7629

AC Security Management and Communication

List of Tables
Table 1 Table 2 Table 3 Table 4 Table 5 Table 6 Keys stored in the security boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . Algorithms for general key management . . . . . . . . . . . . . . . . . . . . . . . Algorithms for 2G subscriber key management . . . . . . . . . . . . . . . . . . Algorithms (functions) for 3G subscriber key management . . . . . . . . . Algorithms for group call key management . . . . . . . . . . . . . . . . . . . . . Examples of security features in the AC . . . . . . . . . . . . . . . . . . . . . . . . 15 16 16 16 16 26

A50016-E1113-C3-1-7629

Id:0900d805806f2119

Change History

AC Security Management and Communication

Change History
Issue 1 (10/2006) New software release. Introduction of Ciphering of group calls. Maximum number of quintets per VLR request increased to five.

Id:0900d80580093f2a

A50016-E1113-C3-1-7629

AC Security Management and Communication

Definition

1 Definition
g This document is valid for both 2G and 3G mobile networks. It should be noted that
the 2G secret key is called Ki and the 3G secret key is called K. Throughout the following description the designation Ki will be used for both, unless 3G specific content is discussed. The secret key for group calls V_Ki (also called master group key) is always explicitly mentioned. The main functions of the authentication center (AC) in the mobile network are: to securely store the authentication keys and master group keys to generate authentication vectors and ciphering vectors The data stored in the AC comprises for subscribers: the IMSI, the secret authentication key of the subscriber and the version indicators of assigned algorithms and keys used in the AC and the (U)SIM for security features for group calls: the group ID and the service type (VBS or VGCS), the assigned master group keys, their IDs and the version indicators of assigned algorithms and keys used in the AC and the USIM for security features The algorithms themselves are stored in the AC security boxes and are used for the calculation of vectors. This involves using hardware with special security facilities on which manipulation is difficult and any data access attempt is logged. The authentication keys, master group keys and algorithms are secret information which is never transmitted to any other network element. The security box (IOP:AUC) of an AC can generate authentication vectors for subscribers and ciphering vectors for group calls. These two types of vectors are delivered to the MSC/VLR in different ways: The authentication vectors of subscribers are delivered from the AC via the HLR to the VLR. For this purpose the HLR/AC can be a standalone network node or it can be integrated into a combined MSC/VLR/HLR/AC node. According to the 3GPP 43.020 recommendation the master group keys have to be kept within the group call register (GCR) being part of the anchor MSC. For that reason the security box has to be integrated into the anchor MSC in order to support ciphering of the voice group call channel resulting in a combined MSC/VLR/AC node. Within this combined network node the ciphering vectors for group calls are delivered via an internal interface from the AC to the group call register. The AC of a combined MSC/VLR/HLR/AC can deliver vectors for subscribers and group calls. The operation and maintenance system (OMS) allows the remote operation and maintenance of the AC. The personalization center (PCS) and the security management center (SMC) are special OMS elements for security management purposes. The communication between the AC and these elements is secured by special keys and algorithms. Furthermore the AC can use the services of the secure application service (SAS) sublayer in order to ensure a secure communication. Authentication and ciphering in 2G and 3G networks are described in the document Security Management Functions in MSC/VLR.

A50016-E1113-C3-1-7629

Id:0900d8058009deda

Definition

AC Security Management and Communication

Personalization center (PCS) The PCS is an OMS element in which a subscriber identity module (SIM) is created for the mobile subscriber - a 2G SIM for a 2G subscriber or a 3G SIM for a 3G subscriber. Among other things, the 2G SIM stores the international mobile subscriber identity (IMSI) as well as the authentication key Ki and a specific version of the algorithms A3 and A8, which are permanently assigned. A 2G command file with the IMSI, the encrypted Ki and a version number of the algorithms A3 and A8 is also prepared in the PCS. By means of this file the subscribers are created in the AC. The 3G SIM (also called USIM) contains among other things the IMSI as well as the authentication key K, a list of the last used sequence numbers (SQN) and up to two sets of the algorithms f1-f5/f1*/f5*. A 3G command file contains the IMSI, the encrypted K and the version and set number of the algorithms f1-f5/f1*/f5*. Additional data for group calls has to be stored on the SIM if the subscriber is a member of a VBS or VGCS group and shall be able to listen to a ciphered voice group call channel: group ID, service type (VBS or VGCS), the master group keys V_Ki and their IDs (VK_ID), the IDs of the related A5 algorithms and a specific version of the algorithm A8_V. This is only supported by 3G SIM cards. The master group keys on the USIM (and in the AC) have to be changed periodically (for reasons see section 2.1). Possible solutions are for example: to use the PCS (not recommended), to modify the data over-the-air (OTA) or to install local service stations e.g., in the headquarter of a subscriber group. In order to reduce the frequency of master group key modification, two keys can be stored on the USIM and in the AC: a currently used (active) key and a spare (passive) key. Security management center (SMC) The SMC is an OMS element from which secret keys and algorithms can be managed all over the network in a secure way. For instance, to continuously secure the network from attacks, it allows the master AC key set from time to time to be replaced by another one.

Id:0900d8058009deda

A50016-E1113-C3-1-7629

AC Security Management and Communication

Mode of Operation

2 Mode of Operation
2.1 Authentication Vectors and Ciphering Vectors
The AC automatically creates authentication vectors (AV) for 2G and 3G subscribers and ciphering vectors for group calls. Authentication vectors for 2G subscribers (triplets) Six triplets per 2G subscriber are initially created in the security box and stored in the AC: Five triplets are stored as transient data. They are used for authentication and ciphering. One triplet together with other subscriber data is stored in a semipermanent memory for recovery purposes. The semipermanent triplet is used if there are no transient triplets available, e.g. after a restart to still allow authentication and keep the network services available. This triplet is also used if the security boxes of the AC should not be able to compute new triplets (e.g. at overload). Upon request the AC sends up to five triplets to the HLR which forwards them to the VLR. A triplet consists of the following three parameters: RAND: a random number generated in the security box SRES: the signed response calculated from the RAND and the secret authentication key Ki using algorithm A3 Kc: the cipher key calculated from RAND and Ki using algorithm A8 Authentication vectors for 3G subscribers (quintets) Two quintets per 3G subscriber are initially created in the security box and stored in the AC together with a sequence number (SQN). There is no quintet for recovery purposes as a reused quintet would be rejected by the USIM. The VLR may request up to five quintets from the HLR which requests up to three quintets from the AC if more than three quintets are required, the HLR requests them in several steps. The AC provides the available quintets (up to two) to the HLR. If the HLR has requested more quintets, the additional quintets are calculated real-time and sent to the HLR. If the VLR requests more than one quintet in one MAP dialog, these quintets can be forwarded by the HLR using continue handling or SCCP segmentation. Continue handling is only used if SCCP segmentation is not possible. For SCCP segmentation the feature SCCPSGMA must be active and all network nodes in the signaling path to the VLR must support SCCP whitebook. The VLRs for which this prerequisite is fulfilled have to be defined in the HLR by a special roaming area named SCCPSGMA. A quintet consists of the following five parameters: RAND: a random number generated in the security box XRES: the "expected response" calculated from the RAND and the secret authentication key K using algorithm f2 CK: the cipher key calculated from RAND and K using algorithm f3 IK: the integrity key calculated from RAND and K using algorithm f4 AUTN: the authentication token being a combination of

A50016-E1113-C3-1-7629

Id:0900d80580093f12

Mode of Operation

AC Security Management and Communication

SQN: the sequence number generated in the security box AMF: the authentication management field entered during the creation of a subscriber AK: the anonymity key calculated from RAND and K using algorithm f5 MAC: the message authentication code calculated from AMF, RAND and K using algorithm f1 During authentication the SQN is sent to the mobile station as part of the AUTN. If the USIM expects a different SQN it sends a synchronization failure report to the AC. The AC starts a resynchronization procedure and the generation of new quintets with a new sequence number. Ciphering vectors for group calls For each combination of group ID and service type (VBS or VGCS) six vectors are initially created in the security box and stored in the AC: Five vectors are stored as transient data. They are used for ciphering of the voice group call channel. One vector is stored in a semipermanent memory for recovery purposes. The semipermanent vector is used if there are no transient vectors available. From point of view of the AC a vector consists of the following two parameters: VSTK_RAND: a random number generated in the security box VSTK: the short term key calculated from the VSTK_RAND and the master group key V_Ki using algorithm A8_V When the AC sends a ciphering vector to the GCR in the MSC, it adds the ID of the active master group key (VK_ID) and the ID of the A5 algorithm to be used for ciphering. So from point of view of the GCR, the ciphering vector contains four parameters. If the feature FULLRAND is active, the random number is generated as full random number. Otherwise it is generated as a combination of a counter value and a random part. The counter is increased when new vectors are generated. When it reaches its upper limit and is reset to zero, a mask is displayed to inform the operator that the master group keys have to be changed. Thus the risk that the same random number is generated twice during the lifetime of a master group key can be minimized.

2.2

Key Description
A number of keys are used to handle the authentication key and other keys in a secure way outside the security box. The keys are used with the associated algorithms to perform the proper calculation: the authentication key Ki the master group key V_Ki the session key K4 the storage key K2 the public key of the network elements K7p and secret key of the AC K7s These keys are described below.

10

Id:0900d80580093f12

A50016-E1113-C3-1-7629

AC Security Management and Communication

Mode of Operation

2.2.1

Authentication Key Ki
The authentication key Ki is used to generate authentication vectors for a mobile subscriber. It is secret and therefore never transmitted as clear data outside the security box.

2.2.2

Master Group Key V_Ki


The master group key V_Ki is used to generate ciphering vectors for group calls. These vectors are required to allow ciphering of the voice group call channel. The V_Ki is secret and therefore never transmitted as clear data outside the security box. For each VBS or VGCS group up to two master group keys can be stored in the AC. Only one of these keys is active.

2.2.3

Session Key K4
Secret information (e.g. the authentication key Ki in Figure 1 and the group key V_Ki) must be transported in a secure way. For this purpose K4 is used together with cryptographic algorithm A4 for both encryption (for secure data transport) and decryption (for allowing data to be stored). The sender encrypts data using K4. The receiver decrypts it using the same K4. Depending on the features active in the project, each security box of the AC can have several K4 keys at its disposal. The available options are described in section 2.4.3. The AC database in the common memory can store: the identifier of the relevant K4 key (K4ID) the key reference the appropriate K4 being encrypted (only when a provision of several K4s applies) the version indicator of the A4 algorithm
PCS K4 K4 AC K2

Ki

A4

A4(Ki)

A4 Security box Common memory

Ki

A2

A2(Ki)

Figure 1

Transport via file and storage of Ki

2.2.4

Storage Key K2
The storage key K2 is used to encrypt authentication keys Ki and group keys V_Ki before they are stored in the AC database (for Ki see Figure 1). Decryption is also performed using K2 and A2.

A50016-E1113-C3-1-7629

Id:0900d80580093f12

11

Mode of Operation

AC Security Management and Communication

With respect to the K2 key, the AC key database in the common memory stores: the identifier of the K2 key the version indicator of the A2 algorithm the current K2 encrypted with the public AC key and signed with the secret AC key (as secure backup)

2.2.5

Public, Secret and Modulus Key K7


Public and secret keys are used together with cryptographic algorithms to ensure secure communication between the different network elements. To ensure confidentiality, authentication and integrity of the data transferred within the network, each element (AC, SMC , PCS) is assigned a key set consisting of a public key K7p, a secret key K7s and modulus key K7m: K7p is known to all communication partners K7s is only known to the element itself K7m is known to all communication partners The K7 keys are used by the cryptographic algorithm A7, which performs the actual calculation. The following basic functions can be executed using public and secret keys: confidentiality by encryption authentication by challenge/response data integrity by signature Confidentiality by encryption Encryption is used to transfer data (i.e. secret keys) in a confidential way from a sender to a receiver (see Figure 2): The sender encrypts the clear data using the K7p of the receiver. The receiver only can decrypt it using its own K7s.
Sender S K7p,R and K7m,R encrypted data ENCRYPT DECRYPT Receiver R K7s,R and K7m,R

clear data

clear data

Figure 2

Encryption mechanism

Authentication by challenge/response To set up an authenticated connection, the sender can first check whether it is connected with the required partner. The receivers signature is verified by the sender as follows (see Figure 3): The sender transmits a random number (challenge). The receiver signs this number by its secret key K7s, resulting in a signed response. The sender verifies this response by using the receivers K7p. It is obvious that an authenticated connection can also be checked in the opposite case. The receiver verifies the senders signature to be sure of the right connection.

12

Id:0900d80580093f12

A50016-E1113-C3-1-7629

AC Security Management and Communication

Mode of Operation

Sender S K7s,R

Receiver R

challenge K7p,R

SIGN

signed response

=?

VERIFY

Figure 3

Challenge/response mechanism

Data integrity by signature on hash value To transfer large data volumes (i.e. files) via a connection in an intact way, the digital signature is used after performing the hash function. This results in a hash value which is signed before being transferred. The senders signature is verified by the receiver to be sure of the data integrity (see Figure 4): The sender hashes the data stream and signs the hash value with its own K7s. The receiver verifies the signature by using the senders K7p. This result is compared with the hash value obtained at the receivers side. The hash function can be omitted when small data volumes have to be transferred in an intact way.
Sender S data stream HASH K7s,S and K7m,S K7p,S HASH Receiver R

SIGN

signed hash value

VERIFY

=?

Figure 4

Signature mechanism

Example with basic security functions Figure 5 shows an example of how the SMC transmits a secret key to the AC in a confidential, authenticated and intact way: The data stream consists of the secret key being encrypted with the public key of the AC. In order to be able to ensure integrity, the stream is submitted to a hash function in the SMC. The resulting hash value is signed by the SMC. After verification, the result is compared with the hash value obtained in the AC. If both match, the data stream will be stored there. The AC then has the possibility of decrypting the data by using its secret key.

A50016-E1113-C3-1-7629

Id:0900d80580093f12

13

Mode of Operation

AC Security Management and Communication

K7p,AC

SMC

AC

K7s,AC

Secret key

A7

encrypted data stream

A7

Hash

K7s,SMC K7m,SMC

Hash K7p,SMC

A7 Sign

signed hash value

A7 Verify

Compare

Figure 5

Secret key transmission from SMC to AC

2.2.6

Increased Key Lengths


Increased K2/K4 length When the Ki or V_Ki is initially entered in the system, it is done in an encrypted way. To improve the level of security regarding the increased computer power, the length of the K2 and K4 keys can be increased by the feature Increased K2/K4 length. It supports K4 keys of 8 bytes (data encryption standard, DES) or 32 bytes (advanced encryption standard, AES) to be stored on the IOP:AUC. The K2 generated by the IOP:AUC is 32 bytes (AES key) and is only known in unencrypted form by the IOP:AUC. For support of this feature an IOP:AUC2 or higher is required (board and firmware). Short K4 keys (8 bytes) can be entered regardless of the presence of the feature Increased K2/K4 length. Increased K7 length This feature allows the length of the K7 key to be increased. The operator can choose between the following values: 512, 1024, 2048 or 4096 bits. An IOP:AUC2 or higher is required for the feature. Due to performance reasons it is recommended to not exceed 2048 bits when using the IOP:AUC2. The recommended length to be used with the IOP:AUC3 is 4096 bits. The operator is provided with increased key management security and thus with reduced probability of fraud for the mobile subscribers.

2.2.7

K10 Key
If the feature Increased K7 length is active, the secret keys K2, K4 and K7 are encrypted internally in the authentication center with the A10 algorithm using the K10 key. Instead of a signature a message authentication code (MAC) is used. If no K10 key exists the IOP:AUC generates one. It is stored on the IOP:AUC and is encrypted with the AC master set in CMY. When the AC master set is changed on the IOP:AUC, the latter generates a new random K10.

14

Id:0900d80580093f12

A50016-E1113-C3-1-7629

AC Security Management and Communication

Mode of Operation

The K10 key is used: to encrypt all secret keys that have to be stored in CMYto decrypt all secret keys that are transferred from CMY to IOP:AUCto encrypt all keys that are transferred to another IOP:AUCto decrypt all keys that are received from another IOP:AUC

2.3

Key and Algorithm Storage


All keys (Table 1) and associated cryptographic algorithms (Table 2 to Table 5) are installed in the security box in a protected way. This box is implemented in the AC as an IOP:AUC. As far as the AC database in the common memory is concerned, it only stores key organization data (i.e. key identities, algorithm indicators and secured backup data), no clear data. Key K2 K4 K7s,AC Storage key: to store Ki, K and V_Ki encrypted in the AC Session key (also called transportation key): to transport Ki, K and V_Ki to the AC Secret master AC key: to decrypt K4 received from PCS to sign messages sent to SMC or PCS to decrypt a new K7s,AC received from SMC to sign/decrypt internal AC messages (e.g. backup keys in common memory) to encrypt/sign K10, if in use K7p,AC Public master AC key: to store K4 encrypted on transport medium to verify/encrypt messages signed internally (e.g. backup) to encrypt/sign K10, if in use K7p,SMC K7p,PCS K10 Public SMC key: to verify messages signed by SMC Public PCS key: to verify messages signed by PCS In case of increased K7 length, the K10 key is used: to encrypt all secret keys that have to be stored in CMY to decrypt all secret keys that are transferred from CMY to IOP:AUC to encrypt all keys that are transferred to another IOP:AUC to decrypt all keys that are received from another IOP:AUC Table 1 Keys stored in the security boxes Purpose

A50016-E1113-C3-1-7629

Id:0900d80580093f12

15

Mode of Operation

AC Security Management and Communication

Algorithm A2 A4 A7

Purpose to encrypt Ki, K and V_Ki before its storage to decrypt the stored key in order to use it as input for vector calculations to encrypt/decrypt data before its transmission/after reception to encrypt data in such a way that the receiver only can decrypt it using A7 as well to sign/verify the data to hash large data volumes to encrypt the K2, K4 and K7 key in case of increased K7 length Algorithms for general key management

A9 A10 Table 2

Algorithm A3 A8 Table 3

Purpose to calculate the signed response (SRES) of a triplet (which contains the SRES, the cipher key Kc and a random number RAND) to calculate the cipher key Kc of a triplet Algorithms for 2G subscriber key management

Algorithm f1-f5

Purpose f1: to calculate the message authentication code (MAC) f2: to calculate the expected response (XRES) f3: to calculate the cipher key (CK) f4: to calculate the integrity key (IK) f5: to calculate the anonymity key (AK) MAC and AK are used to calculate the authentication token (AUTN), which combined with XRES, CK, IK and a random number (RAND) constitutes a quintet.

f1*/f5*

f1*: to calculate the re-synchronization message authentication code f5*: to calculate the re-synchronization anonymity key The results from the algorithms f1*/f5* are then used to calculate the sequence number (SQN).

Table 4

Algorithms (functions) for 3G subscriber key management

Algorithm A8_V

Purpose to calculate the short term key VSTK (required to calculate cipher key V_Kc) Algorithms for group call key management

Table 5

16

Id:0900d80580093f12

A50016-E1113-C3-1-7629

AC Security Management and Communication

Mode of Operation

2.4

Key Management Functions


In addition to the authentication keys and master group keys used to generate authentication vectors and ciphering vectors, the AC has to manage other types of key e.g., K4 and K7. These are used together with cryptographic algorithms to ensure secure communication between the different network elements. The network operator is allowed to install or update K4 and K7 keys that are stored in each security box in a non-volatile way by executing the following key management functions: initial key loading key distribution to other security boxes public key update master AC key set update session key management These functions are described below. Initial key loading This function applies either to the first installation of the master AC keys (K7p,AC and K7s,AC) and the public SMC key (K7p,SMC) in a security box, or to recovery purposes. These keys are stored on two chip cards. The keys on both chip cards are loaded into the security box to which a chip card reader has been permanently connected. A PIN code is used for verification. Subsequently key distribution is started. If the feature K4 entry with MML commands is provided, K4 keys can be administrated by the operator himself. If requested the AC is initialized with a K4 key set that is made known to the operator. Otherwise the operator has to enter a K4 himself. Key distribution between security boxes This function applies to the secure distribution of keys from one security box to all other active security boxes. This function also applies when a new security box must be configured. A specific mechanism is used to transfer the encrypted keys to another security box via the common memory without transmitting the appropriate encryption key as well. To this end a key distribution protocol is used from which the basic algorithmic functions are initially installed in each security box.

2.4.1

Public Key Update


This function applies to the alteration of the public SMC or PCS key (K7p,SMC and K7p,PCS) in each active security box. The SMC sends the new public key to the authentication center after having signed it with the secret SMC key; the key is not encrypted. The new key will be distributed to each active security box where the signature is verified before installing the key. The SMC also provides a validation time in order to ensure a synchronous update of the public key in the whole network. The key is validated by deleting the old public key.

A50016-E1113-C3-1-7629

Id:0900d80580093f12

17

Mode of Operation

AC Security Management and Communication

2.4.2

Master AC Key Set Update


This function applies to the alteration of the public and secret AC keys (K7p,AC and K7s,AC) in each active security box. Two mechanisms are possible: 1. A new master set is entered at the SMC Using SAS or MML the SMC sends the new keys to the authentication center after having signed both with the secret SMC key; the new secret AC key is encrypted first with the old public AC key. The new keys are loaded into one security box where the signature is verified and the new AC secret key is decrypted before installing the keys. Key distribution to all other active boxes is then performed. The SMC also provides a validation time in order to ensure a synchronous update of the public AC key in the whole network. The keys are validated by deleting the old master AC key set. 2. A new master set is installed at the AC The master keys actually installed can be replaced by new ones being stored on two chip cards. The keys are loaded into one security box using the appropriate MML command. After key distribution to all other security boxes, the new master set will be active immediately.

g Altering the master AC keys implies that all secured backup data needs to be
reencrypted and resigned with the new master keys.

2.4.3

Session Key Management


New session keys K4 can be transferred to the AC either via the SAS or via MML command and/or chip card reader, depending on the project data. A default K4 assures that communication with the partners is always possible. Management via secure application service (SAS) When AC subscriber administration via SAS is enabled, one entry in the K4 table must be reserved for SAS. In this case a maximum of 10 K4 keys can be installed instead of 11 K4 keys in the K4 table. The SAS assures authenticity and data integrity with the transfer of files: SSA file transfer upon installing subscribers in the AC: The PCS sends a new session key to the authentication center after having encrypted it first with the public AC key and then has it signed with the secret PCS key. The new key will be distributed to each active security box where the signature is verified and the new K4 is decrypted before installing this key. This new K4 remains stored in the AC database (encrypted) for the time of the file transfer and its execution. Regeneration of AC subscriber database in a secure regeneration file: In a similar way, the AC can generate a new session key K4 for backing up the AC subscriber database to a regeneration file in a secure way. Management via MML and/or chip card reader One of the following options for K4 can be installed in a project: Multiple K4 Up to 10 K4 keys are stored in the ACs security boxes using a project-specific software patch. Additionally the default K4 remains available. Upon subscriber installation (or master group key installation) in the AC an additional parameter has to be provided with the create commands, i.e. the K4 identity.

18

Id:0900d80580093f12

A50016-E1113-C3-1-7629

AC Security Management and Communication

Mode of Operation

The latter defines the K4 key the AC has to select in its security box for the decryption of A4(Ki) (or A4(V_Ki)). Administrable K4 This option allows to replace the 11 K4 keys currently installed by new ones. New K4 values can be generated by a PC tool, stored onto two chip cards (protected by a PIN) and loaded into one security box using the appropriate MML command. After distribution to all other active boxes, the new K4 keys will be ready for use. The default K4 key can also be changed. In order to execute regeneration or create commands without specifying the identity of a K4 to be used, the active one will be taken. Therefore, the operator must define such active K4 beforehand by MML command. This option requires an IOP:AUC2 or higher. K4 entry with MML commands This option allows to enter 11 K4 keys remotely using MML commands. The program for writing K4 keys on chip cards, in the Administrable K4 option, calculates the K4 keys and generates the MML commands to install the K4 keys. After distribution to all active security boxes, the new K4 keys are ready to be used. The default K4 key can also be changed. This option requires an IOP:AUC2 or higher.

To transfer a command file using SAS functions, the K4 key for composing the file is included. This means that one temporary K4 key entry in the K4 table has to be reserved for SAS. This one K4 will be stored in the AC for as long as file execution takes (thus limited in time). The consequence is that maximum 10 K4 keys can be modified instead of 11 K4 keys as described above.

2.5

Security Functions
The following security functions are described below: secured logging for AC subscriber data secure regeneration of AC database reencryption of the AC database security records and alarms

2.5.1

Secured Logging for AC Subscriber Data


Secured logging only needs to be applied if AC subscribers have to be installed via ASA files. Such a file contains commands in ASN.1 notation for subscriber administration. Logging is then performed: upon secure installation of AC subscribers, or upon secure regeneration of the AC subscriber database Upon the installation of AC subscribers a log file is created as follows: 1. The network operator assigns the HLR codes via a local terminal. Upon their creation, the appropriate MML commands are also entered in a standard log file. 2. The operator then creates AC subscribers in the AC by means of a secure subscriber administration (SSA) file. For each AC subscriber this administration file

A50016-E1113-C3-1-7629

Id:0900d80580093f12

19

Mode of Operation

AC Security Management and Communication

contains a create command in ASN.1 notation with specific data (i.e. MSIN and A4(Ki)) as well as the session key (K4) in an encrypted and signed form. Upon execution of this file on behalf of the first subscriber a secure log file is created. An MML command to activate an associated log file is written into the existing standard log file. 3. During the further execution of the administration file, creation data in ASN.1 notation of each successfully installed subscriber is logged in the secured log file. 4. As soon as the administration file is completely executed, the encrypted and signed K4 is written into the secured log file together with a signature calculated for the complete file. At this point the log file is effectively secured.

2.5.2

Secure Regeneration of AC Database


In order to securely back up the AC database (ACHLR identifications, AC subscriber data and voice group service ID data) to a regeneration file, the security box generates a new session key K4, which is used for the following purpose: for each record the authentication key or master group key must be encrypted using A4 and stored in a file. This file also contains the new K4 in an encrypted form and the complete file is signed. The procedure is illustrated in Figure 6: The appropriate K2 is identified using the K2id stored in the record. The encrypted authentication key or master group key is decrypted using this K2. Afterwards it is encrypted again using the new K4 identified by the K4ref assigned upon creation of the regeneration file. These calculations are performed by two security boxes in parallel. If both security boxes deliver the same results, the encrypted authentication key or master group key and the encrypted K4 are stored in the regeneration file. The other data contained in the corresponding record is also stored in the regeneration file (see Figure 6 e.g., for 2G subscriber: MSIN, A3ind and A8ind).

Command data K4ref Key database

Security box

Regeneration file

2G Subscr record 3G Subscr record VGS record K2id A2(V_Ki) group ID serv type V_Ki ID A8_Vind A5ind K2id A2(K) MSIN fi ind SQN AMF K2id A2(Ki) MSIN A3ind A8ind

K2

K4

A7

A7(K4)

A2

Ki/K V_Ki

A4

A4(Ki/K/V_Ki)

}
Figure 6

Secure regeneration of AC subscriber database

20

Id:0900d80580093f12

A50016-E1113-C3-1-7629

AC Security Management and Communication

Mode of Operation

2.5.3

Reencryption of the AC Database


From time to time the AC database needs to be reencrypted in order to keep it secured by changing the storage key K2. Its semipermanent data contain, among other things, the encrypted authentication key Ki of each subscriber and master group keys for group calls. The encryption has been performed by the A2 algorithm using storage key K2. To this end a K2 identifier is included in each record. When the operator chooses the option Increased K2/K4 length and reencryption is done, the short K2 key will be replaced by a long K2 (32 bytes). From then on K2 will be a long key (> 8 bytes). The reencryption uses the new storage key K2. This reencryption process is activated by an MML command or in the SMC via the SAS sublayer: The coordination processor requests an active security box to generate a new K2. This K2 is stored in the common memory, after being encrypted by the public AC key and signed by the secret AC key. Then the new K2 is distributed from the common memory to each active security box. The reencryption is started in blocks of records. The encrypted authentication key or master group key of each record is decrypted with the old K2, immediately encrypted with the new K2 and subsequently stored again. For reliability, reencryption is executed by 2 security boxes at the same time for the complete record block. When the results thereof match, the reencryption is considered successful. Upon completion of the reencryption, the old K2 is deleted in all active security boxes.

2.5.4

Security Records and Alarms


Security events result from actions with respect to AC data and AC equipment which could be harmful for the subscribers or for the operating company. These events are recognized, identified and transferred to a network entity for security events handling. According to the events importance, it is either stored as a security record on a file named AC.SECUR or transmitted as a security alarm. Security records Security records are reported by events, such as access to or reencryption of the AC database, managing of keys, execution of an algorithm test of a security box, etc. The security records are transferred to a cyclic file on a duplicated disk in the AC. Actions in the SMC allow file transmission from AC to SMC. Postprocessing of these records allows the operator to be informed of all actions, which could possibly attack the security in one way or another. Enhanced security record logging The security related events described above are enhanced so that every event gaining access to authentication keys or master group keys is logged into a file named AC.SECUR. The logged data minimally consists of the following data: time and date of the event the network component to which the event belongs a unique event identifier the operator ID

A50016-E1113-C3-1-7629

Id:0900d80580093f12

21

Mode of Operation

AC Security Management and Communication

the terminal ID The transfer mechanism using FTAM services (or any other file transfer mechanism from the CP) is not impacted by this enhancement of security records. However, postprocessing using a PC tool is needed to interpret the logged records. When enhanced security record logging is applied, an additional security event called regeneration of the AC subscriber database is supported. When a secure or nonsecure regeneration of the AC database is executed, a security record will be generated. This is not the case when enhanced security record logging does not apply. This feature (enhanced security record logging) is not supported for SAS users. Interaction with the SAS sublayer is avoided. Security alarms Security alarms are reported by events, such as manual access to a security box, configuration of a security box, or a security record file is filled up. Upon the generation of a security alarm, it is immediately sent to the SMC via the SAS server. If SAS has not been installed, an alarm is transferred as a security record to the file concerned.

2.6

Operational Condition
Because it is possible to manage a number of secret keys in the security boxes, the latter can only be operational provided that they have all correct keys at their disposal. If none of the security boxes has the right keys, the following functions have to be performed: 1. Initial key loading via chip cards to restore the master AC keys and the public SMC key. 2. Configuration of the appropriate security box to active. Note: A situation where no active IOP:AUCs are available should only occur on initial system installation, when no AC subscribers exist in the AC subscriber database yet. Activation of the first IOP:AUC in a system where AC subscribers already exist may cause severe problems. (The IOP:AUC does not know the K2 needed for decrypting the stored authentication keys.) This is why the last active IOP:AUC cannot be deactivated. 3. This security box now contains sufficient keys to perform the requested key management functions via SAS server. 4. Being in an active state, the other security boxes can receive the proper keys by means of the distribution function.

2.7

Secure Communication
The HLR/AC network node is linked with OMS elements via a packet switched data network (PSDN), according to X.25 CCITT. X.25 complies with the open system interconnection (OSI) layer-structured signaling system. Each layer defines a set of rules and procedures performing specific tasks in the context of exchanging management information. The OSI application layer protocol as presented in Figure 7 consists of: secure application service (SAS) to ensure authenticity and data integrity with the transfer of files and the exchange of information

22

Id:0900d80580093f12

A50016-E1113-C3-1-7629

AC Security Management and Communication

Mode of Operation

file transfer access and management (FTAM) to exchange large data volumes common management information service element (CMISE) to transfer the correct information application control service element (ACSE) to control the connections remote operation service (ROSE) to provide a common framework Specific functions of AC processes between either the PCS or the SMC on the one hand and the AC on the other hand can be executed by involving the SAS server in the AC (Figure 7). An overview of these functions is provided in section 3.2.

2.7.1

SAS Server
The secure application service (SAS) server supports the following communication protocols as shown in Figure 7: secure file transfer (SFT) secure management information service (SMIS) Hence authenticity and data integrity with the transfer of files and the exchange of information and commands are ensured. The secure file transfer is provided with specific security criteria enabling the secure transfer of files. Therefore a signed file is transmitted and the receiver confirms the file transfer by a signed receipt. In this way the sender is authenticated and makes sure that neither the file contents have been changed, nor the receiver has rejected the file. The SMIS services provide for the establishment of authenticated connections, which are used to exchange actions and notifications containing signed contents which will be partly encrypted sometimes. SAS directly uses the services of FTAM, CMISE, ACSE and ROSE in order to control the application context for communication with the lower presentation layer: FTAM is used within the AC when huge amounts of information must be exchanged. While the file is transferred with FTAM, CMISE operations are required to perform controlling functions. CMISE provides services to transfer information on managed objects in a structured manner. There are two types of information transfer services: Management operation services are used to convey management information applicable to operations directed at a managed object. Management notification services are used to convey management information applicable to notifications generated by a managed object. ACSE provides control services for the establishment and release of associations (connections). ROSE offers services to remotely invoke operations and then to receive replies to those operations. Therefore, ROSE provides a common framework for constructing application layer protocols. The CMISE services are mapped onto the ROSE services.

A50016-E1113-C3-1-7629

Id:0900d80580093f12

23

Mode of Operation

AC Security Management and Communication

AC BAP OSI layer 7 SAS server AC processes administration SFT SMIS maintenance CP

FTAM ACSE

CMISE ROSE PIO

OSI layers 4 - 6

SB interface

IOC

CMY IOP:SCDP OSI layers 1 - 3 security boxes IOP:AUC ... IOP:AUC AC database subscribers keys

X.25 OMS PCS SMC

Figure 7

Organization of SAS sublayer in the AC

24

Id:0900d80580093f12

A50016-E1113-C3-1-7629

AC Security Management and Communication

Administration

3 Administration
3.1 MML Commands at the SC or CTL
Administration of the core network nodes is performed either at the remote switch commander (SC) with integrated or connected client terminals (CT) or at the craft terminal local (CTL). The switch commander supports Q3, MML and SNMP. It offers a graphical user interface and allows a comfortable way of entering tasks and commands. An overview of the tasks relevant in the context of this document is given in the following. Detailed operation instructions can be found in the operation manuals (OMN) and in the task manual (TML). HLR/AC identification Before a subscriber can be created in the AC, the subscribers HLR ID has to exist. This code represents a part of his identification number. The following MML commands are used to administrate the HLR code: CAN ACHLRID, CR ACHLRID, DISP ACHLRID (cancel, create, display ACHLR identification) AC subscriber administration The administration possibilities for mobile subscriber data in the AC are largely projectspecific and there are several methods to create this data. Upon creation of a mobile subscriber in the AC, an entry is also made in the security file. If there is a specific authorization allowing the relevant command to be entered from the terminal, direct administration of the mobile subscribers in the AC is possible via the following MML commands: CR ACMSUB, DISP ACMSUB, CAN ACMSUB (create, display, cancel AC mobile subscriber) When creating a 3G subscriber in the AC, the version of the authentication functions to be used has to be specified. Furthermore up to two sets may be available per version (prerequisites for two sets: feature ACALGSET active and IOP:AUC2 or higher available that supports the feature ACALGSET). The following MML commands allow to administer which of the two sets serves as default set: DISP ACALGSET, ENTR ACALGSET (display, enter AC algorithm set) Another way to administrate subscribers in the AC is by using commands to handle a secure subscriber administration (SSA) file from disk. Such a file contains create commands in ASN.1 notation for all AC subscribers, a new K4 in encrypted form, and a signature of the complete file. After the SAS server of the AC has verified the signature as well as the authorization of the file originator, the subscribers are installed. The creation of 3G subscribers in the AC is possible via the SAS layer but with some restrictions. The following MML commands are used to administrate the execution of an SSA file: ACT SSAFILE, DACT SSAFILE, DISP SSAFILE (activate, deactivate, display SSA file)

A50016-E1113-C3-1-7629

Id:0900d80580093f08

25

Administration

AC Security Management and Communication

Voice group service ID administration (ciphering of voice group call channel) Voice group service IDs are administered in the AC using the following MML commands: CR VGSID, DISP VGSID, ACT VGSID, MOD VGSID, CAN VGSID (create, display, activate, modify, cancel voice group service ID) Upon creation of a VGSID in the AC, an entry is also made in the security file. Roaming area for SCCP segmentation The following MML commands are used for administration of a special roaming area called SCCPSGMA: CR ROAMAREA, DISP ROAMAREA, MOD ROAMAREA, CAN ROAMAREA (create, display, modify, cancel roaming area) Project data The following MML commands allow to administrate the default AMF value to be used in the calculation of the AUTN parameter of a quintet: ENTR MPRDDAT, DISP MPRDDAT (enter, display mobile project description data) Activation of features The security features can be activated or deactivated. Some examples of feature short names related to the security features in the AC are listed in Table 6. description disablement of local administration of the AC subscriber database administration of subscriber data and VGSIDs via CMISE AC mobile subscriber administration via SAS security record logging enhanced security record logging initiate reencryption of AC subscriber database via MML initiate reencryption of AC subscriber database via SAS "secure" regeneration/logging without SAS security key administration via MML security key administration via SAS multiple K4 algorithms K4 administration (with chip cards or by direct input) increased K7 length increased K2/K4 length (dependent on hardware and firmware) two sets of 3G authentication functions ciphering of voice group calls (voice group call channel and dedicated channel) generate VSTK_RAND as full random number without counter part SCCP segmentation for quintet delivery Table 6 Examples of security features in the AC short name BLKACSUB SUBCMISE SUBSAS SECSSS SECSSSAK RESUBMML RESUBSAS SECREG KEYMML KEYSAS MULTIK4 ADMINK4 INCRSAKL ACALGSET CIPHVGC FULLRAND SCCPSGMA

26

Id:0900d80580093f08

A50016-E1113-C3-1-7629

AC Security Management and Communication

Administration

The activation and deactivation of security features can be performed using the following MML commands: MOD MSERVOPT, DISP MSERVOPT (modify, display mobile service options) Secure regeneration of AC database Secure functions allow the operator to use MML commands to produce a regeneration file, to activate logging and to execute the regeneration file by creating subscribers and VGSIDs in the AC. The following MML command is used to initiate regeneration of the database: EXEC REGEN (execute regeneration) The regeneration file contains the following MML commands: ENTR ACALGSET(enter AC algorithm set) CR ACHLRID (create AC HLR identification) ACT SSAFILE (activate SSA file) SET LOG (set log function) EXEC CMDFILE (execute command file) Upon file execution, the command to execute the associated SSA log file is automatically added to the standard log file. AC database reencryption The following MML command is used to generate a new K2 and subsequently reencrypt the AC subscriber database (containing data of AC subscribers and VGSIDs): ACT RENCRYPT (activate reencryption) Key management The following MML commands are used to administrate the asymmetrical keys K7: MOD ASYMKEY, CAN ASYMKEY, ENTR ASYMKEY (modify, cancel, enter asymmetrical keys) The following MML commands are used to administrate the symmetrical key K4: MOD SYMKEY, CAN SYMKEY, ENTR SYMKEY, ACT SYMKEY, DISP SYMKEY (modify, cancel, enter, activate, display symmetrical key) Security events The following MML command is used to transfer the contents of the security buffer to the AC disk: TRANS SCRTBUF (transfer security buffer) The following MML command can be used to handle the security records file. It is also possible to associate an ASN.1 conversion process with this security records file: TRANS FILE (transfer file) Diagnose / test for security box The following MML commands are used to execute tests in a security box, either in a maintenance blocked or in an active state: DIAG ACALGOR, TEST ACALGOR (diagnose, test AC algorithms) The following MML command is used to initiate single, repeated or permanent diagnostic runs for an IOP:AUC: DIAG IOP (diagnose input/output processor)

A50016-E1113-C3-1-7629

Id:0900d80580093f08

27

Administration

AC Security Management and Communication

3.2

Inputs at the PCS and SMC


This section gives an overview of the tasks to be carried out in the PCS and the SMC via the SMIS or SFT services of the SAS sublayer installed there. A direct X.25 connection is available for communication with the AC. Functions concerning the following subjects can be initiated using services of the SAS sublayer: Functions from the PCS: AC subscriber data administration Functions from the SMC: AC subscriber database reencryption key management security record handling security alarm handling security box tests

3.2.1

Primitives at the PCS


For secure file transmission the PCS composes a signed transfer file from the original file and sends it via FTAM to the AC. The AC uses the transfer file to restore the original file and to calculate a signed response (SRES) which it sends to the PCS. The PCS verifies the SRES. AC subscriber data administration The operator in the PCS can administer AC subscribers using Secure File Transfer (SFT) services. To this end the appropriate commands are put in an ASN.1 Subscriber Administration (ASA) file. Then the following actions are performed: A secure file transfer request is initiated from the PCS. Upon file transfer, the AC reads the commands of the ASA file and consequently calculates authentication vectors. When the AC has executed all commands, it informs the PCS via SFT services by means of a response file with the installation results for each subscriber. Please note that MML commands have to be used first for the administration of the subscribers HLR ID which is part of his identification number.

3.2.2

Primitives at the SMC


A secure action request can be sent from the SMC to the AC. Each successful action request results into a confirmation, indicating its acceptance. This means that the command has been correctly received and executed. When the AC has to notify the SMC of something, it invokes a secure event report request. Each notification is confirmed by a secure event report indicating the acceptance or non-acceptance of the message. AC subscriber database reencryption The operator in the SMC can initiate a reencryption of the AC subscriber database (see section 2.5.3) using the Secure Management Information Service (SMIS). Key management The operator in the SMC can update the public PCS or SMC key or the master AC key set using the SMIS services (see section 2.4).

28

Id:0900d80580093f08

A50016-E1113-C3-1-7629

AC Security Management and Communication

Administration

Security record handling The operator in the SMC can transfer security records (see section 2.5.4) from the AC using SFT services. Security alarm handling Upon the generation of a security alarm (see Section 2.5.4), it is immediately sent to the SMC via the SAS server using SMIS services. If SAS has not been installed, an alarm is transferred as a security record to the file concerned. Security box tests The operator in the SMC can initiate the following tests in a security box: An vector test can verify whether the security box generates correct vectors for each version of the algorithms and functions. A test of the A4 algorithm can verify whether it encrypts and decrypts test patterns in a correct way. A random generator test can verify whether random numbers are created correctly. A second test of the A2/A4 algorithm is possible according to the data encryption standard (DES) test as defined by the National Bureau of Standards (NBS). A data integrity test can check whether the security boxes still contain correct data and whether their programs are intact.

A50016-E1113-C3-1-7629

Id:0900d80580093f08

29

Compatibility with other Features

AC Security Management and Communication

4 Compatibility with other Features


SAS incompatible features SAS is incompatible with the following features: increased K2/K4 length increased K7 length initial key loading common solution administrable K4 with MML commands or Multiple K4 via patch administration of authentication function set to be used (the default set is used) administration of authentication management field (AMF) when creating a subscriber in the AC enhanced security record logging ciphering of voice group call channels K4 key administration The feature Administrable K4 with MML commands and the feature Multiple K4 via patch cannot be used simultaneously and once MML commands have been entered, patches can no longer be used. Increased K7 key length This feature is incompatible with: multiple K4 patches key administration via SAS IOP:AUC (only IOP:AUC2 and higher support this feature) Once activated, this feature cannot be switched off. Ciphering of voice group call channels This feature is incompatible with: subscriber administration via SAS VGCS one channel model IOP:AUC and IOP:AUC2 (at least IOP:AUC3 is required)

30

Id:0900d80580093f09

A50016-E1113-C3-1-7629