Advanced wireless networks 4g technologies phần 8 pps

JWBK083-15 JWBK083-Glisic February 23, 2006 5:29 Char Count= 0 AUTHENTICATION 595 N1 N2 A B N2 N1 XOR B XOR A E(N1 XOR B), E(N2) E(N1 XOR B), E(N2) Figure 15.6 An offset attack (through a parallel session). types or combinations of attacks that involve replaying messages and functions of challenges observed in other runs of the protocol will be collectively referred to as interleaving attacks. Based on the above observations we can specify the following design requirements for authentication protocols: (1) nonce-based (avoid synchronization and stable counter storage); (2) resistant to common attacks; (3) usable at any layer of any network architecture (small messages); (4) usable on any processing base (few computations); (5) using any cryptographic algorithm, either symmetric ones, such as DES [20] or asymmetric ones such as RSA [7]; (6) exportable – the chance to receive proper licensing for a technology is larger if it provides only message authentication code (MAC) functions and does not require full-fledged encryption and decryption of large messages; (7) extendable – it should support the sharing of secret keys between multiple users and should allow additional fields to be carried in the messages, which would thus be authenticated as part of the protocol. 15.1.2 Canonical authentication protocol A number of protocols meeting the above requirements have been developed [13, 14]. Some of these protocols are summarized in Figure 15.7. Given that the focus is on authentication protocols using nonces, the most general canonical form for all such protocols is depicted in Figure 15.7 (P1). Here, A sends some nonce N1toB.B authenticates itself by sending back a function u( ) of several parameters, including at least its secret K1 and the challenge N1 it received from A. It also sends a challenge N2toA. A finally completes the protocol by authenticating itself with a function v( ) of several parameters including at least its secret JWBK083-15 JWBK083-Glisic February 23, 2006 5:29 Char Count= 0 596 SECURITY P4 E(q(N2, )) N1 N2, E(f(N1,N2,D, ))# E(f(N1,N2,D, )) A B N1 N2, E(f(N1,N2,D, ))# E(f(N1,N2,D, )) A B P5 E(g(N1,N2,D, )) N1 N2,E(p(N1, )) A B P2 E(q(N2, )) N1 A B N1 A B N2, u(K1,N1,…) v(K2,N2, ) P1 N2, E(p(N1,D, )) P3 E(q(N2, )) Figure 15.7 P1, resistance to replay attacks through use of nonces; P2, use of symmet- ric cryptography; P3, resistance to parallel session attacks; P4, resistance to selected-text and offset attacks; P5, minimal number of encryptions. K2 and the challenge N2 from B. As indicated in the earlier section on attacks, in order for this protocol to resist oracle attacks, the functions u( ) and v( ) must be different from one another, meaning that a cryptographic message from flow (2) can never be used to derive the necessary message for flow (3). The protocols must work with either symmetric or asymmetric cryptographic systems. With the latter, the secrets K 1 and K2 would be the private keys of B and A, respectively. However, with symmetric systems, K 1 and K2 would be shared secret keys. In fact, in many typical scenarios, they would be the same shared secret key. In the sequel we will continue under that assumption because it opens the door to attacks that would not be possible otherwise, yet it has advantages of efficiency and ease of migration of existing systems over solutions which use different keys for A and B. Any protocol that resists interleaving attacks using equal symmetric keys is also safe with asymmetric ones while the opposite is not true. Under the assumption of symmetric cryptography with a single shared secret key K protocol P1 becomesas depicted in Figure15.7 (P2), where the functions u(K1, decryption) are represented by operations E( ) under the same key K of two different functions p() and q( ) of the remaining parameters. As indicated earlier in the section on attacks, the prevention of parallel session attacks suggests that function p( ) must be asymmetric, i.e. direction-dependent. In other words, the arguments to p( ) must be different depending on whether A or B starts the communication session. This is depicted in Figure 15.7 (P3) by the addition of a parameter D in p( ), which stands for anything indicating or tied to the direction of the flow (e.g. the name or address of one of the parties). As shown in Figure 15.7 (P3), the complete protocol P3 requires three messages. In any networking environment, these messages need not travel in packets of their own. In JWBK083-15 JWBK083-Glisic February 23, 2006 5:29 Char Count= 0 AUTHENTICATION 597 practice, they can and typically would be piggy-backed onto other network packets, such as, for instance, connection requests and confirmations at whatever layer entities are being authenticated (e.g. link, network, transport, application, etc.). Within packets at any such layer, the authentication fields should take as little space as possible. As it stands presently, the canonical protocol requires a nonce to be carried on the first flow, a nonce and a cryptographic expression on the second one, and a cryptographic expression on the third one. The cleartext of the directional parameter, e.g. party name or address, is implicitly known or already present in the enclosing packet headers. The required size of nonces is given by the amount of security desired: the larger they are, the lower the probability will be that a given nonce gets reused. The size of the cryptographic expressions depends on the encryption algorithm used and on the amount of information being encrypted. As an example, if the DES is used, the smallest cryptographic expression will be 64 b (key 56 b) long. Since the security of the whole authentication protocol rests on the un- forgeability of the cryptographic expressions, if expressions of 64 b are used, the statistical security, ss, of the expressions is ss = 1/p(expression) = 2 64 , the inverse of the probability that an intruder can successfully guess a cryptographic expression. For many environments, such a degree of security is already quite satisfactory, although longer cryptographic ex- pressions are already being used. Triple DEA (ANSI X9.17, DEA 1999) uses three keys and three executions of DEA with effective key length 112 and 168 b. Advanced encryption standard (AES, 1997) uses blocks of length 128 b and key lengths 128, 192 and 256 b. If 64 b nonces are used, p( ) and q( ) may be restricted to 64 b functions of their parameters without compromising the degree of security. We further make this simplifying assumption. Restricting p( ) and q( ) to 64 b functions to limit message size has its own implica- tions. Many simple and attractive 64 b functions of only N1 and D (e.g. XOR, rotations, conditional permutations, etc.) could be subjected to selected-plaintext and offset attacks by an intruder. By including inside function p( ) an additional internal encrypted function of the same parameters N1 and D, one can separate these parameters cryptographically and thus bar the way to offset attacks. By including N2 inside function p(), one bars the way to a potential intruder using B as an oracle to get some selected plaintext enciphered in the second flow because the cleartext of that flow then depends on nonce N2 which is not under the control of the intruder initiating a protocol run. These further conditions on p( ) are represented in Figure 15.7 (P4), where p( ) would thus be a 64 b function (noted #) of two operands, which themselves include functions f ( ) and g()ofN1, N2 and D. The different fields in the message should be cryptographically separated, so that the attacker should not be able to control one field through another field. This separation should be ensured by an appropriate selection of the functions f ( ) and g( ). We will later give exact conditions on f ( ) and g( ) to prevent interleaving attacks, and give specific examples for these functions. Any peer authentication protocol requires at least two cryptographic expressions. In Figure 15.7 (P5) a third cryptographic operation is used to protect against offset attacks. To keep the protocol simple, by putting additional conditions on q(), we can return to a protocol requiring only two cryptographic block operations. This can be achieved by imposing that the functions g( ) and q( ) actually be the same, as represented in Figure 15.7 (P5). Indeed, in this case, the innermost cryptographic expression required to produce or verify the second flow is the same as the cryptographic expression of the third flow, and can thus be computed only once and saved to minimize computation. JWBK083-15 JWBK083-Glisic February 23, 2006 5:29 Char Count= 0 598 SECURITY ( Ca C= Ciphertext C Plaintext M= 1 e − (mod ) e Mn (mod ) d Key generation (p,q prime) Calculate (n)=(p-1)(q-1) C= Ciphertext C Plaintext M= 1 e − (mod ) e Mn (mod ) d Cn d Decription phertext Ci Plaintext M<n Encription Private key KR=[d,n] Public key KU=[e,n] Calculate d (d= mod φ (n)) Select integer e )=1, 1< e< φ (n)),e(n) φ ((gcd φ Calculate n=pq Select p,q (a) ( 23 mod C φ (n)=(p-1)(q-1)=160 e=7 d=23 (de mod 160=1) Ciphertext C = 11 23 mod187 = 88 = 88 7 mod187 = 11 p=17 q=11 n=pq=187 KR=[23,187] C M Plain text M=88 KU=[7,187] (b) 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 encryp- tion 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). JWBK083-15 JWBK083-Glisic February 23, 2006 5:29 Char Count= 0 SECURITY ARCHITECTURE 599 15.2 SECURITY ARCHITECTURE Cryptography provides only two fundamental services, namely, confidentiality and authen- tication. All communications securityservices are concerned with the identityof 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]: r Confidentiality – only the user (or set of users) in possession of the secret key can read the message; r 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 corre- sponding 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,whileschemessuch 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 JWBK083-15 JWBK083-Glisic February 23, 2006 5:29 Char Count= 0 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, where it takes the values of g f ◦ g 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. JWBK083-15 JWBK083-Glisic February 23, 2006 5:29 Char Count= 0 SECURITY ARCHITECTURE 601 Confidentiality channels Keys ConfChannels : User →User ∀ x, y : User r (x, y) ∈ ConfChannels ⇔ {∃k: Conf \ Secret; z: User r (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 r (x, y) ∈ AuthChannels⇔ {∃k : Auth \ Public; z : User r (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 r {x, y}} ∀ x, y : User r (x, y) ∈ SymmChannels ⇔ {(∃k : Shared r (y, k) ∈ keys(x) ∧ [x, dual(k)] ∈ keys(y)} JWBK083-15 JWBK083-Glisic February 23, 2006 5:29 Char Count= 0 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?) JWBK083-15 JWBK083-Glisic February 23, 2006 5:29 Char Count= 0 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 trans- mission 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. JWBK083-15 JWBK083-Glisic February 23, 2006 5:29 Char Count= 0 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. There- fore, 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 mainte- nance. 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 distin- guished 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 man- ually 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,calledits(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 pseu- dorandom process involving random seeds, whichcannot 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 interac- tive 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 verifi- cation 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 certi- fication 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. [...]... sensor networks routing protocol and possible countermeasures are discussed in References [86 , 87 ] REFERENCES [1] OSI Directory – Part 8: Authentication Framework ISO 9594 -8 ISO: Geneva, 1 988 [2] J.J Jueneman, S.M Matyas and C.H Meyer, Message authentication, IEEE Commun Mag., 1 985 , pp 29–40 [3] C.H Meyer and S.M Matyas, Cryptography: a New Dimension in Computer Data Security Wiley: New York, 1 982 [4]... Society Press, 1997, pp 85 –92 [81 ] R Hauser, T Przygienda and G Tsudik, Lowering security overhead in link state routing Comput Networks, vol 31, 1999, pp 88 5 89 4 [82 ] M.K Reiter, Distributing trust with the Rampart toolkit, Commun ACM, vol 39, 1996, pp 71–74 [83 ] M.K Reiter, M.K Franklin, J.B Lacy and R.N Wright The key management service, J Comput Security, vol 4, 1996, pp 267–297 [84 ] L Gong, Increasing... Heinzelman and H Balabishnan, Negotiation-based protocols for disseminating information in wireless sensor networks, Wireless Networks, vol 8, nos 2–3, 2002, pp 169– 185 16 Active Networks 16.1 INTRODUCTION The basic goals of active networking (AN) are to create networking technologies that, in contrast to current networks, are easy to evolve and which allow application specific customization To achieve... authentication in large networks of computers, CACM, vol 21, no 12, 19 78, pp 993–9 98 [6] D Otway and O Rees, Efficient and timely mutual authentication, ACM OSR, vol 21, no 1, 1 987 , pp 8 10 [7] R.L Rivest, A Shamir and L Adlcman, A method for obtaining digital signatures and public-key crypto-systems, CACM, vol 21, no 2, 19 78, pp 120–126; CACM, vol 26, no 1, 1 983 , pp 96–99 [8] R Rivest, The MD4 message... and M.D Schroeder, Using encryption for authentication in large networks of computers, Commun ACM, vol 21, 19 78, pp 993–999 [ 38] E Okamoto, Proposal for identity-based key distribution systems, Electron Lett., vol 22, 1 986 , pp 1 283 –1 284 [39] D Otway and O Rees, Efficient and timely mutual authentication Opns Syst Rev., vol 21, 1 987 , pp 8 10 [40] A Mehrotra and L.S Golding, Mobility and security management... vol 8, no 1, 1990, pp 18 36 [24] CCITT, The Directory, Part 8: Authentication Framework, Recommendation X.509 ISO: Geneva, 1 989 [25] D.W Davies and W.L Price, Security in Computer Networks Wiley: New York, 1 989 [26] L Gong, R Needham and R Yahalom, Reasoning about belief in cryptographic protocols, in Proc 1990 IEEE Computer Soc Symp Security Privacy IEEE Computer Society Press, 1990, pp 234–2 48 [27]... would not be needed Advanced Wireless Networks: 4G Technologies C 2006 John Wiley & Sons, Ltd Savo G Glisic 630 ACTIVE NETWORKS On the network level the previous concepts resulted in middleboxes [7] Domain-specific ‘middleboxes’ [7] are appearing such as firewalls, network address translators (NATs) and intrusion detection systems (IDSs) Examples of such middleboxes include NATs [8 10], NAT with protocol... 2003, work in progress [ 68] IEEE Std 80 2.1X-2001, IEEE Standard for Local and Metropolitan Area Networks – Port-Based Network Access Control, July 2001 [69] L Zhou and Z Haas, Securing ad hoc Networks, IEEE Networks, November/ December 1999, pp 24–30 [70] E Ayanoglu, C.-L I, R D Gitlin and J E Mazo, Diversity coding for transparent self-healing and fault-tolerant communication networks IEEE Trans Commun.,... and R.M Needham, A logic of authentication, in Proc 12th ACM SOSP, ACM OSR, vol 23, no 5, 1 989 , pp 1–13 [16] D.E Denning and G.M Sacco, Timestamps in key distribution systems, CACM, vol 24, no 8, 1 981 , pp 533–536 [17] L Gong, Using one-way functions for authentication, ACM CCR, vol 19, no 5, 1 989 , pp 8 11 [ 18] C I’Anson and C Mitchell, Security defects in CCITT Recommendation X.509 – The Directory... 1993, pp 657–662 [85 ] S Capkun, L Butty´ n and J.-P Hubaux, Self-organized public-key management for a mobile ad hoc networks, IEEE Trans Mobile Comput., vol 2, no 1, 2003, pp 52–64 [86 ] C Karlof and D Wagner, Secure routing in wireless sensor networks: attacks and countermeasures, Proc First IEEE Int Workshop on Sensor Network Protocols and Applications, 11 May 2003, pp 113–127 [87 ] J Kulik, W Heinzelman . (a) ( 23 mod C φ (n)=(p-1)(q-1)=160 e=7 d=23 (de mod 160=1) Ciphertext C = 11 23 mod 187 = 88 = 88 7 mod 187 = 11 p=17 q=11 n=pq= 187 KR=[23, 187 ] C M Plain text M =88 KU=[7, 187 ] (b) Figure 15 .8 (a) Operation of a public key encryption system;. executions of DEA with effective key length 112 and 1 68 b. Advanced encryption standard (AES, 1997) uses blocks of length 1 28 b and key lengths 1 28, 192 and 256 b. If 64 b nonces are used, p( ) and. and decrypts using a private key as illustrated in Figure 15 .8( a); a numerical example is given in Figure 15 .8( b). JWBK 083 -15 JWBK 083 -Glisic February 23, 2006 5:29 Char Count= 0 SECURITY ARCHITECTURE