
Advanced Wireless Networks - 4G Technologies
.pdf
598 SECURITY
(a)
Key generation
Select p,q (p,q prime)
Calculate n=pq
Calculate φ (n)=(p-1)(q-1)
Select integer e (gcd (φ(n),e)=1, 1< e <φ(n))
Calculate d (d=e−1 mod φ(n))
Public key KU=[e,n]
Private key KR=[d,n]
Encription
Plaintext M<n
Ciphertext C= M e (mod n)
Decription
Ciphertext C
Plaintext M= Cd (mod n)
(b) p=17
q=11
n=pq=187 φ(n)=(p-1)(q-1)=160 e=7
d=23 (de mod 160=1)
KU=[7,187]
KR=[23,187]
M=88 Ciphertext
C = 887 mod187 = 11
Plain text
M = 112323mod187 = 88
Figure 15.8 (a) Operation of a public key encryption system; (b) numerical example of operation of a public key encryption system.
Finally, it may be instructive at this point to describe the operation of public key encryption system used for authentication. In this case user generates pair of keys and places one key in the public domain. To send a message the user encrypts using the public key and decrypts using a private key as illustrated in Figure 15.8(a); a numerical example is given in Figure 15.8(b).
SECURITY ARCHITECTURE |
599 |
15.2 SECURITY ARCHITECTURE
Cryptography provides only two fundamental services, namely, confidentiality and authentication. All communications security services are concerned with the identity of the senders or recipients of information. Cryptography allows users to be identified by allocating secret keys to them. There are only two ways that cryptography can work, and these define the fundamental services [22, 23]:
Confidentiality – only the user (or set of users) in possession of the secret key can read the message;
Authentication – only the user (or set of users) in possession of the secret key can write the message.
A secure channel can be thought of as a relationship between two system users which provides some security services.
In this section, two basic types of secure channel are considered, namely, confidentiality channels and authentication channels. In addition, we define symmetric channels, each of which may coincide with a confidentiality channel, an authentication channel or both.
In a conventional symmetric cipher, a pair of users share the same key. This symmetric channel typically provides both a confidentiality and an authentication channel between a specific pair of users. Symmetric ciphers can also be used to provide authentication alone, as when a message authentication code is used [25].
A public key cryptosystem, as described above, usually has one public key and a corresponding secret key. For certain algorithms, such as RSA [31], the public key may be used for confidentiality and the secret key may be used for authentication. However, for other algorithms, it may be that only one channel is provided. For example, signature schemes provide authentication but not confidentiality,while schemes such as the McEliece algorithm [25] are suitable for authentication but not confidentiality.
There are three components that make up a security architecture in the model of this paper: (1) users; (2) trusted users, including information on who trusts whom; and (3) secure channels, which may provide confidentiality authentication or both.
The formal model is a relatively simple specification and defines a state-based sequential system as described in Spivey [32]. The first line of the specification defines the abstract types which will be used. These are users and keys [User, Key] and they are fundamental values in the model. Other components, such as secure channels and trusted users, will be defined in terms of these sets.
Next, some global, or axiomatic, definitions are made. These are things that are not expected to change within the model and so can be excluded from the rest of the system state. Five sets of keys are defined concerning two separate properties. A key must be in exactly one of the sets public, secret, shared; in other words, these sets partition ( ) the keys. In addition, a key must be a confidentiality key (in the set Conf ) or an authentication key (in the set Auth) or both. The dual, or inverse, is defined for each key. Taking the dual of a key is a self-inverse operation. The dual of a confidentiality key is still a confidentiality key and similarly for authentication keys. Secret and public keys are interchanged under the dual map, while the dual of a shared key is still shared. The trusted users are defined by a map which defines those users trusted by each user. For a formal representation of the

600 |
SECURITY |
||
|
|
|
Table 15.1 Special Z symbols |
|
|
|
|
Symbol |
|
Meaning |
|
|
|
||
f : X → Y |
Function between X and Y |
||
f : X ↔ Y |
Relation between X and Y |
||
id X |
|
The identity function on X |
|
dom f |
|
The domain of f |
|
ran f |
|
The range of f |
|
f (|X|) |
|
Image of the set X under the function f |
|
f |
g |
|
Function which takes values of the function f except on the domain of g, |
|
◦ g |
|
where it takes the values of g |
f |
|
Functional composition where the domain of g must equal the range of f |
|
X \ Y |
|
Set difference of X and Y |
|
X |
|
the set of sets with elements of X as values |
system components, notation from Table 15.1 known as Z notation [32] is used, resulting in [21]:
Shared, Public, Secret, Auth, Conf : Key dual : Key → Key
Trusted : User → User
(Shared, Public, Secret) partition Key Auth Conf = Key
dual ◦ dual = id Key dual(|Conf|) = Conf dual(|Auth|) = Auth dual(|Shared|) = Shared dual(|Public|) = Secret dual(|Secret|) = Public
The first ordinary schema defines the variable that records what keys are known by each user, and with whom they are associated.
Keys
keys : User → (User × Key)
A set of (user, key) pairs is associated to each user, where ‘x maps to (y, k)’ means that x knows key k and uses it in communications with user y. The following three schemas define the state space of the model by giving formal definitions of secure channels in terms of possession of keys.

