Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Advanced Wireless Networks - 4G Technologies

.pdf
Скачиваний:
47
Добавлен:
17.08.2013
Размер:
21.94 Mб
Скачать

618 SECURITY

If a server is compromised, then the adversary has access to all the secret information stored on the server. A compromised server might be unavailable or exhibit Byzantine behavior (i.e. it can deviate arbitrarily from its protocols). It is also assumed that the adversary lacks the computational power to break the cryptographic schemes employed. The service is correct if robustness and confidentiality are preserved. Robustness assumes that the service is always able to process query and update requests from clients. Every query always returns the last updated public key associated with the requested client, assuming no concurrent updates on this entry. Confidentiality assumes that the private key of the service is never disclosed to an adversary so that an adversary is never able to issue certificates, signed by the service private key, for erroneous bindings.

Threshold cryptography is used to accomplish distribution of trust in the key management service [71, 72]. An (n, t + 1) threshold cryptography scheme allows n parties to share the ability to perform a cryptographic operation (e.g. creating a digital signature), so that any t + 1 parties can perform this operation jointly, whereas it is infeasible for at most t parties to do so, even by collusion.

In this case, the n servers of the key management service share the ability to sign certificates. For the service to tolerate t compromised servers, an (n, t + 1) threshold cryptography scheme is employed and the private key k of the service is divided into n shares (s1, s2, . . . , sn ), by assigning one share to each server. In this context (s1, s2, . . . , sn ) is referred to as an (n, t + 1) sharing of k. The service is configured as illustrated in Figure 15.17.

For the service to sign a certificate, each server generates a partial signature for the certificate using its private key share and submits the partial signature to a combiner. With t + 1 correct partial signatures, the combiner is able to compute the signature for the certificate as illustrated in Figure 15.18, where servers generate a signature using a (3, 2) threshold signature scheme. The compromised servers (there are at most t of them) cannot generate correctly signed certificates by themselves, because they can generate at most t partial signatures.

If K /k is the public/private key pair of the service then by using a (3, 2) threshold cryptography scheme in Figure 15.18, each server i gets a share si of the private key k. For a message m, server i can generate a partial signature PS(m, si ) using its share si . Correct servers 1 and 3 both generate partial signatures and forward the signatures to a combiner c. Even though server 2 fails to submit a partial signature, c is able to generate the signature (m)k of m signed by service private key k [71, 72].

Sn

K n/k n

Server 3

 

 

 

k

S2

K 2/k 2

Server 2

 

 

 

 

 

 

S1

K1/k1

Server 1

 

 

 

Figure 15.17 The configuration of a key management service.

SECURITY 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 KuG 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.

SECURITY IN SENSOR NETWORKS

623

Sinkhole attacks typically work by making a compromised node look especially attractive to surrounding nodes with respect to the routing algorithm. For instance, an adversary could spoof or replay an advertisement for an extremely high quality route to a base station.

One motivation for mounting a sinkhole attack is that it makes selective forwarding trivial. By ensuring that all traffic in the targeted area flows through a compromised node, an adversary can selectively suppress or modify packets originating from any node in the area.

Sybil attack refers to the case where a single node presents multiple identities to other nodes in the network. Sybil attacks pose a significant threat to geographic routing protocols. Location-aware routing often requires nodes to exchange coordinate information with their neighbors to efficiently route geographically addressed packets. It is only reasonable to expect a node to accept but a single set of coordinates from each of its neighbors, but by using the Sybil attack an adversary can ‘be in more than one place at once’.

The wormhole attack refers to the case where an adversary tunnels messages received in one part of the network over a low latency link and replays them in a different part. Wormhole attacks most commonly involve two distant malicious nodes colluding to understate their distance from each other by relaying packets along an out-of-bounds channel available only to the attacker. An adversary situated close to a base station may be able to completely disrupt routing by creating a well-placed wormhole. An adversary could convince nodes who would normally be multiple hops from a base station that they are only one or two hops away via the wormhole. This can create a sinkhole: since the adversary on the other side of the wormhole can artificially provide a high-quality route to the base station, potentially all traffic in the surrounding area will be drawn through it if alternate routes are significantly less attractive. This will most likely always be the case when the endpoint of the wormhole is relatively far from a base station. Figure 15.21 shows an example of a wormhole being used to create a sinkhole. Wormholes can also be used simply to convince two distant nodes that they are neighbors by relaying packets between the two of them. Wormhole attacks would probably be used in combination with selective forwarding or eavesdropping. Detection is potentially difficult when used in conjunction with the Sybil attack.

?

?

Adversary

?

Base station

Sensor node

 

Low-power radio link

 

Low latency,

 

high bandwidth link

Figure 15.21 A laptop-class adversary using a wormhole to create a sinkhole in TinyOS beaconing.

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.