Patent Grant
7373499
The present invention relates to cryptography and, more particularly, to techniques for providing delegation of cryptographic servers for use by cryptographic devices which are resilient to capture.
A computing device that performs private key operations, such as signatures and/or decryptions, risks exposure of its private key if captured. While encrypting the private key with a password is common, this provides only marginal protection, since passwords are well-known to be susceptible to offline dictionary attacks. Much recent research has explored techniques for providing better password protections for the private keys on devices that may be captured.
One technique provides for encrypting the private key under a password in a way that prevents the attacker from verifying a successful password guess. This technique is referred to as cryptographic camouflage, see, e.g., D. N. Hoover et al., “Software Smart Cards via Cryptographic Camouflage,” 1999 IEEE Symposium on Security and Privacy, pp. 208-215, May 1999, the disclosure of which is incorporated by reference herein.
Another technique provides for forcing the attacker to verify his password guesses at an online server before the use of the private key is enabled, thereby turning an offline attack into an online one that can be detected and stopped. This technique is described in the commonly-assigned U.S. patent application identified as Ser. No. 10/072,331 filed on Feb. 7, 2002, and entitled “Methods and Apparatus for Providing Networked Cryptographic Devices Resilient to Capture,” the disclosure of which is incorporated by reference herein. In accordance with this server-based approach, the server may be untrusted (e.g., its compromise does not reduce the security of the device's private key unless the device is also captured) and need not have a prior relationship with the device.
The server-based approach offers certain advantages over the cryptographic camouflage approach, e.g., the server-based approach is compatible with existing infrastructure, whereas cryptographic camouflage requires that public keys be hidden from potential attackers.
However, the server-based approach requires that the device interact with a designated server in order to perform a (and typically each) private key operation. This interaction may become a bottleneck if the designated server is geographically distant and the rate of private key operations is significant.
Thus, there exists a need for techniques which overcome drawbacks associated with the approaches described above and which thereby make networked cryptographic devices more resilient to capture while minimizing or eliminating any potential bottleneck situations.
The present invention provides improved cryptographic techniques by which a device that performs private key operations (e.g., signatures and/or decryptions), and whose private key operations are protected by a password, is immunized against offline dictionary attacks in case of capture by forcing the device to confirm a password guess with a designated entity or party in order to perform a private key operation, and by which the initiating device may dynamically delegate the password-checking function (i.e., confirmation of the password guess) from the originally designated entity or party to another designated entity or party.
One application of this technique is to allow a user who is traveling to a foreign country to temporarily delegate to a server local to that country the ability to confirm password guesses and aid the user's device in performing private key operations. Even more generally, rather than a server, this function may be temporarily delegated to a token in the user's possession. Another application is related to proactive security for the device's private key, wherein proactive updates are made at the device and servers to eliminate any threat of offline password guessing attacks due to previously compromised servers.
For example, in one aspect of the invention, a method for use in a device associated with a first party (e.g., client device), performed in association with a device associated with a second party (e.g., an originally designated server), for delegating authorization to perform a function (e.g., password-checking operation) from the second party device to a device associated with a third party (e.g., a local server or token in the possession of the client), may comprise the following steps. In the first party device, a request for the partial assistance of the second party device in delegating authorization of the function to the third party device is generated. The request is transmitted from the first party device to the second party device. Results are received in the first party device generated by the second party device based on the partial assistance provided by the second party device. Then, at least a portion of the received results are used in the first party device to delegate authorization to the third party device.
Data stored on the first party device may comprise a piece of secret information associated therewith (e.g., password) which is included in the request. In such case, the partial assistance may be provided by the second party device when a verification is made by the second party device, based on the piece of secret information, that the first party sent the request.
The delegation operation preferably employs three-way function sharing whereby at least a portion of data stored on the first party device was constructed by generating a first share, a second share and a third share of a value (e.g., a private key) associated with the first party device. The first share may be constructed so that the share can be generated from a piece of secret information associated with the first party (e.g., a password) and information stored on the first party device.
Further, data stored on the first party device may comprise an encryption of at least a portion of the third share of the value in accordance with a public key associated with the second party device so as to generate cryptographic information (e.g., a ticket). The request generated in the first party device then includes the cryptographic information or ticket. Then, the share in the request is split at the second party device such that a portion of a third party share is generated at the second party device.
Lastly, at least one value (e.g., another ticket) is generated in the first party device, using at least the portion of the third party share generated by the second party device, for subsequent use between the first party device and the third party device in performing the function.
The third party device may then assist the first party device in performing one or more private key operations. It is to be understood that while private key operations that may be performed in accordance with the invention may comprise many types of decryption operations, the ElGamal decryption protocol is one preferred protocol. Similarly, while private key operations that may be performed in accordance with the invention may comprise many types of signature operations, the RSA (Rivest-Shamir-Adleman) signature protocol is one preferred protocol.
These and other objects, features and advantages of the present invention will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings.
The following description will illustrate the invention in the context of a client/server environment, i.e., a client device may temporarily delegate a password-checking function from its originally designated server to another server that is closer to it. However, it should be understood that the invention is not limited to such an environment. Rather, the invention is instead more generally applicable to any environment where a user wishes to temporarily delegate a password-checking function from one entity or party to any other entity or party. For instance, the device may temporarily delegate the function to a token in his possession.
By way of example and without limitation, it is to be understood that a “device” may include any type of computing system, e.g., a personal computer (including desktops and laptops), a personal digital assistant (PDA), a smartcard, a cellular phone, etc. Likewise, by way of example and without limitation, a “server” may also be any type of computing system. However, it is to be understood that the protocols of the invention may be implemented between any two parties or entities. Further, it is to be understood that the term “token” is intended to generally refer to any processing entity that can act like a server such as, by way of example only, a smartcard or a software program on the user's laptop.
Thus, the following detailed description of the invention will provide an illustrative explanation of techniques to alleviate the bottleneck situation described above, and other drawbacks associated with existing approaches, by permitting a user device to temporarily delegate the password-checking function from its originally designated server to another server that is closer to it. For example, as mentioned above, a traveler in a foreign country may temporarily delegate the password-checking function for her laptop computer to a server in the country she is visiting. By doing so, her device's subsequent private key operations will require interaction only with this local server, presumably incurring far less latency than if the device were interacting with the original server. Also, as mentioned above, the user may temporarily delegate to a hardware token in her possession, so that the device may produce signatures or decryptions in offline mode without network access at all.
Delegating the password-checking function from one server to another has security implications. The techniques that serve as a starting point here, i.e., those described in the above-referenced, commonly-assigned U.S. patent application identified as Ser. No. 10/072,331 filed on Feb. 7, 2002, and entitled “Methods and Apparatus for Providing Networked Cryptographic Devices Resilient to Capture,” have the useful property that the designated server, in isolation, gains no information that would enable it to forge signatures or decrypt ciphertexts on the device's behalf. However, if both it and the device were captured, then the attacker could mount an offline dictionary attack against the password, and then forge signatures or decrypt ciphertexts for the device if he succeeds.
In the case of delegation, this vulnerability should not extend to any server ever delegated by the device. Rather, a high-level security goal is to ensure that an individual server authorized for password-checking by delegation, and whose authority is then revoked, poses the same security threat as a server to which delegation never occurred in the first place. Specifically, an attacker that captures the device after the device has revoked the authorization of a server (even if the server was previously compromised) must still conduct an online dictionary attack at an authorized server in order to attack the password.
Even with this goal achieved, however, delegation may affect security in at least two ways. First, if the attacker captures the device, then it can mount an online dictionary attack against each currently authorized server, thereby gaining more password guesses than any one server allows. Second, a feature of the protocols of Ser. No. 10/072,331 is that the password-checking server could be permanently disabled for the device even after the device and password were compromised. By doing so, the device can never sign or decrypt again.
In a system supporting delegation, however, if the device and password are compromised, and if there is some authorized server when this happens, then the attacker can delegate from this authorized server to any server permitted by the policy set forth when the device was initialized. Thus, to be sure that the device will never sign or decrypt again, every server in this permissible set must be disabled for the device.
The present invention also provides a technique for realizing proactive security, as described in A. Herzberg, et al., “Proactive Public Key and Signature Systems,” ACM Conf. on Comp. and Comm. Security, pp. 100-110, 1997, the disclosure of which is incorporated by reference herein, in the context of the server-based password-checking scenario. As is known, proactive security encompasses techniques for periodically refreshing the cryptographic secrets held by various components of a system, thereby rendering any cryptographic secrets captured before the refresh useless to the attacker. The delegation protocol of the invention can be used as a subroutine for proactively refreshing a password-checking server, so that if the server's secrets had been exposed, they are useless to the attacker after the refresh. In particular, if the attacker subsequently captured the device, any dictionary attack that the attacker could mount would be online, as opposed to offline.
To illustrate the principles of the invention, security issues associated with delegation are described followed by a description of delegation techniques for RSA signing (as described in R. L. Rivest, “A Method of Obtaining Digital Signatures and Public Key Cryptosystems,” Communications of the ACM, vol. 21(2), pp. 120-126, February 1978, the disclosure of which is incorporated by reference herein) and ElGamal decryption (as described in T. ElGamal, “A Public Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms,” IEEE Transactions on Information Theory, vol. 31, pp. 469-472, 1985, the disclosure of which is incorporated by reference herein). However, the invention is not limited to use in accordance with any particular signing or decrypting protocols.
It is to be understood that supporting delegation for these protocols not only involves providing custom delegation protocols for RSA and ElGamal keys, but also modifying the signing and decryption protocols of Ser. No. 10/072,331 to accommodate delegation. For example, an RSA system of the invention utilizes three-way function sharing, versus the two-way function sharing used in the system of Ser. No. 10/072,331. And, whereas the original systems of Ser. No. 10/072,331 permitted the server to conduct an offline dictionary attack against the user's password (without placing the device's signing key at risk), here a server is prevented from conducting such an attack.
An illustrative system for implementing delegation according to the invention comprises a device referred to as “dvc” and an arbitrary, possibly unknown, number of servers. A server will be denoted by “svr,” possibly with subscripts or other annotations when useful. An example of such an arrangement will be described below in the context of
The device-server protocol allows a device operated by a legitimate user (i.e., one who knows π0) to sign or decrypt a message with respect to the public key of the device, after communicating with one of the servers. This server must be “authorized” to execute this protocol, as defined below. The system is initialized with exactly one server authorized, denoted svr0. Further servers may be authorized, but this authorization cannot be performed by dvc alone. Rather, for dvc to authorize svr, another already-authorized server svr′ must also consent to the authorization of svr, after verifying that the authorization of svr is consistent with policy previously set forth by dvc and is being performed by dvc with the user's password.
In this way, authorization is a protected operation just as signing and decryption are protected. The device can unilaterally revoke the authorization of a server when it no longer intends to use that server. A server can be disabled (for a device) by being instructed to no longer respond to that device or, more precisely, to requests involving its key.
For the purposes of illustrating the invention, the aforementioned policy dictating which servers can be authorized is expressed as a set U of servers with well-known public keys. That is, an authorized server svr will consent to authorize another server svr′ only if svr′ εU. Moreover, it is assumed that svr can reliably determine the unique public key pksvr′ of any svr′ εU. This policy may be expressed more flexibly. For example, one policy may allow any server with a public key certified by a given certification authority to be authorized. For such a policy, the delegation protocols of the invention may be augmented with the appropriate certificates and certificate checks. Given the inventive teachings herein, such augmentation is straightforward and thus well within the skill of the ordinary artisan.
To specify security for a delegation-enabled system, one must consider the possible attackers that attack the system. Each attacker considered is presumed to control the network; i.e., the attacker controls the inputs to the device and every server, and observes the outputs. Moreover, an attacker can permanently compromise certain resources. The possible resources that may be compromised by the attacker are any of the servers, dvc, and π0. Compromising reveals the entire contents of the resource to the attacker. The one restriction on the attacker is that if he compromises dvc, then he does so after dvc initialization and while dvc is in an inactive state (i.e., dvc is not presently executing a protocol with π0 as input) and that π0 is not subsequently input to the device by the user. This decouples the capture of dvc and π0, and is consistent with the motivation that dvc is captured while not in use by the user and, once captured, is unavailable to the user.
Aspects of the system described thus far are formalized as a collection of events:
The time of any event x is given by T(x). Now, the following predicates are defined for any time t:
For any event x, let Active(x)={svr: nominatedT(x)(svr) V authorizedT(x)(svr)}.
It is convenient in specifying security goals to partition attackers into four classes, depending on the resources they compromise and the state of executions when these attackers compromise certain resources. An attacker is assumed to fall into one of these classes independent of the execution, i.e., it does not change its behavior relative to these classes depending on the execution of the system. In particular, the resources an attacker compromises are assumed to be independent of the execution. In this sense, only static attackers (in contrast to adaptive ones) are considered.
Now, security goals of a delegation-enabled system against these attackers are stated as follows (disregarding events that occur with negligible probability):
Active(dvc.comp) after T(dvc.comp), and dict is the dictionary from which the password is drawn (at random). This is goal {goal:online}.
These goals can be more intuitively stated as follows. First, if an attacker does not capture dvc, or does so only when no servers are authorized for dvc (A1), then the attacker gains no ability to forge or decrypt for the device (G1). On the other extreme, if an attacker captures both dvc and π0 (A4), and thus is indistinguishable from the user, it can forge only until all servers are disabled (G4) or indefinitely if it also compromises a server. If the attacker compromises a server along with both dvc and π0, then it can delegate from any authorized server to that compromised server to forge or decrypt indefinitely.
The “middle” cases are if the attacker compromises dvc and not π0. If it compromises dvc and no then-authorized server is ever compromised ({adv:online}), then the attacker can do no better than an online dictionary attack against π0 ({goal:online}). If, on the other hand, when dvc is compromised some authorized server is eventually compromised (A2), then the attacker can do no better than an offline attack against the password (G3).
These properties offer an approach to proactively update dvc to render useless to an attacker any information it gained by compromising a server. That is, suppose that each physical computer running a logical server svr periodically instantiates a new logical server svr′ having a new public and private key. If dvc delegates from svr to svr′, and if then dvc revokes svr, any disclosure of information from svr (e.g., the private key of svr) is then useless for the attacker in its efforts to forge or decrypt for dvc. Rather, if the attacker captures dvc, it must compromise svr′ in order to conduct an offline attack against dvc.
Before explaining the protocols of the invention, we first introduce some definitions and notations associated with a variety of cryptographic tools which will be used in accordance with the protocol explanations.
Security parameters. Let κ be the main cryptographic security parameter; a reasonable value today may be κ=160. We will use λ>κ as a secondary security parameter for public keys. For instance, in an RSA public key scheme, we may set λ=1024 to indicate that we use 1024-bit moduli.
Hash functions. We use h, with an additional subscript as needed, to denote a hash function. Unless otherwise stated, the range of a hash function is {0, 1}κ. It is generally preferred that these hash functions behave like random oracles, see, e.g., M. Bellare et al., “Random Oracles Are Practical: A Paradigm for Designing Efficient Protocols,” ACM Conference on Computer and Communications Security, pp. 62-73, November 1993, the disclosure of which is incorporated by reference herein. However, hash functions with weaker properties may be employed.
Keyed hash functions. A keyed hash function family is a family of hash functions {ƒν} parameterized by a secret value ν. We will typically write ƒν(m) as f(ν, m). We also use a specific type of keyed hash function, a message authentication code (MAC). We denote a MAC family as {maca}. We do not require MACs to behave like random oracles.
Encryption schemes. An encryption scheme ε is a triple (Genc, E, D) of algorithms, the first two being probabilistic, and all running in expected polynomial time. Genc takes as input 1λ and outputs a public key pair (pk, sk), i.e., (pk, sk)←Genc(1λ). E takes a public key pk and a message m as input and outputs an encryption c for m; we denote this c←Epk(m). D takes a ciphertext c and a secret key sk as input and returns either a message m such that c is a valid encryption of m, if such an m exists, and otherwise returns ⊥.
It is preferred that an encryption scheme be secure against adaptive chosen ciphertext attacks, see, e.g., C. Rackoff et al., “Non-interactive Zero-knowledge Proof of Knowledge and Chosen Ciphertext Attack,” Advances in Cryptology—CRYPTO '91, pp. 433-444, 1991, the disclosure of which is incorporated by reference herein. Other examples can be found in M. Bellare et al., “Optimal Asymmetric Encryption,” Advances in Cryptology—EUROCRYPT '94, Lecture Notes in Computer Science 950, pp. 92-111, 1995; and R. Cramer et al., “A Practical Public Key Cryptosystem Provably Secure Against Adaptive Chosen Ciphertext Attack,” Advances in Cryptology—CRYPTO '98, Lecture Notes in Computer Science 1462, pp. 13-25, 1998, the disclosures of which are incorporated by reference herein.
Signature schemes. A digital signature scheme S is a triple (Gsig, S, V) of algorithms, the first two being probabilistic, and all running in expected polynomial time. Gsig takes as input 1λ and outputs a public key pair (pk, sk), i.e., (pk, sk)←Gsig (1λ). S takes a message m and a secret key sk as input and outputs a signature (e for m, i.e., σ←S(sk,m). V takes a message m, a public key pk, and a candidate signature σ′ for m as input and returns the bit b=1 if σ′ is a valid signature for m, and otherwise returns the bit b=0. That is, b←V(pk,m,σ′). Naturally, if σ←S(sk,m), then V(pk,m,σ)=1.
1. Delegation for S-RSA
As mentioned above, the U.S. patent application identified as Ser. No. 10/072,331 described several systems by which dvc could involve a server for performing the password-checking function and assisting in its cryptographic operations, and thereby gain immunity to offline dictionary attacks if captured. The first of these systems, denoted “generic,” did not support the disabling property (the instantiation of G4 for a single server and no delegation), but worked for any type of public key algorithm that dvc used. As part of the signing/decryption protocol in this system, dvc recovered the private key corresponding to its public key. This, in turn, renders delegation in this system straightforward, being roughly equivalent to a re-initialization of the device using the same private key, but for a different server. The changes needed to accommodate delegation are also reflected in the RSA system detailed herein, and so further discussion of a generic protocol is not necessary.
The system described in Ser. No. 10/072,331 by which dvc performs RSA signatures is called S-RSA. At a high level, S-RSA uses 2-out-of-2 function sharing to distribute the ability to generate a signature for the device's public key between the device and the server. The server, however, would cooperate with the device to sign a message only after being presented with evidence that the device was in possession of the user's correct password.
In this section, a new system for RSA signatures is described, called S-RSA-D
1.1 Preliminary Considerations
It is presumed that the device signs using a standard encode-then-sign RSA signature algorithm (e.g., “hash-and-sign” as described in D. E. Denning, “Digital Signatures with RSA and Other Public-key Cryptosystems,” Communications of the ACM 27(4):388-392, April 1984, the disclosure of which is incorporated by reference herein) as described below.
The public key of the device is pkdvc=<e, N> and the secret key is skdvc=<d, N, φ (N)>, where ed≡φ(N) 1, N is the product of two large prime numbers, and φ is the Euler totient function. The notation≡φ(N) means equivalence modulo φ (N). The device's signature on a message m is defined as follows, where ‘encode’ is the encoding function associated with S, and Ksig denotes the number of random bits used in the encoding function (e.g., κsig=0 for a deterministic encoding function):
S<d,N,φ(N)>(m): r←R{0, 1}κ
σ←(encode(m, r))d mod N
return<σ, r>
Note that it may not be necessary to return r if it can be determined from m and σ. We remark that “hash-and-sign” is an example of this type of signature in which the encoding function is simply a deterministic hash of m, and that PSS (as described in M. Bellare et al., “The Exact Security of Digital Signatures—How to Sign with RSA and Rabin, Advances in Cryptology—EUROCRYPT '96, Lecture Notes in Computer Science 1070, pp. 399-416, 1996, the disclosure of which is incorporated by reference herein) is another example of this type of signature with a probabilistic encoding.
Both of these types of signatures were proven secure against adaptive chosen message attacks in the random oracle model. Any signature of this form can be verified by checking that σe≡N encode (m, r). In the function sharing primitive used in the system of the invention, d is broken into shares d0, d1 and d2 such that d0+d1+d2≡φ(N)d.
1.2 Device Initialization
The inputs to device initialization are the identity of svr0 and its public encryption key pksvr
t←R{0, 1}κ
u←hdsb1(t)
ν←R{0, 1}κ
a←R{0, 1}κ
b←ƒ(ν, π0)
d0←h(π0)
d1←R{0, 1}λ+κ
d2←d−d1−d0 mod φ(N)
ζ←Epk
τ←Epk
Above, h is assumed to output a (λ+κ)-bit value. The values pkdvc, u and record <svr0, pksvr
The ticket τ will be sent to svr within the context of the S-RSA-D
In anticipation of its own compromise, dvc may include a policy statement within τ to instruct svr0 as to what it should or should not do with requests bearing this ticket. This policy could include an intended expiration time for τ, instructions to cooperate in signing messages only of a certain form, or instructions to cooperate in delegating only to certain servers. As discussed above, here we assume a default policy that restricts delegation to only servers in U. For simplicity, we do not expressly illustrate this policy and its inspection in device initialization and subsequent protocols, however, given the inventive teachings herein, one of ordinary skill in the art will easily realize its implementation.
1.3 S-RSA-DEL Signature Protocol
This subsection illustratively explains the protocol by which the device signs a message m. The input provided to the device for this protocol is the input password π, the message m, and the identity svr of the server to be used, such that dvc holds an authorization record <svr, pksvr, τ, t, ν, d1, a>, generated either in the initialization procedure of subsection 1.2 above, or in the delegation protocol of subsection 1.4 below. Recall that dvc also stores pkdvc=<e, N>.
In general, this protocol generates a signature for m by constructing encode (m, r)d
Further, δ is a message authentication code computed using a, to show the server that this request originated from the device. δ enables svr to distinguish an incorrect password guess by someone holding the device from a request created by someone not holding the device. Since svr should respond to only a limited number of the former (lest it allow an online dictionary attack to progress too far), δ is important in preventing denial-of-service attacks against the device by an attacker who has not compromised the device.
In step 110, δ is computed by the device and represents, as mentioned above, a message authentication code computed using a to show the server that this request originated from the device.
Next, in step 112, the device transmits the values γ, δ and τ to the server.
Upon receipt of these values, the server decrypts the ticket τ in order to recover values a, b and u, d2 and N in step 114. In step 116, the server uses γ, δ and τ to confirm that this request for a private key actually originated from the device. Thus, if maca (<γ, τ>)≠δ, then the server aborts the private key retrieval operation. Also, in step 118, the server aborts the operation if it is determined that u (ticket identifier) is disabled. In step 120, the server decrypts γ in order to recover values m, r, β and ρ. In step 122, the server determines whether it is in receipt of a request that bears τ and originated from the device but that is a request for which the device's knowledge of the user's password cannot be verified. Thus, if β≠b, then the server aborts the private key operation.
Assuming the operation is not terminated in step 116, 118 or 122, the server computes ν in step 124 using the ‘encode’ function m, r, d2 (the server's share of d) and N. In step 126, the server then computes parameter η by performing an exclusive-OR operation between ρ and ν. In step 128, the server transmits the result η to the device.
In step 130, the device computes parameter ν by performing an exclusive-OR operation between ρ and η. The device computes d0 in step 132 as ƒ (ν, π). In step 134, the device computes the signature s using the ‘encode’ function m, r, d0, d1 and N. The signature is verified in step 136, and returned (outputted) in step 138.
The efficiency of the S-RSA-DEL signature protocol illustrated in
1.4 S-RSA-DEL Delegation Protocol
This subsection illustratively explains the protocol by which the device delegates the capability to help it perform cryptographic operations to a new server. The inputs provided to the device are the identity svr of the server to be used, such that dvc holds an authorization record <svr, pksvr, τ, t, ν, d1, a>, a public key pksvr′ for another server svr′ εU, and the input password π. As described above in subsection 1.2, one could also input additional policy information here. Recall that dvc also stores pkdvc=<e, N>. The protocol is described in
The overall goal of the protocol in
In addition to the manipulation of these shares of d, this protocol borrows many components from the signature protocol of
The value α is important in this protocol for protecting against denial-of-service attacks by a network attacker. α is a mac key used to authenticate svr's response to dvc. This is important to prevent a network attacker from falsifying the value η to the dvc in the delegation protocol. Since dvc cannot verify the correctness of η, permitting the falsification of η could result in dvc completing this protocol with a corrupt and useless authorization record <svr′, pksvr′, τ′, t, ν′, d′1, α′>. Thus, dvc authenticates the response from svr using a to prevent a network attacker from falsifying η. It is important to note, however, that a corrupt svr could still undetectably generate η incorrectly, and so α provides limited (but practically important) protection in this regard. It is also interesting to contrast the use of α in this protocol with the absence of any such mechanism in the S-RSA-D
Next, in step 212, the device transmits the values γ, δ and τ to the server.
Upon receipt of these values, the server decrypts the ticket τ, in step 214, to obtain a, b, d12, ξ, and N. In step 216, the server determines whether this request actually originated from the device, and aborts the operation if it is determined that it has not. In step 218, the server decrypts γ to obtain β, pksvr′, ρ and α. In step 220, the server determines whether it is in receipt of a request that bears τ and originated from the device but that is a request for which the device's knowledge of the user's password cannot be verified. Thus, if β≠b, then the server aborts the operation. In step 222, the server decrypts ξ to obtain u and d22. In step 224, the server aborts the operation if it is determined that u (ticket identifier) is disabled.
In step 226, the server computes d2 from d12 and d22. In steps 228 and 230, the server computes d′21 and d′22, respectively. Next, the server encrypts u and d′22, in step 232, to generate ξ′. In step 234, the server then computes parameter η by exclusively-ORing ρ with d′21 and ξ′. Then, in step 236, the server computes δ′ based on η. In step 238, the server transmits the results δ′ and η to the device.
In step 240, the device determines whether the received results actually originated from the server, and aborts the operation if it is determined that it has not. Further, as shown in
Then, in step 256, the device computes τ′ as an encryption of a′, b′, d′12, ξ′ and N. Lastly, in step 258, the device stores svr′, pksvr′, τ′, t, ν′, d′1 and a′. These values are to be used when the device performs a signature protocol with a secondary server svr′.
To relate this protocol to the system model discussed above, we define the execution of the code before the first message in
1.5 Key Disabling
The S-RSA-DEL signature system of the invention supports the ability to disable the device's key at servers, as would be appropriate to do if the device were stolen. Provided that the user backed up t before the device was stolen, the user can send t to a server svr. The server svr can then store u=hdsbl(t) on a list of disabled ticket identifiers. Subsequently, svr should refuse to respond to any request containing a ticket τ with a ticket identifier u. Rather than storing u forever, the server can discard u once there is no danger that pkdvc will be used subsequently (e.g., once the public key has been revoked). Note that for security against denial-of-service attacks (an attacker attempting to disable u without t), we do not need hdsbl to be a random oracle, but simply a one-way hash function.
In relation to the model described above, svr.disable denotes the event in which svr receives t and marks u =hdsbl(t) as disabled. For convenience, we say that a ticket τ is disabled at svr if τ contains u as its ticket identifier and u is marked as disabled at svr.
2. Delegation for D-ELG
In addition to RSA signatures, ElGamal decryption has also been used to demonstrate the general approach to achieving capture-resilient devices presented herein. As mentioned, Ser. No. 10/072,331 presented a protocol D-E
2.1 Preliminary Considerations
For ElGamal encryption, the public and private keys of the device are pkdvc=<g, p, q, y>and Skdvc=<g, p, q, x>, respectively, where p is a λ-bit prime, g is an element of order q in Zp*, x is an element of Zq chosen uniformly at random, and y=gx mod p. Following Ser. No. 10/072,331, we describe the D-ELG protocol using an abstract specification of “ElGamal-like” encryption. An ElGamal-like encryption scheme is an encryption scheme in which: (i) the public and private keys are as above; and (ii) the decryption function D can be expressed in the following form:
D<g, p, q, x>(c): abort if valid(c)=0
w←select(c)
z←wx mod p
m←reveal(z, c)
return m
Above, valid(c) tests the well-formedness of the ciphertext c; returning a one if well-formed and a zero otherwise. Further, select(c) returns the argument w that is raised to the x-th power modulo p. Still further, reveal(z, c) generates the plaintext m using the result z of that computation. For example, in original ElGamal encryption, where q=p−1 and c=<c1, c2>=<gk mod p, myk mod p> for some secret value kεZq, valid(c1, c2) returns one if c1, c2εZp* and zero otherwise; select(<c1, c2>) returns c1; and reveal(z, <c1, c2>) returns c2z−1 mod p. We note, however, that the private key is not an argument to valid, select, or reveal; rather, the private key is used only in computing z. Using this framework, the D-E
There are several possibilities for ElGamal-like encryption schemes that, when used to instantiate the framework above, enable goals G1-G4 to be proved for our D-E
If the original ElGamal scheme is secure against indifferent chosen ciphertext attacks, then the D-E
2.2 Device Initialization
The inputs to device initialization are the identity of a server svr0 along with its public encryption key pksvr
t←R{0, 1}κ
u←hdsbl(t)
ν←R{0, 1}κ
a←R{0, 1}κ
b←ƒ(ν, π0)
x0←h(π0)
x1←RZq
x2←x−x1−x0 mod q
ξ←Epk
τ←Epk
We assume h produces an output of λ+κ bits. The value pkdvc and the authorization record <svr0, pksvr
2.3 D-ELG-DEL Decryption Protocol
This subsection describes the protocol by which the device decrypts a ciphertext c generated using the device's public key in an ElGamal-like encryption scheme. The input provided to the device for this protocol is the input password π, the ciphertext c, and the identity svr of the server to be used, such that dvc holds a record <svr,pksvr, τ, t, ν, x1, a>. Recall that dvc also stores pkdvc=<g, p, q, y>.
Further, hzkp is assumed to return an element of Zq. It should be observed that, with DELG-DEL, the device's decryption function is implemented jointly by dvc and svr. Moreover, <ν, e, s>constitutes a noninteractive zero-knowledge proof from svr (the “prover”) to dvc (the “verifier”) that svr constructed its contribution ν correctly. As before, β is a value that proves the device's knowledge of π to the server, γ is an encryption of c, β, and ρ to securely transport them to the server, and δ0 is a message authentication code computed using a, to show the server that this request originated from the device.
Next, in step 312, the device transmits the values γ, δ and τ to the server.
Upon receipt of these values, the server decrypts the ticket τ in order to recover values a, b, u, p, q, g and X2 in step 314. As before, in step 316, the server uses γ, δ and τ to confirm that this request for a private key actually originated from the device. Thus, if maca (<γ, τ>)≠δ, then the server aborts the decryption operation. In step 318, the server aborts the operation if it is determined that u (ticket identifier) is disabled.
In step 320, the server decrypts γ in order to recover values c, β and ρ. In step 322, the server determines whether it is in receipt of a request that bears τ and originated from the device, but that it is a request for which the device's knowledge of the user's password cannot be verified. Thus, if β≠b, then the server aborts the decryption operation.
In step 324, the expression select(c) returns the argument w that is then raised to the x-th power modulo p in step 326 to generate ν. In step 328, the server then computes parameter η by performing an exclusive-OR operation between ρ and ν. The value r is computed by the server in step 330. Then, in step 332, values ν, ν′, gr mod p are hashed using function hzkp in order to generate e. The value s is then computed by the server in step 334. In step 336, the server transmits the results η, e, and s to the device.
In step 338, the device computes value ν by performing an exclusive-OR operation between ρ and η. A check is made in step 340 to determine whether νq is equal to 1 mod p. If not, the operation is aborted. The device, in step 342 (like step 322 at the server), computes w using select(c). In step 344, the device computes x0 as a hash of π. In step 346, a check is made to confirm that the returned value of e is consistent with the hash function hzkp. If it is not, then the decryption operation is aborted. The value μ is computed in step 348 as wx0+x1 mod p. Then, in step 350, the reveal expression generates the plaintext m using ν, μ, p and c.
Thus, it is to be understood that the device's decryption function is implemented jointly by dvc and svr in accordance with the protocol, in a manner that supports delegation.
Decryption via the D-E
2.4 D-ELG-D
In this subsection, a protocol is provided by which the device delegates the password-checking function from an authorized server svr to another server svr′. The inputs provided to the device for this protocol are the identity of svr, such that dvc holds a record <svr, pksvr, τ, t, ν, x1, a>, the public key pksvr′ for svr′, and the input password π. As stated above, one could also input policy information here. Recall that dvc also stores pkdvc=<g, p, q, y>. The protocol is described in
In general, the overall goal of the D-ELG-DEL protocol is to generate a new share x′2 for server svr′, and new share x′1 and new ticket τ′ for the device to use with svr′. The values x′1 and x′2 are constructed in a fashion similar to how d′1 and d′2 were constructed in
Next, in step 412, the device transmits the values γ, δ and τ to the server.
Upon receipt of these values, the server decrypts the ticket τ, in step 414, to obtain a, b, g, p, q, x12, and ξ. In step 416, the server determines whether this request actually originated from the device, and aborts the operation if it is determined that it has not. In step 418, the server decrypts γ to obtain β, pksvr′, ρ and α. In step 420, the server determines whether it is in receipt of a request that bears τ and originated from the device but that is a request for which the device's knowledge of the user's password cannot be verified. Thus, if β≠b, then the server aborts the operation. In step 422, the server decrypts ξ to obtain u and x22. In step 424, the server aborts the operation if it is determined that u (ticket identifier) is disabled.
In step 426, the server computes x2 from x12 and x22. In steps 428 and 430, the server computes x′21 and x′22, respectively. Next, the server encrypts u and x′22, in step 432, to generate ξ′. In step 434, the server then computes parameter η by exclusively-ORing ρ with x′21 and ξ′. Then, in step 436, the server computes δ′ based on η. In step 438, the server transmits the results δ′ and η to the device.
In step 440, the device determines whether the received results actually originated from the server, and aborts the operation if it is determined that it has not. Further, as shown in
Then, in step 456, the device computes τ′ as an encryption of a′, b′, g, p, q, x′12, and ξ′. Lastly, in step 458, the device stores svr′, pksvr′τ′, t, ν′, x′1 and a′. These values are to be used when the device performs a decryption protocol with a secondary server svr′.
2.5 Key Disabling
Like S-RSA-D
Referring now to
Typically, and as labeled in
As is readily apparent to one of ordinary skill in the art, the servers and client may be implemented as programmed computers operating under control of computer program code. The computer program code is stored in a computer readable medium (e.g., a memory) and the code is executed by a processor of the computer system. Given this disclosure of the invention, one skilled in the art can readily produce appropriate computer program code in order to implement the protocols described herein.
In any case,
Although illustrative embodiments of the present invention have been described herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various other changes and modifications may be made by one skilled in the art without departing from the scope or spirit of the invention.
This application claims priority to the U.S. provisional patent application identified as Ser. No. 60/300,993 filed on Jun. 26, 2001, and entitled “Delegation of Cryptographic Servers for Capture-Resilient Devices,” the disclosure of which is incorporated by reference herein. This application is related to the commonly-assigned U.S. patent application identified as Ser. No. 10/072,331 filed on Feb. 7, 2002, and entitled “Methods and Apparatus for Providing Networked Cryptographic Devices Resilient to Capture,” the disclosure of which is incorporated by reference herein.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5535276 | Ganesan | Jul 1996 | A |
| 5557678 | Ganesan | Sep 1996 | A |
| 5588061 | Ganesan et al. | Dec 1996 | A |
| 5721779 | Funk | Feb 1998 | A |
| 5737419 | Ganesan | Apr 1998 | A |
| 5748735 | Ganesan | May 1998 | A |
| 5838792 | Ganesan | Nov 1998 | A |
| 5905799 | Ganesan | May 1999 | A |
| 6138235 | Lipkin et al. | Oct 2000 | A |
| 6367009 | Davis et al. | Apr 2002 | B1 |
| 6601171 | Carter et al. | Jul 2003 | B1 |
| 6643774 | McGarvey | Nov 2003 | B1 |
| 20020112155 | Martherus et al. | Aug 2002 | A1 |
| 20020147917 | Brickell | Oct 2002 | A1 |
| 20030216172 | LeMay et al. | Nov 2003 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20030048909 A1 | Mar 2003 | US |
| Number | Date | Country | |
|---|---|---|---|
| 60300993 | Jun 2001 | US |