SECURITY ARCHITECTURE |
601 |
Confidentiality channels
Keys
ConfChannels : User → User
x, y : User (x, y) ConfChannels
{ k: Conf \ Secret; z:
User (y, k) keys(x) [z, dual(k)] keys (y)}
Confidentiality channels define relations between pairs of users. These are ordered pairs as the channel may be in only one direction. It will be noticed that the definition is not symmetrical with respect to x and y. The predicate states that, for a confidentiality channel to exist from x to y, there must be a key whose use includes confidentiality and is either shared or public; x must associate this key with y; y must know the dual of the key. In the model, this means that y must associate it with some user(s), but it is not of any concern to y exactly which users know the key. To see why this is reasonable, consider a public key system providing confidentiality to y. Any user z who knows the public key of y has a confidentiality channel to y, and it is important to z that it is only y who has the secret dual key; y must of course know the secret key, but it does not matter to y who knows the public key. This corresponds to the viewpoint that confidentiality is a service provided to the sender of information.
Authentication channels
Keys
AuthChannels : User → User
x, y : User (x, y) AuthChannels
{ k : Auth \ Public; z : User
(z, k) keys(x) [x, dual(k)] keys(y)}
Authentication channels also define relations between pairs of users. The definition of authentication channels is dual to the definition of confidentiality channels and corresponds to the viewpoint that authentication is a service provided to the receiver of information.
Symmetric channels
Keys
SymmChannels : { (User)}
SymmChannels {x, y : User|x =y {x, y}}
x, y : User (x, y) SymmChannels
{( k : Shared (y, k) keys(x) [x, dual(k)] keys(y)}

602 SECURITY
Symmetric channels are in both directions and so are defined as sets of two different users. They correspond to the situation where neither key is public, and in practice the key and its dual are usually equal.
State
ConfidentialityChannels
AuthenticationChannels
SymmetricChannels
The system state is defined exactly by what keys are known by each user, thereby defining what secure channels exist.
Transfer
State
orig?, dest?, recip?, sender? : User
k? : Key
(orig?, k?) keys (sender?)
keys = keys {recip? → keys(recip?) (orig?, k?)}
This schema says that if a key k? is sent from one user to another, then the keys known to the recipient are updated to associate the key sent with the originator. In this model, the only state changes are those which happen as a result of passing keys from one user to another. Such a key exchange may or may not result in new channels being formed. The key passes from the sender to the recipient. It may be that the users between whom communication is intended (originator and destination) are different from the sender and recipient involved in a particular exchange. This is the situation if the sender is a key server. The recipient will therefore associate the received key with the originator, who may or may not be the sender.
SecureTransfer
Transfer
k? Secret (sender?, recip?) ConfChannels k? Public (sender?, recip?) AuthChannels
k? Shared (sender?, recip?) ConfChannels ∩
AuthChannels
orig? =sender? k? Public Shared
sender? Trusted(recip?)
recip? =dest? k? Secret Shared
recip? Trusted(sender?)
KEY MANAGEMENT |
603 |
This schema specifies the conditions which must exist if a key exchange should be performed securely: (1) secret keys may only be transferred over a confidentiality channel;
(2) public keys must be transferred over authentication channels; (3) if the key is to be shared, the channel should provide both confidentiality and authentication since both users need to associate the key only with each other; (4) if the key is public or shared then the recipient must trust the sender, unless the sender is the originator; this is because the key must be correctly assigned to the originator; and (5) if the key is secret or shared, then the sender must trust the recipient not to reveal it, unless the recipient is the destination. More details on formal protocol presentation can be found in References [21–32].
15.3 KEY MANAGEMENT
Information protection mechanisms, discussed so far in this chapter, assume cryptographic keys to be distributed to the communicating parties prior to secure communications. The secure management of these keys is one of the most critical elements when integrating cryptographic functions into a system, since even the most elaborate security concept will be ineffective if the key management is weak.
An automatic distribution of keys typically employs different types of messages. A transaction usually is initiated by requesting a key from some central facility (e.g. a key distribution center, KDC), or from the entity a key is to be exchanged with. Cryptographic service messages (CSMs) are exchanged between communicating parties for the transmission of keying material, or for authentication purposes. CSMs may contain keys, or other keying material, such as the distinguished names of entities, key-IDs, counters or random values. CSMs have to be protected depending on their contents and on the security requirements. Generic requirements include the following:
(1)Data confidentiality should be provided while secret keys and possibly other data are being transmitted or stored.
(2)Modification detection prevents the active threat of unauthorized modification of data items. In most environments, all cryptographic service messages have to be protected against modification.
(3)Replay detection is to counter unauthorized duplication of data items.
(4)Timeliness requires that the response to a challenge message is prompt and does not allow for playback of some authentic response message by an impersonator.
(5)Entity authentication is to corroborate that an entity is the one claimed.
(6)Data origin authentication (proof/nonrepudiation of origin) is to make certain that the source of a message is the one claimed.
(7)Proof/nonrepudiation of reception shows the sender of a message that the message has been received by its legitimate receiver correctly.
(8)Notarization is the registration of messages to attest at a later stage its content, origin, destination or time of issue.
604 SECURITY
The correctness of key management protocols requires more than the existence of secure communication channels between entities and key management servers. For example, it critically depends on the capability of those servers to reliably follow the protocols. Therefore, each entity has to base its deductions not only on the protocol elements sent and received, but also on its trust in the server which, for that reason, often is called the trusted party.
Key management is facilitated by the key management services, which include entity registration, key generation, certification, authentication, key distribution and key maintenance.
Entity registration is a procedure by which an individual or a device is authenticated to the system. An absolute identification is provided if a link between an ID (e.g. a distinguished name or a device-ID) and some physical representation of the identified subject (e.g. a person or a device) can be established. An identification can be carried out manually or automatically. Absolute identification always requires at least one initial manual identification (e.g. by showing a passport or a device-ID).
Mutual authentication is usually based on the exchange of certificates. In any system, an entity is represented by some public data, called its (public) credentials (e.g. ID and address). Besides that, an entity may own secret credentials (e.g. testimonials) that may or may not be known by some trusted party. Whenever an entity is registered, a certificate based upon its credentials is issued as a proof of registration. This may involve various procedures, from a protected entry in a specific file to a signature by the certification authority on the credentials.
Key generation refers to procedures by which keys or pairs of keys of good cryptographic quality are securely and unpredictably generated. This implies the use of a random or pseudorandom process involving random seeds, which cannot be manipulated. The requirements are that certain elements of the key space are not more probable than others, and that it is not possible for the unauthorized to gain knowledge about keys.
Certificates are issued for authentication purposes. A credential containing identifying data together with other information (e.g. public keys) is rendered unforgeable by some certifying information (e.g. a digital signature provided by the key certification center). Certification may be an on-line service where some certification authority provides interactive support and is actively involved in key distribution processes, or it may be an off-line service so that certificates are issued to each entity only at some initial stage.
Authentication/Verification may be either (1) entity authentication or identification,
(2) message content authentication and (3) message origin authentication. The term verification refers to the process of checking the appropriate claims, i.e. the correct identity of an entity, the unaltered message content or the correct source of a message. The validity of a certificate can be verified using some public information (e.g. a public key of the key certification center), and can be carried out without the assistance of the certification authority, so that the trusted party is only needed for issuing the certificates.
Key distribution refers to procedures by which keys are securely provided to parties legitimately asking for them. The fundamental problem of key exchange or distribution is to establish keying material to be used in symmetric mechanisms whose origin, integrity and confidentiality can be guaranteed. As a result of varied design decisions appropriate to different circumstances, a large variety of key distribution protocols exist [37, 39]. The basic elements of a key distribution protocol are as follows.
KEY MANAGEMENT |
605 |
15.3.1 Encipherment
The confidentiality of a data item D can be ensured by enciphering D with an appropriate key K which is denoted eK(D). Depending on whether a secret key algorithm or a public key algorithm is used for the enciphering process, D will be enciphered with a secret key K shared between the sender and the legitimate recipient of the message, or with the legitimate recipient B’s public key K Bp. Encipherment with the sender A’s private key K As , may be used to authenticate the origin of data item D, or to identify A. Encipherment with a secret key provides modification detection if B has some means to check the validity of D (e.g. if B knows D beforehand, or if D contains suitable redundancy).
15.3.2 Modification detection codes
To detect the modification of a data item D, one can add some redundancy that has to be calculated using a collision-free function, i.e. it must be infeasible to find two different values of D that render the same result. Moreover, this process has to involve a secret parameter K in order to prevent forgery. Appropriate combination of K and D also allows for data origin authentication. Examples of suitable building blocks are message authentication codes, or hash functions combined with encipherment. The generic form of this building block is D||mdcK(D). Modification detection codes (mdc) enable the legitimate recipient to detect unauthorized modification of the transmitted data immediately after receipt. The correctness of distributed keying material can also be checked if the sender confirms his knowledge of the key in a second step (see below).
15.3.3 Replay detection codes
To detect the replay of a message and to check its timeliness, some explicit or implicit challenge-and-response mechanism has to be used, since the recipient has to be able to decide on the acceptance. In most applications, the inclusion of a replay detection code denoted by D||rdc (e.g. a timestamp TD, a counter CT, or a random number R) will only make sense if it is protected by modification detection. With symmetric cryptographic mechanisms, key modification, i.e. some combination (e.g. XOR) of the secret key with an rdc, can be used to detect the replay of a message. A special case is the process of key offsetting used to protect keying material enciphered for distribution where the key used for encipherment is XORed with a count value.
15.3.4 Proof of knowledge of a key
Authentication can be implemented by showing knowledge of a secret (e.g. a secret key). Nevertheless, a building block that proves the knowledge of a key K can also be useful, when K is public. There are several ways for A to prove to B the knowledge of a key that are all based on the principle of challenge and response in order to prevent a replay attack. Depending on the challenge which may be a data item in cleartext or in ciphertext, A has to process the key K and the rdc in an appropriate way (e.g. by encipherment, or by calculating a message authentication code), or A has to perform a deciphering operation. The challenge may explicitly be provided by B (e.g. a random number R) or implicitly be given by a

|
SECURITY MANAGEMENT IN GSM NETWORKS |
607 |
||
|
Table 15.4 Point-to-point key distribution |
|
|
|
|
|
|
|
|
A |
(ISO/IEC CD 9798-2) |
B |
|
|
(1) → |
eKBp(K*)|| rdc|| eKAs (h( eKBp(K*)|| rdc)) |
← (2) |
|
|
|
eK*( rdc) |
|
secret key K * enciphered with B’s public key and an appended rdc. The integrity of the token is protected by A’s signature. This guarantees modification and replay detection, as well as data origin authentication. B responds with the enciphered rdc, thereby acknowledging that it has received the key K*, as shown in Table 15.4.
Key maintenance includes procedures for key activation, key storage, key replacement, key translation, key recovery, black listing of compromised keys, key deactivation and key deletion. Some of the issues of key maintenance are addressed below.
Storage of keying material refers to a key storage facility which provides secure storage of keys for future use, e.g. confidentiality and integrity for secret keying material, or integrity for public keys. Secret keying material must be protected by physical security (e.g. by storing it within a cryptographic device) or enciphered by keys that have physical security. For all keying material, unauthorized modification must be detectable by suitable authentication mechanisms.
Key archival refers to procedures by which keys for notarization or nonrepudiation services can be securely archived. Archived keys may need to be retrieved at a much later date to prove or disprove certain claims.
Key replacement enables parties to securely update their keying material. A key shall be replaced when its compromise is known or suspected. A key shall also be replaced within the time deemed feasible to determine it by an exhaustive attack. A replaced key shall not be reused. The replacement key shall not be a variant or any nonsecret transformation of the original key.
Key recovery refers to cryptographic keys which may become lost due to human error, software bugs or hardware malfunction. In communication security, a simple handshake at session initiation can ensure that both entities are using the same key. Also, message authentication techniques can be used for testing that plaintext has been recovered using the proper key. Key authentication techniques permit keys to be validated prior to their use. In the case where a key was lost, it still may be possible to recover that key by searching part of the key space. This approach may be successful, if the number of likely candidates is small enough.
Key deletion refers to procedures by which parties are assured of the secure destruction of keys that are no longer needed. Destroying a key means eliminating all records of this key, such that no information remaining after the deletion provides any feasibly usable information about the destroyed key.
More information on key management can be found in References [33–39].
15.4 SECURITY MANAGEMENT IN GSM NETWORKS
The authentication generic process is shown in Figure 15.9 [41,42]. The authentication algorithm (called A3 in the GSM specifications) computes from a random number RAND,