Patent Grant
7814320
This present invention relates to cryptography, and more particularly to authentication and to establishing a shared cryptographic key by two parties by means of a (possibly short) secret about which the two parties have information.
Consider two parties, Alice and Bob. Alice and Bob may be implemented via hardwired and/or software programmable circuitry capable of performing processing logic. Suppose Alice and Bob desire to communicate securely over an insecure network, but their only means of verifying each other's identity consists of a short secret password (e.g., a 4-digit PIN number), for which Alice knows the password itself, and Bob knows at least some “password verification information”. In particular, it is possible that neither of them knows a public key corresponding to the other party, and neither has a certified public key (i.e., a public key whose certificate can be verified by the other party). In this scenario, Alice needs to be concerned not only with eavesdroppers that may try to steal the password by listening in on her communications, but also with the party with whom she is communicating, since a priori she cannot even be sure she is communicating with Bob. Bob's situation is similar.
If Alice and Bob shared a high-strength cryptographic key (i.e., a long secret), then this problem could be solved using standard solutions well-known in the art for setting up a secure channel, such as the protocol of Bellare and Rogaway [4]. However, since Alice and Bob only have information about a short secret password, they may also be concerned with offline dictionary attacks. An offline dictionary attack occurs when an attacker obtains some password verification information that can be used to perform offline verification of password guesses. For example, suppose Alice and Bob share a password π, and an attacker somehow obtained a hash of the password h(π), where h is some common cryptographic hash function such as SHA-1 [39]. Then the attacker could go offline and run through a dictionary of possible passwords {π1, π2, . . . }, testing each one against h(π). For instance, to test if πi is the correct password, the attacker computes h(πi) and checks if h(πi)=h(π). In general, the password verification information obtained by the attacker may not be as simple as a hash of a password, and an attacker may not always be able to test all possible passwords against the password verification information, but if he can test a significant number of passwords, this is still considered an offline dictionary attack. Wu [47] describes how effective an offline dictionary attack can be.
Accordingly, it is desirable to establish a protocol for communication between Alice and Bob so that they can bootstrap information about a short secret (the password) into a long secret (a cryptographic key) that can be used to provide a secure channel.
Such protocols are called in the art password-authenticated key exchange (PAKE) protocols. Informally, a PAKE protocol is secure if the only feasible way to attack the protocol is to run a trivial online dictionary attack of simply iteratively guessing passwords and attempting to impersonate one of the parties. (This type of attack can generally be detected and stopped by well-known methods, as discussed below.) The problem of designing a secure PAKE protocol was proposed by Bellovin and Merritt [6] and by Gong et al. [21], and has since been studied extensively.
If the PAKE protocol designates one of Alice or Bob as a client, and the other one as a server, and if it guarantees that a compromise of the server does not reveal any information that could be used to impersonate the client without performing at least an offline dictionary attack, then the protocol is said to have resilience against server compromise. Such a protocol is also called an augmented PAKE protocol. This problem of designing an augmented PAKE protocol was proposed by Bellovin and Merritt [7], and has also been studied extensively. In the foregoing, many techniques in the art that have been proposed to solve this problem will be discussed.
One major application of PAKE is to bootstrap a public key infrastructure (PKI). Specifically, a user can use a PAKE protocol to set up a secure channel to a credential store to securely download his certificate for a public key and the corresponding private key. Thus a user does not need to be concerned about storing his private key on his local device, where it may be stolen—laptop theft is a major problem—or it may simply be lost, say if the hard drive of the user's device is damaged from falling on the ground. One example of a system that uses a PAKE protocol in such a way is Plan9, and more specifically, SecureStore in Plan9 [14].
Previous Solutions
Many common password authentication techniques in the art are unilateral authentication techniques, that is, only one party (a user or client) is authenticated to the other party (a server), but not vice-versa. (On the other hand, a PAKE protocol as described above is a mutual authentication technique.) For convenience we will apply the labels client and server to describe the two principals Alice and Bob, bearing in mind, however, that these terms are merely convenient labels.
One simple technique is for the client to send a password to the server without any form of cryptographic protection. This type of authentication is used in some older Internet applications, as well as many web-based mail applications. However, this is insecure against an eavesdropper on the network. This technique might be acceptable on channels wherein eavesdropping is relatively difficult.
A more advanced technique is challenge-response, wherein the server sends a challenge to the client, and the client responds with a message depending on the challenge and the password, for instance the hash of the challenge and password concatenated. This type of authentication is used in some operating systems to enable network access. However, this technique is vulnerable to an offline dictionary attack by an eavesdropper since the challenge and its corresponding response, together, make password verification information. An attacker eavesdropping on the communication could take the transcript of the conversation (i.e., the challenge and the hash value), and try all possible passwords until one matches.
A more secure technique involves sending a password to the server over an anonymous secure channel, wherein the server has been verified using a public key. This type of authentication is used in some remote terminal applications, as well as web-based applications, and it depends intrinsically on the ability of the client to verify the server's public key. When used on the web, the public key of the server is certified by a certification authority that is presumably trusted by the client. For remote terminal applications, there typically is no trusted third party, and security relies on the client recognizing the public key, perhaps with a “fingerprint,” or hash, of the public key. As long as the server's public key can be verified, this type of authentication is secure. However, if the server's public key cannot be verified, then this type of authentication is vulnerable to an attacker that is able to impersonate the server. For instance, in the web-based application, this could occur if the attacker obtains a certificate improperly, and in a remote terminal application, this could occur if the client machine has not previously stored the public key of the server.
Accordingly, it is desirable to find a Password Authenticated Key Exchange (PAKE) algorithm secure against offline dictionary attack. Such security should be achieved at least when no participants are compromised. If a party has been compromised by an adversary, the adversary may obtain some password verification information which will defeat the security against an offline dictionary attack. However, if for example the server is compromised, it is desirable that while the offline dictionary attack security may be defeated, the protocol would be resilient to server comprise.
It will be understood that it is the objective of any PAKE protocol to be secure against offline dictionary attacks. Since the PAKE problem was introduced, it has been studied extensively, and many PAKE protocols have been proposed, e.g., [7, 21, 20, 24, 25, 34, 45, 46, 33, 32]. Many of these protocols have been shown to be insecure [10, 40]. It is therefore desirable to develop a protocol that can be proven secure according to some reasonable cryptographic assumption. Many of these PAKE protocols also claim to be resilient to server compromise, e.g., [7, 25, 46, 33, 38], and it is also desirable to develop protocols that can be proven to be resilient to server compromise according to some reasonable cryptographic assumption.
More recent PAKE protocols have proofs of security, based on certain well-known cryptographic assumptions, although some of these proofs assume the existence of ideal hash functions or ideal ciphers (i.e. black-box perfectly-random functions or keyed permutations, respectively). Such a means is commonly used by those skilled in the cryptographic arts to provide a mathematical proof of security of their work to others skilled in the art. A few recent papers [2, 12, 1] present refinements of the EKE protocol of [7] and prove security based on the Diffie-Hellman (DH) assumption [16]. The first assumes both ideal ciphers and ideal hashes, while the others assume only ideal hashes. Other papers [35, 51] present refinements of the OKE protocol of [34] and prove security based on the RSA assumption [42]. These all assume ideal hashes. Another paper [30] presents new protocol based on a variant of the Cramer-Shoup cryptosystem [15] and proves security based on the decisional DH assumption (see, e.g., [11]), assuming only a public random string (not an ideal hash function). Some variants of the [30] protocol are presented in [18, 29, 13]. Another password-authenticated key exchange protocol was developed in [19] and proven secure based on trapdoor permutations without any setup assumptions, but with a restriction that concurrent sessions with the same password are prohibited.
In terms of resilience to server compromise, the following papers contain protocols that have proofs of security assuming the existence of ideal hash functions [12, 37, 35].
For the purposes of bootstrapping PKI, it has been noticed that one may not need a full PAKE protocol, but just a password-based protocol designed solely for downloading a set of credentials (or at least a static cryptographic key used to decrypt an encrypted set of credentials). One protocol that does this is [17], and a variant is [26]. Security for these protocols relies on a non-standard assumption related to Diffie Hellman.
Previous Password Authenticated Key Exchange schemes have been implemented in commercial products and have been specified for use within several technology standards. The SRP protocol [46] has been implemented for a variety of applications, including telnet and ftp [50]. There are also two IETF RFCs related to SRP: RFC 2944 [48] and RFC 2945 [49]. The SPEKE protocol [24] has been implemented and is available [41] for licensing. The PAK protocol [12] has been implemented and is used in the SecureStore protocol [14].
There are currently PAKE standards being developed in the IEEE P1363 working group and in ISO/IEC 11770-4 working group. The IEEE P1363 working group is developing the P1363.2 draft standard specifications for password-based public key cryptographic techniques, which is likely to include PAK [12], SPEKE [24], SRP [46], AMP [33], and the Ford-Kaliski/Jablon protocol [17,26], along with variations of these protocols. The ISO/IEC 11770-4 draft standards will most likely include all of these except PAK.
The function H1( ) maps passwords into a finite cyclic group Gq of an order q. Gq can be a subgroup of the multiplicative group ZP* of the ring Zp, of integers modulo a prime number p. Element g is a generator of Gq, Symbols Hi(e.g. H2, H3, H4) denote various hash functions. For example, the following hash functions can be used:
Hi(x)=H(ASCII(i)∥x) (1)
where H( ) is the SHA-1 function or some other hash function. The functions H1 and H2 have values in Gq, so if Gq is a subgroup of Zp*, then for i=1, 2 one can set
Hi(x)=H(ASCII(i)∥x)mod p. (2)
Other suitable hash functions are described in [38].
For better security, neither the client C nor the server S need to store the password π. The client C can receive the password and the server's name S as input from a user via a keyboard or some other input device. For each client C having a password π=πC, the server stores a database record πS[C] which may include the value H1(πC). In
Step 110C is performed by the client C as in the Diffie-Hellman (DH) secret key exchange protocol. More particularly, the client generates a random element x of Zq (i.e., x is an integer from 0 to q−1), and computes α=gx. At step 120C, the client computes H1(π) and then computes m=α·H1(π). At step 124C, the client sends its name C and the value m to the server.
At step 110S, the server performs some simple checking on m (using a function ACCEPTABLE( )), and aborts if this check fails. The check can be that m mod p is not 0. At step 120S, the server generates a random y in Zq and computes μ=gy. At step 130S, the server uses its stored value H1(πC)−1 to compute the client's value α (see step 110C):
α=m·H1(πC)−1.
At step 140S, the server computes the DH shared key value σ=αy (this value is equal to gxy). At step 150S, the server computes a value k=H2(<C,S,m,μ,σ,H1(πC)−1>). At step 160S, the server sends the values μ, k to the client to prove that the server knows H1(πC)−1 (and hence H1(πC) assuming that inverting H1(πC)−1 is easy in Gq; of note, the inversion can be easily done in Zp* using the Extended Euclidean Algorithm).
The client verifies the server's proof at steps 130C, 140C. More particularly, at step 130C, the client computes σ as μx. At step 140C, the client computes H1(π)−1, then H2(<C,S,m,μ,σ,H1(π)−1>), and aborts if this latter value does not equal the server's k. At step 160C, the client generates a value k′=H3(<C,S,m,μ,σ,H1(πC)−1>) and sends this value to the server (step 170C) as a proof that the client knows H1(π). At step 170S, the server verifies the proof by computing H3(<C,S,m,μ,σ,H1(πC)−1>) and checking that this value equals k′.
At respective steps 180C, 180S, the client and the server each generate a shared session key K=H4(<C,S,m,μ,σ,H1(πC)−1>). K can be a long key.
Of note, the information send over the network (i.e. the values C, m, μ, k, k′) is difficult to use for an offline dictionary attack. For example, the use of σ in the expressions for k and k′ (steps 150S, 160C), and the use of the random number y in generating σ, make it difficult to mount an offline dictionary attack even if the communications between C and S are intercepted.
However, if an adversary compromises the server S, the adversary can obtain the value H1(π)−1 from πS[C] and compute H1(π). The adversary can then impersonate the client C because the protocol does not require the client to prove knowledge of any information about π other than H1(π). Hence, the protocol is not resilient against server compromise.
E<C,π
where H7( ) is a suitable hash function, e.g. as in (1) or (2). This encryption is called “one-time pad”.
The client performs steps 110C-124C as in
c′=H5(<C,S,m,μ,σ,H1(<C,π>)−1>)⊕E<C,π
where H5 is some hash function (e.g. as in (1) or (2)). At step 160S, the server sends the value c′ together with μ and k to the client.
The client performs steps 130C, 140C as in
E<C,π
At step 220C, the client decrypts c=E<C,π
sk=c⊕H7(<C,π>)−1 (6)
The client also does some validity checking on sk, and aborts if the check fails. At step 230C, the client computes a digital signature s=Sigsk(μ) on the server's DH key μ (see step 120S in
s′=H6(<C,S,m,μ,σ,H1(<C,π>)−1>)⊕s (7)
and sends s′ to the server (step 250C). At step 220S, the server recovers the signature s by computing:
s=H6(<C,S,m,μ,σ,H1(<C,π>)−1>)⊕s′ (8)
At step 230S, the server verifies the signature with the public key pk obtained from πS[C]. If the verification fails, the server aborts. The shared key generation (steps 180C, 180S) is performed as in
This section summarizes some features of the invention. The invention is defined by the appended claims.
The inventors have observed that the PAK-Z protocol of
The attack exploits the following property of the DL based signature schemes. The signing key sk and the corresponding verification key pk=pk(sk) are related such that
pk(sk)=gsk (9)
where g is an element of a finite cyclic group, and g is known to the signer. Therefore, for any integer j,
pk(sk+j)=pk(sk)·gj (10)
so pk(sk+j) can be computed without knowing sk.
The Single-Bit-Malleability Attack proceeds as follows. Referring to step 210S, denote d=|c|, i.e. the bit length of c. Then c can be written as
c=cd−1 . . . c0
where each ci is a binary digit. At step 210S, the adversary flips one bit of c, e.g. bit i, to obtain
c*(i)=cd−1 . . . ci+1Ci*Ci−1 . . . c0
where ci*=1-ci. Referring to the encryption (3), and denoting π=πC, we can write:
c=E<C,π>(sk), and
c*(i)=E<C,π>(sk*(i)) (11)
where sk*(i) is obtained from sk by flipping the i-th bit ski of sk. The adversary does not know the i-th bit of sk, but he knows that:
sk*(i)=sk+2i if ski=0, and
sk*(i)=sk−2i if ski=1. (12)
The adversary performs the steps 214S, 160S with c*(i) instead of c. On the client side, step 210C outputs c*(i) instead of c. Step 220C outputs sk*(i) instead of sk. If sk*(i) is in the proper range, then VALID(sk*(i)) returns TRUE. Steps 230C, 240C, 250C are performed with sk*(i) instead of sk.
On the server side, step 220S outputs the value s=Sigsk*(i)(μ). Then the adversary computes
pk*=pk·g2
i.e. pk*=pk(sk+2i); see (10). Then the adversary executes Verifypk*(μ,s). If this function returns 1, the adversary concludes that pk(sk+2i) is the verification key corresponding to sk*(i), and hence sk*=sk+2i, i.e. the i-th bit of sk is 0 (see (12)). If Verifypk*(μ,s)=0, the adversary concludes that the i-th bit is 1.
The adversary can thus determine all the bits of sk in d executions of the protocol. If d is much smaller than the dictionary of possible passwords, the attack can be much more efficient than an offline dictionary attack.
In some embodiments of the present invention, the one-time pad encryption E of (3) is replaced with some other encryption EE, for example, an essentially non-malleable encryption. In some embodiments, EE is such that if c is an encryption of sk, then c*(i) is not a valid encryption under EE, or c*(i) is a valid encryption of some value sk* but the probability that an adversary can find sk* in a “reasonable time” is “about the same” as the probability that the adversary can find sk* without knowing c (say, by randomly selecting sk* from a pool of values). Here, “reasonable time” means a polynomial time with respect to at least one polynomial in the security parameter κ. The security parameter κ can be any parameter, and can for example be chosen so that with a non-negligible probability, a successful security attack would need about 2κ operations. In some embodiments, κ represents the size (e.g. the bit length) of sk. (For example, κ can be one half of the bit length of sk.) The expression that the probabilities are “about the same” means that the probabilities differ by at most a “negligible amount”. The “negligible amount” is a value whose magnitude approaches zero faster than the reciprocal of any polynomial in κ when κ approaches infinity. Each probability is defined assuming a uniform distribution on the pertinent set of values.
In some embodiments, the encryption (3) is replaced with an encryption scheme which allows the client to verify the decrypted value sk. For example, the following scheme can be used:
EE<C,π>(sk)=E<C,π>(sk)∥H8(sk) (14)
where E<C,π>(sk) is as in (3) and H8( ) is a cryptographic hash function. Denote
cE=E<C,π>(sk),cV=H8(sk) (15)
Then
c=cE∥cV (16)
Suppose the client has obtained c=EE<C,π>(sk). The client the cE portion to sk as in (6), and then compute H8(sk) and verify that this value is equal to cV.
In some embodiments, the function H8( ) is not a cryptographic hash function. For example, this function can be not one-way and/or not collision resistant. In some embodiments, H8( ) is such that at least one bit of H8(sk) depends on at least two bits of sk. In some embodiments, each of one or more bits of H8(sk), and perhaps each bit of H8(sk), depends on two or more bits of sk, and perhaps on all of the bits of sk. In addition, H8(sk) depends on all of the bits of sk in some embodiments (i.e. for any bit position j, there are two sk values which differ only in bit j but the corresponding values H8(sk) are different). In some embodiments, each of sk and H8(sk) has at least 80 bits. Other embodiments are also possible.
The invention is not limited to the embodiments described above. The invention is not limited to cases when each party does not have a public key of the other party or a certified public key, or to other cases described above. Other features of the invention are described below. The invention is defined by the appended claims.
The present invention will be understood more fully from the detailed description given below and from the accompanying drawings of various embodiments of the invention, which, however, should not be taken to limit the invention to the specific embodiments, but are for explanation and understanding only.
In the following description, numerous details are set forth to provide a more thorough explanation of the present invention. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present invention.
Some portions of the detailed descriptions that follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is a method leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
The present invention also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing computer instructions, and each coupled to a computer system bus. Computer programs can be also carried by data carrier signals over networks. Thus, the programs can be carried by carrier waves, infrared signals, digital signals, etc.
It is known to one of ordinary skill in the cryptographic arts that the security of many cryptographic inventions relies upon making certain computational intractability assumptions; for example, one may try to prove that a cryptosystem is secure so long as it is difficult to decompose a specific number into its prime factors efficiently. The term “computational” is often used in the art to identify this class of cryptographic inventions. The present invention provides a computational scheme for password authenticated key exchange. The term “information theoretic” or “unconditional” is often used in the art in conjunction with schemes that are mathematically seen to meet a specific meaningful security definition without making any type of assumption.
While it is generally preferable from a pure security perspective not to have any computational assumptions whatsoever, there are instances of problems that cannot be solved without making such an assumption (the present invention serves as such an example). In particular, according to the present state of the art, it is not possible to construct a PAKE scheme without requiring public-key cryptography [22]. Further, it is unknown, according to the present state of the art, how to implement public-key cryptography without making some form of computational assumption. Therefore, all PAKE schemes in the art, including the one described herein, require some form of computational assumption. These assumptions will be described later. Further, it is generally known by those skilled in the art that cryptographic methods can sometimes be made more efficient by incorporating computational assumptions.
It also worth noting that often times one assumption implies another. That is, if one of the assumptions were actually true, then another assumption would be seen to be true by a mathematically logical argument. Typically the means used by those skilled in the art to show such an implication, is a transformation (often known in the art as a reduction) that converts a mechanism for violating the second assumption to a mechanism for violating the first assumption. In such cases, the first assumption is called “stronger” or the second “weaker.” In general, weaker assumptions are preferable.
Signature Schemes
A signature scheme S may include a triple (GenS, Sig, Verify) of algorithms, the first two of which may be probabilistic. In some embodiments, all the three algorithms run in expected polynomial time. GenS may take as input the security parameter (usually denoted as κ and represented in unary format, i.e., 1κ) and outputs a key pair (pk,sk), i.e., (pk,sk)←GenS(1κ). Sign takes a message m and a signing key sk as input and outputs a signature σ for m, i.e., σ←Sigsk(m). Verify takes a message m, a verification key pk, and a candidate signature σ for m as input and returns an indication of whether σ is a valid signature for m. For example, Verify=Verifypk(m,σ′) may return a value 1 if σ is a valid signature for m for the corresponding private key, and otherwise return 0. Naturally, if σ←Sigsk(m), then Verifypk(m,σ)=1.
In many cases, sk is kept secret by the signer, and pk is made public. In other cases, both sk and pk are kept secret.
One example of a signature scheme is a Schnorr signature [44]. See also the Appendix below. This example is illustrative only, and should not be taken to limit the invention.
Symmetric Encryption Schemes
A symmetric encryption scheme E is a pair (Enc,Dec) of algorithms. In some embodiments, both algorithms run in expected polynomial time. Enc takes a symmetric key k and a message m as input and outputs an encryption c for m; we denote this c←Enck(m). Dec takes a ciphertext c and a symmetric key k 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 some error indication (⊥). We say an encryption scheme is essentially non-malleable if given an encryption c of an unknown message m under an unknown key k, it is difficult to compute a new encryption c′≠c of a related message m′ under key k, at least without somehow determining m.
An illustrative example of a symmetric encryption scheme that is not essentially non-malleable is a one-time pad, in which Enck(m)=H(k)⊕m, where H( ) is a hash function with output that is the same length as m and where ⊕ is taken as a bit-wise exclusive OR operation. See also (3) above. Given a ciphertext c of an unknown message m under an unknown key k, one can construct a ciphertext c*=c⊕00 . . . 001 of a related message m*=m⊕00 . . . 001, i.e., m with the last bit flipped, without determining m. In fact, one can construct the ciphertext c*(i) of any message m*(i) obtained by flipping the i-th bit of m. See (11).
An illustrative example of a symmetric encryption scheme that is essentially non-malleable is a one-time pad concatenated to a cryptographic hash of the message, i.e.
Enck(m)=H(k)⊕m|H′(m), (17)
for a cryptographic hash function H′( ). See also (14). This is essentially non-malleable since if the one-time pad portion is modified, the cryptographic hash would have to be recomputed with the correct message, implying the message has been determined.
Some embodiments of the present invention can be described without referring to the “essentially non-malleable” concept. The invention is not believed to be limited to essentially non-malleable encryption schemes.
Hash Functions
A cryptographic hash function H is a function that satisfies the following properties:
(a) One-way, i.e. given H(x), it is computationally infeasible to find a pre-image z such that H(z)=H(x), except with negligible probability;
(b) Collision resistance or at least weak collision resistance. H( ) is called collision resistant (or “strong collision resistant”) if it is computationally infeasible to find m1≠m2 such that H(m1)=H(m2). H( ) is called weak collision resistant if given m1, it is computationally infeasible to find m2≠m1 such that H(m1)=H(m2).
“Computationally infeasible” means that given a security parameter κ, the computation cannot be computed in a time equal to or less than any fixed polynomial in κ except with negligible probability (the probability is negligible in the sense that it approaches zero faster than the reciprocal of any polynomial in κ when κ approaches infinity). The security parameter κ is a measure of the size of H(m), e.g. one half of |H(m)|(where |H(m)| denotes the bit length of H(m)).
It is generally believed in the art that the following functions are one-way and collision resistant: SHA-1 and MD5 (see e.g. RFC-2104, Request for Comments, Networking Working Group, H. Krawczyk et al., HMAC: Keyed-Hashing for Message Authentication, February 1997, both incorporated herein by reference). It is believed that the function (1) is one-way and collision-resistant if H( ) is SHA-1 or MD5. It is believed that the function (2) is one-way and collision-resistant if H( ) is SHA-1 or MD5 and p is sufficiently large (e.g. having a bit length equal to or larger than the security parameter). In other words, there are no known algorithms to invert such functions, or to find two different pre-images m1 and m2 of a given function value, or to find a pre-image m2 different from a given m1 such that m1 and m2 are mapped into the same image, in at most a polynomial time in the security parameter except with negligible probability.
To prove security of some embodiments of the present invention, the hash functions would be assumed to behave like black-box perfectly random functions, referred to in the art as random oracles [3]. In [3] there is an extensive discussion on how to instantiate random oracles, and in [23] there is a discussion on key generation functions. However, the invention is not limited to such functions.
Let Π be the set of passwords in the dictionary, and let π denote a single password in Π. A password refers here to some quantity that is known mutually to some preferably small number of parties, and is typically kept otherwise secret. In the context of the present disclosure, a password may refer to any quantity which can be easily mapped to a possibly unique bit string. In some embodiments, the password is easy to memorize. In some embodiments, the bit string is unique, but it is computationally infeasible to find two passwords that map to the same bit string. Furthermore, in the context of the present invention, the terms “password” and “short secret” are synonymous. In addition, the use of the term “short” is only an indication of a preference for an easily memorizable quantity, but should not limit the invention to any specific secret length.
Some embodiments of the PAKE protocol of the present invention are run between a client computer system C and a server computer system S which communicate with signals transmitted over a network 302 (
In some embodiments, the client system C is associated with a password πC (sometimes denoted just π herein). In some embodiments, the password is associated with a human user rather than a computer system. We can think of the client system C as a computer system used by a user associated with a password πC. The same computer system may be viewed as a different “client”, and associated with a different password, when used by a different user or by the same user using a different password.
In some embodiments, the client system C does not store any per-server information (such as a server certificate) or per-user data (such as a password, or hash of a password). The client system receives the password π and the server identity S as input from the user, as shown in
πS[C]=<(H1(<C,πC>))−1,pk,EEπ
where (H1(<C,πC>))−1 is as in
EEk(m)=H7(k)⊕m∥H8(m) (18)
(the symbols | and ∥ are synonymous, and denote string concatenation). Other embodiments are also possible. For example, the function H7 could depend on C, e.g.
EE<C,k>(m)=H7(C,k)⊕m∥H8(m) (19)
In some embodiments, H1(C,πC) does not depend on the first argument, i.e. H1(C,πC)=H1(πC). Also, the server can store H1(C,πC) or H1(πC) instead of (H1(C,πC))−1. In some embodiments, the functions H1( ) are one-way. See (1) and (2) for suitable examples.
Protocol description. We construct an augmented PAKE protocol P of
Once P′ is finished and has derived a cryptographically strong shared key K, the server uses a temporary session key K′ derived from K to securely send EEπ
In more detail, one embodiment runs as follows:
Client Part 1: At step 314C, the client computes H1(<C,π>) and performs its part in the PAKE protocol P′, deriving a shared cryptographic key K. At step 320C, the client computes a key K′=H20(K) using some hash function H20( ), and a key K″=H21(K) using some hash function H21( ). In some embodiments, the functions H20, H21 are one-way and/or collision resistant.
Server Part 1: At step 314S, the server performs its part in the PAKE protocol P′, deriving a shared cryptographic key K. At step 320S, the server computes the keys K′=H20(K) and K″=H21(K).
In some embodiments, the server and the client do not compute the key K, e.g. in the case of
K′=H20(<C,S,m,μ,σ,H1(C,πC)−1>)
K″=H21(<C,S,m,μ,σ,H1(C,πC)−1>)
Server Part 2, Step 1: At step 330S, the server reads the value c=EEπ
E′K′(m)=H22(K′)⊕m (20)
for some hash function H22( ) which may or may not be a cryptographic hash function. At step 350S, the server sends the value c′ to the client.
Client Part 2, Step 1: The client receives the value c′. The client computes sk by performing decryption. In particular, at step 324C, the client computes c=D′K′(c′). For example, for the scheme (20), the client computes
c=H22(K)⊕c′ (21)
At step 334C, the client computes sk=DDπ(c). More particularly, let us write c as
c=cE∥cV (22)
where cE are the first j bits of c, where j=|sk|. See also (15), (16). The client computes
sk=cE⊕H7(π) (23)
Then the client computes H8(sk), and aborts if this value is not equal to cV. Optionally, the client may perform some additional validity checking on sk, e.g. to check if sk is in a proper range. Aborting may mean that the client generates a signal indicating an authentication failure, and skips the steps 340C, 344C, and possibly 350C.
At step 340C, the client signs the transcript of P′ using sk, i.e., it computes s=Sigsk(transcript). For example, in the case of
Server Part 2, Step 2: The server receives the signature s, and at step 360S the server computes b=Verifypk(transcripts). If b=0, the server aborts. Otherwise (step 370S), the server outputs the session key K″.
The advantage of the protocol of
Further, the protocol of
As for efficiency, the protocol of
Security Parameter Selection
Our protocol includes a cryptographic security parameter κ, or equivalently the “bit-security” of the protocol is selected. (in some embodiments, κ is one half of the output size of H8( ). According to the present state of the art, κ=80 is a reasonable choice, although for some applications of hash functions, the number should probably be increased to κ=128. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without this specific parameter choice.
The invention is not limited to the embodiments described above or to the digital signature schemes presented in the Appendix below. The function H8( ) in
EE<C,π>(sk)=E<C,π>(sk)∥H8(π,sk) (24)
The invention is not limited to one-way or weak or strong collision resistant functions. Of note, the terms “one-way”, “collision resistant”, and “essentially non-malleable” were defined in terms of polynomial time. For example, a one-way function is a function which cannot be inverted in a polynomial time except with a negligible probability. However, for a large polynomial P(κ), the security may be adequate for at least some applications even if a pertinent function can be inverted in the polynomial time P(κ) with a non-negligible probability. Also, the negligible probability and the negligible amount were defined as quantities approaching zero faster than the reciprocal of any polynomial. If a polynomial is large, then its reciprocal is small, and adequate security can be obtained even if the pertinent probabilities or amounts are not negligible (i.e. are equal to or greater than the reciprocal of some polynomial). Other embodiments and variations are within the scope of the invention, as defined by the appended claims.
1. ElGamal Signature.
1A. Key generation: Generate a random prime p and a primitive root g mod p. Choose a random integer a in the set {1, 2, . . . , p−2}. Compute A=ga mod p. The signing key is a. The verification key is (p, g, A).
1B. Signing: The signing algorithm uses a publicly known collision resistant hash function
h: {0,1}*→{1, 2, . . . , p−2}
To sign a message mε{0,1}*, choose a random number kε{1, 2, . . . , p−2} coprime to p−1. Compute
r=gk mod p,s=k−1(h(m)−ar)mod(p−1)
where k−1 is the inverse of k modulo p−1. The signature is the pair (r,s).
1C. Verification: Accept if, and only if, 1≦r≦p−1 and Arrs≡gh(s) mod p.
2. DSS Signature.
2A. Key generation: Like in ElGamal Signature, except that g does not have to be a primitive root modulo p; g can be any element of Zp*, of some order q.
2B. Signing: To sign a message mε{0,1}*, choose a random number k coprime to q. Compute
r=(gk−1 mod p)mod q,s=k(m+xr)mod q
where k−1 is the inverse of k modulo q. The signature is the pair (r,s).
2C. Verification: Accept if, and only if, r≡(gms
3. Schnorr signature.
3A. Key generation: Like ElGamal, but g can be a generator of any (public) group G of prime order p. Also, a is allowed to equal p−1.
3B. Signing: Choose a random integer kε{1, 2, . . . , p−1}. Compute
r=gk,e=h(m∥r), s=(k−ah(m∥r))mod p
where h is a public hash function. The signature is the pair (e,s).
3C. Verification: Compute r′=gsA−e. Accept iff e=h(m∥r′).
The following documents are incorporated herein by reference except the hyperlink documents [41] and [50]:
The present application claims priority of U.S. provisional patent application No. 60/700,769, filed Jul. 19, 2005, incorporated herein by reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5241599 | Bellovin et al. | Aug 1993 | A |
| 5440635 | Bellovin et al. | Aug 1995 | A |
| 6226383 | Jablon | May 2001 | B1 |
| 6411715 | Liskov et al. | Jun 2002 | B1 |
| 6757825 | Mackenzie et al. | Jun 2004 | B1 |
| 6792533 | Jablon | Sep 2004 | B2 |
| 6952771 | Zuccherato et al. | Oct 2005 | B1 |
| 6988198 | Zuccherato et al. | Jan 2006 | B1 |
| 7073068 | Jakobsson et al. | Jul 2006 | B2 |
| 7076656 | MacKenzie | Jul 2006 | B2 |
| 7149311 | MacKenzie et al. | Dec 2006 | B2 |
| 7359507 | Kaliski | Apr 2008 | B2 |
| 7493488 | Lewis et al. | Feb 2009 | B2 |
| 7522723 | Shaik | Apr 2009 | B1 |
| 20020067832 | Jablon | Jun 2002 | A1 |
| 20030079124 | Serebrennikov | Apr 2003 | A1 |
| 20030221102 | Jakobsson et al. | Nov 2003 | A1 |
| 20030229788 | Jakobsson et al. | Dec 2003 | A1 |
| 20040030932 | Juels et al. | Feb 2004 | A1 |
| 20040234074 | Sprunk | Nov 2004 | A1 |
| 20060041759 | Kaliski et al. | Feb 2006 | A1 |
| 20060095769 | Zuccherato et al. | May 2006 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20070067629 A1 | Mar 2007 | US |
| Number | Date | Country | |
|---|---|---|---|
| 60700769 | Jul 2005 | US |
