TECHNICAL FIELDThis invention relates to cryptosystems. More particularly, the present invention relates to password access to different network sites in cryptosystems.[0001]
BACKGROUND SYSTEMSToday, computing devices are almost always interconnected via networks. As these networks can be large closed networks, as within a corporation, or truly public networks as the Internet is, the network itself might have hundreds, thousands or even millions of potential users. Consequently it is often required to restrict access to any given computer or service, or a part of a computer or service to a subset of the users on the public or closed network. For instance, a brokerage might have a public website accessible to all, but would like to only give Ms. Alice Smith access to Ms. Alice Smith's brokerage account.[0002]
This is an old problem, tracing its roots to the earliest days of computers, and passwords were among the first techniques used, and to this day remain the most widely used technique for protecting resources on a computer or service.[0003]
In its simplest form, every user has a unique password and the computer has knowledge of the user password. When attempting to log on Alice would enter her userid, say alice, and password, say apple23, the computer would compare the pair, i.e. alice, apple23, with the pair it had stored for Alice, and if there is a match would establish a session and give Alice access.[0004]
This simple scheme suffers from two problems. First, the table containing the passwords is stored on the computer, and represents a single point of compromise. If Eve could somehow steal this table, she would be able to access every user's account. A second problem with this approach is that when Alice enters her password it travels from her terminal to the computer in the clear, and Eve could potentially eavesdrop. For instance the “terminal” could be Alice's PC at home, and the computer could be a server on the Internet, in which case her password travels in the clear on the Internet.[0005]
Various solutions have been proposed and implemented to solve these two issues. For instance, to solve the first problem of storing the password on the computer, the computer could instead store a one way function of the password. E.g. F(apple23)=XD45DTY, and the pair {alice, XD45DTY}. In this example as F( ) is a one way function, computing XD45DTY from apple23 is easy, but as it is a “one way function”, the reverse is believed to be difficult or close to impossible. So when Alice logs on and sends the computer {alice, apple23}, the computer can compute F(apple23) and compare the result with XD45DTY. The UNIX operating system was among the first to implement such a system in the late 1970's.[0006]
Before discussing more sophisticated conventional techniques for solving this problem, let us briefly describe symmetric, asymmetric and ‘split private key’ cryptography.[0007]
In symmetric key cryptography, the two parties who want to communicate in private share a common secret key, say K. the sender encrypts messages with K, to generate a cipher, i.e. C=Encrypt(M,K). The receiver decrypts the cipher to retrieve the message, i.e. D=Decrypt(C,K). An attacker who does not know K, and sees C, cannot successfully decrypt the message, if the underlying algorithms are strong. Examples of such systems are DES and RC[0008]4. Encryption and decryption with symmetric keys provide a confidentiality, or privacy service.
Symmetric keys can also be used to provide integrity and authentication of messages in a network. Integrity and authentication means that the receiver knows who sent a message and that the message has not been modified so it is received as it was sent. Integrity and authentication is achieved by attaching a Message Authentication Code (MAC) to a message M. E.g., the sender computes S=MAC(M,K) and attaches S to the message M. When the message M reaches the destination, the receiver also computes S′=MAC(M,K) and compares S′ with the transmitted value S. If S′=S the verification is successful otherwise verification fails and the message should be rejected. Early MACs were based on symmetric encryption algorithms such as DES whereas more recently MACs are constructed from message digest functions, or “hash” functions, such as MD5 and SHA-1. The current Internet standard for this purpose is known as hash-based MAC (HMAC).[0009]
By combining confidentiality with integrity and authentication, it is possible to achieve both services with symmetric key cryptography. It is generally accepted that different keys should be used for these two services and different keys should be used in different directions between the same two entities for the same service. Thus if Alice encrypts messages to Bob with a shared key K, Bob should use a different shared key K′ to encrypt messages from Bob to Alice. Likewise Alice should use yet another key K″ for MACs from Alice to Bob and Bob should use K′″ for MACs from Bob to Alice. Since this is well understood by those skilled in the art, we will follow the usual custom of talking about a single shared symmetric key between Alice and Bob, with the understanding that strong security requires the use of four different keys.[0010]
Symmetric key systems have been in use for literally thousands of years, and have always suffered from a major problem—namely how to perform key distribution. How do Bob and Alice agree on K? Asymmetric key cryptography was invented to solve this problem. Here every user is associated with two keys, which are related by special mathematical properties. These properties result in the following functionality: a message encrypted with one of the two keys can then only be decrypted with the other.[0011]
One of these keys for each user is made public and the other is kept private. Let us denote the former by E, and the latter by D. So Alice knows Dalice, and everyone knows Ealice. To send Alice the symmetric key K, Bob simply sends C=Encrypt(K,Ealice). Alice, and only Alice (since no one else knows Dalice), can decrypt the ciphertext C to recover the message, i.e. Decrypt(C,Dalice)=K. Now both Alice and Bob know K and can use it for encrypting subsequent messages using a symmetric key system. Why not simply encrypt the message itself with the asymmetric system? This is simply because in practice all known asymmetric systems are fairly inefficient, and while they are perfectly useful for encrypting short strings such as K, they are inefficient for large messages.[0012]
The above illustrates how asymmetric cryptography can solve the key distribution problem. Asymmetric cryptography can also be used to solve another important problem, that of digital signatures. To sign a message M, Alice encrypts it with her own private key to create S=Encrypt(M,Dalice). She can then send (M,S) to the recipient who can then decrypt S with Alice's public key to generate M′, i.e. M′=Decyrpt(S,Ealice). If M′=M then the recipient has a valid signature as only someone who has Dalice, by definition only Alice, can generate S, which can be decrypted with Ealice to produce M. To convey the meaning of these cryptographic operations more clearly they are often written as S=Sign (M, Dalice) and. M′=Verify (M,S,Ealice). It is worth noting that asymmetric key digital signatures provide non-repudiation in addition to the integrity and authentication achieved by symmetric key MACs. With MACs the verifier can compute the MAC for any message M of his choice since the computation is based on a shared secret key. With digital signatures this is not possible since only the sender has knowledge of the sender's private key required to compute the signature. The verifier can only verify the signature but not generate it.[0013]
The RSA cryptosystem is one system that implements asymmetric cryptography as described above. In particular the RSA cryptosystem allows the same public-private key pair to be used for encryption and for digital signatures. It should be noted there are other asymmetric cryptosystems which implement encryption only e.g., ElGamal or digital signature only, e.g., DSA.[0014]
Finally, the above description does not answer the important question of how Bob gets Alice's public key Ealice. The process for getting and storing the binding [Alice, Ealice] which binds Ealice to Alice is tricky. The most practical method appears to be to have the binding signed by a common trusted authority. So such a “certificate authority” (CA) can create CERTalice=Sign([Alice, Ealice], Dca). Now CERTalice can be verified by anyone who knows the CA's public key Eca. So in essence, instead of everyone having to know everyone else's public key, everyone only need know a single public key, that of the CA. More elaborate schemes with multiple Certificate Authorities, sometimes having a hierarchical relationship, have also been proposed.[0015]
Asymmetric key cryptosystems have been around for a long time, but have found limited use. The primary reasons are twofold: (a) the private key D in most systems is long, which means that users cannot remember them, and they have to either be stored on every computer they use, or carried around on smart cards or other tokens; and (b) the infrastructure for ensuring a certificate is valid, which is critical, is cumbersome to build, operate and use. The first technique proposed to validate certificates was to send every recipient a list of all certificates that had been revoked. This clearly does not scale well to an environment with millions of users. The second method proposed was to require that one inquire about the validity of a certificate on-line, which has its own associated problems.[0016]
A system based on split private key cryptography has been developed to solve these two issues, among others. In this system the private key for Alice, i.e. Dalice, is further split into two parts, Daa which Alice knows, and a part Das which is stored at a security server. To sign a message, Alice could perform a partial encryption to generate a partial signature, i.e. PS=Sign(M,Das). Alice then sends the server PS which ‘completes’ the signature by performing S=Sign(PS,Dss). This completed signature S is indistinguishable from one generated by the original private key, so the rest of the process works as previously described. However, Daa can be made short, which allows the user to remember it as a password, so this system is consumer friendly. Further, if the server is informed that a particular ID has been revoked, then it will cease to perform its part of the operation for that user, and consequently no further signatures can ever be performed. This provides for instant revocation in a simple highly effective fashion.[0017]
Let us return now to password based systems. Challenge-response systems solve the issue of having to send passwords in the clear across a network. If the computer and Alice share a secret password, P, then the computer can send her a new random challenge, R, at the time of login. Alice computes C=Encrypt(R,P) and sends back C. The computer decrypts Decrypt(C,P)=C′. If C=C′, then the computer can trust that it is Alice at the other end. Note however that the computer had to store P. A more elegant solution can be created using asymmetric cryptography. Now Alice has a private key Dalice, or in a split private key system she has Daa. The computer challenges her to sign a new random challenge R. She signs the challenge, or in the split private key system she interacts with the security server to create the signature, and sends it back to the computer which uses her public key, retrieved from a certificate, to verify the signature. Observe that the computer does not have to know her private key, and that an eavesdropper observing the signature on R gains no knowledge of her private key.[0018]
The SSL system, which is widely used on the Internet in effect implements a more elaborate method of exactly this protocol. SSL has two components, ‘server side SSL’ in which a server proves its identity by signing a particular message during connection set-up. As browsers such as Netscape and Microsoft Internet Explorer come loaded with the public keys of various CAs, the browser can verify the signature of the server. This authenticates the server to the client, and also allows for the set-up of a session key K, which is used to encrypt all further communications. Server side SSL is widely used, as the complexity of managing certificates rests with system administrators of web sites who have the technical knowledge to perform this function. The converse function in SSL, client side SSL, which lets a client authenticate herself to a server is rarely used, because although the technical mechanism is exactly the same, it now requires users to manage certificates and long private keys which has proven to be difficult, unless they use the split private key system. So in practice, most Internet web sites use server side SSL to authenticate themselves to the client, and to obtain a secure channel, and from then on use Userid, Password pairs to authenticate the client.[0019]
So far from disappearing, the use of passwords has increased dramatically. Passwords themselves are often dubbed as inherently “weak” which is inaccurate, because if they are used carefully passwords can actually achieve “strong” security. As discussed earlier passwords should not be sent over networks, and if possible should not be stored on the receiving computer. Instead, in a “strong” system, the user can be asked to prove knowledge of the password without actually revealing the password. And perhaps most critically passwords should not be vulnerable to dictionary attacks.[0020]
Dictionary attacks can be classified into three types. In all three cases the starting point is a ‘dictionary’ of likely passwords. Unless the system incorporates checks to prevent it, users tend to pick poor passwords, and compilations of lists of widely used poor passwords are widely available.[0021]
1) On line dictionary attack. Here the attacker types in a guess at the password from the dictionary. If the attacker is granted access to the computer they know the guess was correct. These attacks are normally prevented by locking the user account if there are an excessive number of wrong tries. Note that this very commonly used defense prevented one problem, but just created another one. An attacker can systematically go through and lock out the accounts of hundreds or thousands users. Although the attacker did not gain access, now legitimate users cannot access their own accounts either, creating a denial of service problem.[0022]
2) Encrypt dictionary attacks: If somewhere in the operation of the system a ciphertext C=Encrypt(M,P) was created, and the attacker has access to both C and M, then the attacker can compute off-line C[0023]1=Encrypt(M,G1), C2=Encrypt(M,G2), . . . where G1, G2, . . . etc. are the guesses at the password P from the dictionary. The attacker stops when he finds a Cn=C, and knows that Gn=P. Observe that the UNIX file system, which uses a one way function F( ) instead of an encryption function E( ), is vulnerable to this attack.
3) Decrypt dictionary attacks: Here the attacker, does not know M, and only sees the ciphertext C (where C=Encrypt(M,P). The system is only vulnerable to this attack IF it is true that M has some predictable structure. So the attacker tries M[0024]1=Decrypt(C,G1), M2=Decrypt(C,G2) . . . , and stops when the Mi has the structure he is looking for. For instance Mi could be known to be a timestamp, English text, or a number with special properties such as a prime, or a composite number with no small factors.