Advanced Wireless Networks - 4G Technologies
.pdfSECURITY IN AD HOC NETWORKS |
619 |
|
|
|
(m)k |
|
|
|
|
|
C |
|
|
|
PS(m,s1) |
|
PS(m,s3 ) |
||
1 |
|
2 |
|
3 |
|
Server |
S1 |
Server |
S2 |
Server |
S3 |
|
|
|
|||
|
|
|
m |
|
|
Figure 15.18 Threshold signature with three servers.
A compromised server could generate an incorrect partial signature, and use of this partial signature would yield an invalid signature. Fortunately, a combiner can verify the validity of a computed signature using the service public key. In case verification fails, the combiner tries another set of t + 1 partial signatures. This process continues until the combiner constructs the correct signature from t + 1 correct partial signatures. More efficient robust combining schemes are proposed [73, 74]. These schemes exploit the inherent redundancies in the partial signatures (note that any t + 1 correct partial signatures contain all the information of the final signature) and use error correction codes to mask incorrect partial signatures. In Gennaro et al. [73], a robust threshold DSS (digital signature standard) scheme is proposed. The process of computing a signature from partial signatures is essentially an interpolation. The authors uses the Berlekamp and Welch decoder, so that the interpolation still yields a correct signature despite a small portion (fewer than one-quarter) of partial signatures being missing or incorrect.
Even if the compromised servers are detected and excluded from the service, the adversary could still gather more than t shares of the private key from compromised servers over time. This would allow the adversary to generate any valid certificates signed by the private key.
Proactive schemes [75, 76] are proposed as a countermeasure to mobile adversaries. A proactive threshold cryptography scheme uses share refreshing, which enables servers to compute new shares from old ones in collaboration without disclosing the service private key to any server. The new shares constitute a new (n, t + 1) sharing of the service private key. After refreshing, servers remove the old shares and use the new ones to generate partial signatures. Because the new shares are independent of the old ones, the adversary cannot combine old shares with new shares to recover the private key of the service. Thus, the adversary is challenged to compromise t + 1 servers between periodic refreshing.
Share refreshing must tolerate missing newly generated shares (called subshares) and erroneous subshares from compromised servers. A compromised server may not send any subshares. However, as long as correct servers agree on the set of subshares to use, they can generate new shares using only subshares generated from t + 1 servers. For servers to detect incorrect subshares, verifiable secret sharing schemes are used, for example, those in Pedersen [77]. A verifiable secret sharing scheme generates extra public information for
620 SECURITY
each (sub)share using a one-way function. The public information can testify the correctness of the corresponding (sub)shares without disclosing the (sub)shares.
A variation of share refreshing also allows the key management service to change its configuration from (n, t + 1) to (n , t + 1). This way, the key management service can adapt itself, on the fly, to changes in the network. If a compromised server is detected, the service should exclude the compromised server and refresh the exposed share. If a server is no longer available or if a new server is added, the service should change its configuration accordingly. For example, a key management service may start with the (7, 3) configuration. If, after some time, one server is detected to be compromised and another server is no longer available, then the service could change its setting to the (5, 2) configuration. If two new servers are added later, the service could change its configuration back to (7, 3) with the new set of servers.
15.7.1 Self-organized key management
In this section we discuss a self-organizing public-key management system that allows users to create, store, distribute and revoke their public keys without the help of any trusted
Kv |
1 |
2 |
|
|
|
|
x2 |
x4 |
|
Power range |
|
G |
|
u |
|
|
|
(v,Kv)PrKu |
x1 |
x3 |
Ku |
send (Gu Gnu) and request (Gxi Gnxi) |
|
|
||
|
3a |
3b |
Gnu |
G |
Ku |
Ku |
|
Updated local repository of u(Gu)
Figure 15.19 The creation of nodes’ updated and nonupdated repositories (where
GuN = Gnu ).
SECURITY IN AD HOC NETWORKS |
621 |
authority or fixed server [85]. In the system model, the public keys and the certificates of the system are represented as a directed graph G(V, E), where V and E stand for the set of vertices and the set of edges, respectively. This graph will be referred to as the certificate graph. The vertices of the certificate graph represent public keys and the edges represent certificates. More precisely, there is a directed edge from vertex Ku to vertex Kw if there is a certficate signed with the private key of u that binds Kw to an identity. A certificate chain from a public key Ku to another public key Kv is represented by a directed path from vertex Ku to vertex Kv in G. Thus, the existence of a certificate chain from Ku to Kv means that vertex Kv is reachable from vertex Ku in G (denoted below Ku→G Kv ). In the following, the certificate graph G designates the graph comprising only the valid (not expired) certificates of the whole network. In the model, the updated and the nonupdated certificate repositories of user u are represented by the certificate graphs Gu and Gnu, respectively. Therefore, for any u, Gu is a subgraph of G, but Gnu is not necessarily a subgraph of G, as it may also contain some implicitly revoked certificates.
As shown in Figure 15.19, the initial phase of the scheme is executed in four steps: the creation of public/private key pairs, the issuing of certificates, the certificate exchange, and the creation of nodes’ updated certificate repositories.
In step 0, the user creates her own public/private key pair.
In step 1, she issues public-key certificates based on her knowledge about other users’ public keys. The issuing of public-key certificates also continues when the system is fully operational (i.e. when the updated and nonupdated repositories are already constructed) as users get more information about other users’ public keys. During this process, the certificate graph G is created. The speed of the creation of a usable (i.e. sufficiently connected) certificate graph heavily depends on the motivation of the users to issue certificates.
In step 2, the node performs the certificate exchange. During this step, the node collects certificates and thus creates its nonupdated certificate repository. Along with the creation of new certificates, the certificate exchange also continues even when the system is fully operational. This means that nodes’ nonupdated repositories will be continuously upgraded with new certificates. The nodes’ mobility determines the speed at which certificates are accumulated by the nodes themselves.
In step 3, the node constructs its updated certificate repository. The node can perform this operation in two ways, either by communicating with its certificate graph neighbors (Step 3a), or by applying the repository construction algorithm on the nonupdated certificate repository (Step 3b). When the node constructed its updated certificate repository, it is ready to perform authentication.
The authentication is performed in such a way that, when a user u wants to verify the authenticity of the public key Kv of another user v, u tries to find a directed path from Ku to Kv in Gu Gv. The certificates on this path are then used by u to authenticate Kv. An example of a certificate graph with updated local repositories of the users is shown in Figure 15.20. If there is no path from Ku to Kv in Gu Gv, u tries to find a path from Ku
622 SECURITY
K v
K u
updated local repository of u updated local repository of v
paths of certificates between u and v in their merged updated local repositories
Figure 15.20 A certificate graph and paths of certificates between users u and v in their merged updated local repositories.
to Kv in Gu Gnv. If such a path is found, u updates the expired certificates, checks their correctness and performs authentication. If there is no path from Ku to Kv in Gu Gnv, u fails to authenticate Kv. A detailed description of each operation can be found in Capkun et al. [85].
15.8 SECURITY IN SENSOR NETWORKS
Owing to its inherent simplicity, sensor network routing protocols are sometimes even more susceptible to attacks against general ad-hoc routing protocols. Most network layer attacks against sensor networks fall into one of the following categories: spoofed, altered or replayed routing information, selective forwarding, sinkhole attacks, sybil attacks, wormholes, HELLO flood attacks or acknowledgement spoofing. Spoofing, altering or replaying routing information may be used by adversaries to create routing loops, attract or repel network traffic, extend or shorten source routes, generate false error messages, partition the network, increase end-to-end latency, etc.
Selective forwarding attack refers to the case where malicious nodes refuse to forward certain messages and simply drop them, ensuring that they are not propagated any further. Selective forwarding attacks are typically most effective when the attacker is explicitly included on the path of a data flow. In the next two sections, we discuss sinkhole attacks and the Sybil attack, two mechanisms by which an adversary can efficiently include herself on the path of the targeted data flow.
624 SECURITY
HELLO floods can be thought of as one-way, broadcast wormholes. Many protocols require nodes to broadcast HELLO packets to announce themselves to their neighbors, and a node receiving such a packet may assume that it is within (normal) radio range of the sender. This assumption may be false: a laptop-class attacker broadcasting routing or other information with large enough transmission power could convince every node in the network that the adversary is its neighbor.
An adversary does not necessarily need to be able to construct legitimate traffic in order to use the HELLO flood attack. It can simply re-broadcast overheard packets with enough power to be received by every node in the network.
Acknowledgement spoofing refers to the case where an adversary can spoof link layer acknowledgments for ‘overheard’ packets addressed to neighboring nodes. Goals include convincing the sender that a weak link is strong or that a dead or disabled node is alive. For example, a routing protocol may select the next hop in a path using link reliability. Artificially reinforcing a weak or dead link is a subtle way of manipulating such a scheme. Since packets sent along weak or dead links are lost, an adversary can effectively mount a selective forwarding attack using acknowledgement spoofing by encouraging the target node to transmit packets on those links.
Attacks on specific 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, 1988.
[2]J.J. Jueneman, S.M. Matyas and C.H. Meyer, Message authentication, IEEE Commun. Mag., 1985, pp. 29–40.
[3]C.H. Meyer and S.M. Matyas, Cryptography: a New Dimension in Computer Data Security. Wiley: New York, 1982.
[4]R. Morris and K. Thompson, Password security: a case history, CACM, vol. 22, no. 11, 1979, pp. 594–597.
[5]R.M. Needham and M.D. Schroeder, Using encryption for authentication in large networks of computers, CACM, vol. 21, no. 12, 1978, pp. 993–998.
[6]D. Otway and O. Rees, Efficient and timely mutual authentication, ACM OSR, vol. 21, no. 1, 1987, 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, 1978, pp. 120–126; CACM, vol. 26, no. 1, 1983, pp. 96–99.
[8]R. Rivest, The MD4 message digest algorithm, Internet RFC, vol. 1320, April 1992.
[9]R. Rivest, The MD5 message digest algorithm, Internet RFS, vol. 1321, April 1992.
[10]Banking – key Management (Wholesale). ISO 8732. ISO: Geneva, 1988.
[11]R.K. Bauer, T.A. Berson and R.J. Freiertag, A key distribution protocol using event markers, ACM TOCS, vol. 1, no. 3, 1983, pp. 249–255.
[12]S.M. Bellovin and M. Merritt, Limitations of the Kerberos authentication system, ACM CCR, vol. 20, no. 5, 1990, pp. 119–132.
[13]R. Bird, I. Gopal, A. Herzberg, P.A. Janson, S. Kutten, R. Mowa and M. Yung, Systematic design of a family of attack-resistant authentication protocols, IEEE J. Select. Area Commun., vol. 11. no. 5, 1993, pp. 679–692.
REFERENCES 625
[14]R. Bird, I. Gopal, A. Herzberg, P.A. Janson, S. Kutten, R. Mowa and M. Yung, Systematic design of two-party authentication protocols, in Proc. Crypto 91,Santa Barbara, CA, Aug. 1991, pp. 44–61, available as Advances in Cryptology, Lecture Notes in Computer Science 576, J. Feigenbaum (ed.). Springer: New York, 1991.
[15]M. Burrows, M. Abadi and R.M. Needham, A logic of authentication, in Proc. 12th ACM SOSP, ACM OSR, vol. 23, no. 5, 1989, pp. 1–13.
[16]D.E. Denning and G.M. Sacco, Timestamps in key distribution systems, CACM, vol. 24, no. 8, 1981, pp. 533–536.
[17]L. Gong, Using one-way functions for authentication, ACM CCR, vol. 19, no. 5, 1989,
pp.8–11.
[18]C. I’Anson and C. Mitchell, Security defects in CCITT Recommendation X.509 – The Directory Authentication Framework, ACM CR, vol. 20, no. 2, 1990, pp. 30–34.
[19]Entity Authentication Using Symmetric Techniques. ISO-IEC JTC1.27.02.2 (20.03.1.2). ISO: Geneva, June 1990.
[20]Data Encryption Standard, FIPS 46, NBS, January 1977.
[21]C. Boyd, Security architectures using formal methods, IEEE J. Select. Areas Commun., vol. 11, no. 5, June 1993, pp. 694–701.
[22]C.A. Boyd, Hidden assumptions in cryptographic protocols, Proc. IEE, Part E, vol. 137, 1990, pp. 433–436.
[23]M. Burrows, M. Abadi and R. Needham, A logic of authentication, ACM Trans. Comput. Syst., vol. 8, no. 1, 1990, pp. 18–36.
[24]CCITT, The Directory, Part 8: Authentication Framework, Recommendation X.509. ISO: Geneva, 1989.
[25]D.W. Davies and W.L. Price, Security in Computer Networks. Wiley: New York, 1989.
[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–248.
[27]Information Processing Systems – Open Systems Interconnection Reference Model, Security Architecture, ISO 7498-2. ISO: Geneva, 1988.
[28]R. Kailar and V.D. Gligor, On belief evolution in authentication protocols, in Proc. Computer Security Foundations Workshop IV. IEEE Press: New York, 1991, pp. 103– 116.
[29]C. Meadows, A system for the specification and analysis of key management protocols, in Proc. 1991 IEEE Computer Soc. Symp. Security Privacy. IEEE Computer Society Press: New York, 1991, pp. 182–195.
[30]R.M. Needham and M.D. Schroeder, Using encryption for authentication in large networks of computers, Commun. ACM, vol. 21, no. 12, 1978, pp. 993–999.
[31]R. Rivest, A Shamir and L. Adelman, A method for obtaining digital signatures and public key cryptosystems, Commun. ACM, vol. 21, no. 2, 1978, pp. 120–126.
[32]J.M. Spivey, The Z Notation. Prentice-Hall: Englewood Cliffs, NJ, 1989.
[33]W. Fumy and P. Landrock, Principles of key management, IEEE J. Select. Areas Commun., vol. 11, no. 5, 1993, pp. 785–793.
[34]D.M. Balenson, Automated distribution of cryptographic keys using the financial institution key management standard. IEEE Commun. Mag., July 1985, pp. 41–46.
[35]W. Diffie and M.E. Hellman, New directions in cryptography, IEEE Trans. Inform. Theory, vol. 22, 1976, pp. 644–654.
[36]S.M. Matyas, Key handling with control vectors, IBM Syst. J., vol. 30, no. 2, 1991,
pp.151–174.
626 SECURITY
[37]R.M. Needham and M.D. Schroeder, Using encryption for authentication in large networks of computers, Commun. ACM, vol. 21, 1978, pp. 993–999.
[38]E. Okamoto, Proposal for identity-based key distribution systems, Electron. Lett., vol. 22, 1986, pp. 1283–1284.
[39]D. Otway and O. Rees, Efficient and timely mutual authentication. Opns. Syst. Rev., vol. 21, 1987, pp. 8–10.
[40]A. Mehrotra and L.S. Golding, Mobility and security management in the GSM system and some proposed future improvements, Proc. IEEE, vol. 86, no. 7, 1998, pp. 1480– 1486.
[41]A. Mehrotra, GSM System Engineering. Artech House: Norwood, MA, 1997.
[42]A. Mehrotra, Cellular Radio Analog and Digital Systems. Artech House: Norwood, MA, 1994, section 7.5.2.4, pp. 305–309.
[43]S.M. Redl, M.K. Weber and M.W. Oliphant, Security parameter, in An Introduction to GSM. Artech House: Norwood, MA, 1995, section 3.8, pp. 44–48.
[44]European Telecommunication Standard Institute/Global System for Mobility, ETSI/GSM specification vol. 2.17, section 3, Jan. 1993.
[45]G. Koien, An Introduction to Access Security in UMTS, IEEE Wireless Commun., February 2004, pp. 8–18.
[46]3G TS 33.120, 3G Security; Security Principles and Objectives.
[47]3G TS 21.133, 3G Security; Security Threats and Requirements.
[48]3G TS 33.102, 3G Security; Security Architecture.
[49]3G TS 33.105, 3G Security; Cryptographic Algorithm Requirements.
[50]3G TS 33.200, 3G Security; Network Domain Security; MAP Application Layer Security.
[51]3G TS 33.210, 3G Security; Network Domain Security; IP Network Layer Security.
[52]3G TS 35.205, 3G Security; Specification of the MILENAGE Algorithm Set: An Example Algorithm Set for the 3GPP Authentication and Key Generation Functions f1, f1*, f2, f3, f4, f5, and f5*; Document 1: General.
[53]3G TS 35.206, 3G Security; Specification of the MILENAGE Algorithm Set: An Example Algorithm Set for the 3GPP Authentication and Key Generation Functions f1, f1*, f2, f3, f4, f5, and f5*; Document 2: Algorithm Specification.
[54]Information Technology – Security Techniques – Entity Authentication - Part 4: Mechanisms Using a Cryptographic Check Function. ISO/IEC 9798-4. ISO: Geneva.
[55]National Institute of Standards and Technology. FIPS-197, Advanced Encryption Standard (AES) (FIPS PUB 197). NIST: Gaithersburg, MD, 26 November 2001.
[56]3G TS 35.201, 3G Security; Specification of the 3GPP Confidentiality and Integrity Algorithms; Document 1: f8 and f9 Specification.
[57]3G TS 35.202, 3G Security; Specification of the 3GPP Confidentiality and Integrity Algorithms; Document 2: KASUMI specification.
[58]3GPP, Document TSGS#14(01)0622, Work Item Description: Support for Subscriber Certificates, SA#14, Tokyo, Japan, Dec. 2001.
[59]S. Murphy and M. J. B. Robshaw, Essential algebraic structure within the AES: in Proc. Crypto2002, LNCS, vol. 2442. Springer: Berlin, 2002, pp. 1–16.
[60]3G TS 33.904, 3GPP, SAGE; Report on the Evaluation of 3GPP Standard Confidentiality and Integrity Algorithms (SAGE v. 2.0).
[61]3G TS 23.234, 3GPP System to Wireless Local Area Network (WLAN) Interworking System Description, Release 6, work in progress.
REFERENCES 627
[62]3G TS 33.234 v050, 3G Security; Wireless Local Area Network (WLAN) Interworking Security, Release 6, work in progress.
[63]L. Blunk et al., Extensible Authentication Protocol (EAP), Internet draft, draft-ietf- eap-rfc2284bis-04.txt, June 2003, work in progress.
[64]G. Koien and T. Haslestad, Security Aspects of’3G-WLAN Interworking, IEEE Commun. Mag., November 2003, pp. 82–88.
[65]ETSI TR 101 957, Broadband Radio Access Networks (BRAN); HIPERLAN Type 2; Requirements and Architectures for Interworking between HIPERLAN/2nd and 3rd Generation Cellular Systems.
[66]IEEE Std 802.11i/D4.0, Draft Amendment to Standard for Telecommunications and Information Exchange Between Systems – LAN/MAN Specific Requirements – Part 11: Wireless Medium Access Control (MAC) and Physical Layer (PHY) specifications: Medium Access Control (MAC) Security Enhancements, May 2003, work in progress.
[67]J. Arkko and H. Haverinen, EAP AKA Authentication, Internet Draft: draft-arkko- pppext-eap-aka-10.txt, June 2003, work in progress.
[68]IEEE Std 802.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., vol. 41, 1993, pp. 1677–1686.
[71]Y. Desmedt and Y. Frankel, Threshold cryptosystems. In G. Brassard (ed.), Advances in Cryptology – Crypto’89, Proc. 9th Annual International Cryptology Conference, Santa Barbara, CA A, 20–24 August 1989, vol. 435 of Lecture Notes in Computer Science. Springer: Berlin, 1990, pp. 307–315.
[72]Y. Desmedt, Threshold cryptography. Eur. Trans. Telecommun., vol. 5, 1994, pp. 449– 457.
[73]R. Gennaro, S. Jarecki, H. Krawczyk and T. Rabin, Robust threshold DSS signatures. In U. M. Maurer (ed.), Advances in Cryptology – Proc. Eurocrypt’96, International Conference on the Theory and Application of Cryptographic Techniques, Saragossa, 12–16 May 1996, vol. 1233 of Lecture Notes in Computer Science. Springer: Berlin, 1996, pp. 354–371.
[74]R. Gennaro, S. Jarecki, H. Krawczyk and T. Rabin, Robust and efficient sharing of RSA functions. In N. Koblitz (ed.), Advances in Cryptology – Proc. Crypto’96, the 16th Annual International Cryptology Conference, Santa Barbara, CA, 18–22 August 1996, vol. 1109 of Lecture Notes in Computer Science. Springer: Berlin, 1996, pp. 157–172.
[75]A. Herzberg, S. Jarecki, H. Krawczyk and M. Yung, Proactive secret sharing or: How to cope with perpetual leakage. In D. Coppersmith (ed.), Advances in Cryptology – Proc. Crypto’95, the 15th Annual International Cryptology Conference, Santa Barbara, CA USA, 27–31 August 1995, vol. 963 of Lecture Notes in Computer Science. Springer: Berlin, 1995, pp. 457–469.
[76]Y. Frankel, P. Gemmell, P. MacKenzie and M. Yung, Proactive RSA. In B. S. Kaliski Jr. (ed.), Advances in Cryptology – Proc. Crypto’97, the 17th Annual International Cryptology Conference, Santa Barbara, CA, 17–21 August 1997, vol. 1294 of Lecture Notes in Computer Science. Springer: Berlin, 1997, pp. 440–454.