Electronic Information Network User Authentication and Authorization System

Widespread use of networks to interconnect heterogenous computer services is common today. Typically, in a distributed processing environment, a user will access an unsecured workstation and, using the workstation itself, access a variety of other computer services on the network. But as the use of networks has increased so have the problems relating to securing and controlling the legitimate access of users to the computer systems.

Traditionally, access to computer services was controlled through the use of passwords. Each user was associated with a user id and a password. Both the computer system and the user who wished to access a service had to know the password. The user provided the user id and the computer systems challenged the user to then provide the password. This initiated access to the system.

FIG. 1 represents a typical prior art computer network configuration. A user 10 accesses a workstation 14 which is connected to a network 18. The user 10 then accesses services 20, 22 and 24 from the workstation 14 via the network 18. User authentication is controlled through the use of a password 11 known only by user 10 and services 20, 22 and 24.

A weakness with this authentication scheme can be seen in FIG. 2. Since the workstation 14 is often installed in an unsecured environment, an illicit user may install a trojan horse 15 on the workstation 14 to spy on the input of password 11 by user 10. Further, a password thief 12 may borrow or steal the password 11 from user 10. Finally, a network eavesdropper 16 can intercept the transmission of password 11 to services 20, 22 and 24. All of these methods may be utilized to gain illicit access to service 20, 22 and 24. It will be appreciated that the network 18 can connect many other untrusted workstations and services, compounding the danger if illicit access to network services.

As seen, in a distributed processing environment, a user often needs to access resources located at multiple servers from multiple workstations interconnected via a communications network. Authentication to each host accessed is crucial, but presenting separate user id/password pairs can be both unwieldy and unsecure. What is needed is a mechanism which requires users to identify and authenticate themselves once to a trusted agent which then performs the necessary user identification and authentication to each accessed resource transparently. This is known as unitary login.

Previous work in developing secure unitary login protocols for distributed systems include those intended for open environments (e.g., the Massachusetts Institute of Technology Kerberos protocol, the Digital Equipment Corporation SPX protocol, the Carnegie Mellon University Strongbox protocol, and the ISO OSI Directory Services protocols) and those intended for closed environments (e.g., the World Wide Military Command and Control System (WWMCCS) Information System Network Authentication Service (WISNAS) protocol, the Department of Defense Intelligence Information System Network Security for Information Exchange (DNSIX) protocol, and the Strategic Air Command Intelligence Network (SACINTNET) protocol).

Each of these protocols provides different authentication services (e.g., Kerberos, SPX, WISNAS, DNSIX, and SACINTNET are more connection-oriented while Strongbox and the OSI Directory Services are more process-oriented) and depends upon different mechanisms to provide security (e.g., Kerberos employs conventional encryption, Strongbox employs zero-knowledge proofs, SPX and OSI Directory Services employ public key encryption). None of them are intended for a truly hostile environment (i.e., one subject to active attacks against both workstations/servers and the network). WISNAS, DNSIX and SACINTNET, though designed for military applications, are intended for physically secure environments with trusted users and no eavesdropping threats. The other protocols protect against the threat of network eavesdropping but assume that workstations and servers are protected by other mechanisms (e.g., physical ownership/control). Organizations could greatly ease the problems associated with password management and the threat from masquerading on their increasingly distributed information systems with a unitary login capability which was secure from both a workstation/server and a network perspective.

The Kerberos protocol possesses many advantages as a basis for this capability. Originally developed to provide user authentication for the distributed open computing environment of MIT's Project Athena, Kerberos is growing significantly in popularity (it has been adopted by the Open Software foundation and Unix International as well as being offered in several commercial products). It is based upon the use of a trusted authentication server to provide "tickets" for presentation to other system servers and uses algorithm-independent conventional (secret) key encryption to protect against network eavesdropping and masquerading. This latter feature is especially important for military/intelligence applications in that the current Data Encryption Standard (DES) algorithm might be inadequate for certain environments. If so, it can easily be replaced with a stronger algorithm.

Kerberos utilizes a trusted central authentication server, the Kerberos Authentication Server (KAS). The KAS contains a database of system entities (registered users and services) and its private cryptographic keys. Each user and each service is a separate entry, each with their own cryptographic key. These private keys, known only to the respective entity and the KAS, allow the KAS to communicate privately with the Kerberos agent of each system service (server Kerberos) and with the Kerberos agent of each registered user who wishes to be logged in (client Kerberos). The KAS also contains a "ticket" granting service to provide a trusted means for logged in users to prove their identity to system services. Finally, it contains a key generation service which supplies authorized pairs of entities with temporary cryptographic keys.

The Kerberos protocol is based upon the concept of tickets and authenticators. A ticket is issued by the KAS for a single user and a specified service. It contains the service id, the user id, the user's (workstation) address, a timestamp, the ticket's lifetime and a randomly chosen session key to be used by this service. This information is protected by encryption under the service's private key. Since this key is known only to the service and the KAS, the service is assured of the authenticity of the ticket. Once a ticket is issued, it can be reused by the named user to gain access to the indicated service until it expires. A new ticket can be issued upon the user's presenting his/her appropriate credentials.

Unlike the ticket, the authenticator is built by client Kerberos. A new one must be generated every time the user wishes to use a ticket. An authenticator contains the user's id, the user's (workstation) address, and a timestamp. The authenticator is encrypted with the session key which is associated with the ticket. Encryption of the authenticator assures the service that the user presenting the ticket is the user to whom the original ticket was issued. The agreement of the user id in the authenticator with the user id in the ticket and the address in the authenticator with the address in the ticket proves a user's authenticity. Agreement of the timestamp with the current time proves that this is a fresh ticket/authenticator pair and not a replay of an old pair.

Security within Kerberos is enforced through the protection of session keys during transmission. The initial response from the KAS to the client, upon presentation of the user id, consists of a ticket to the ticket granting service and its associated session key. The ticket granting service ticket is encrypted with the ticket granting service's private key. The ticket granting service session key is encrypted with the client's private key. Additional session keys associated with tickets to system service requested by that particular client are henceforth encrypted in the ticket granting service session key.

Kerberos has been analyzed from a general security perspective. A significant vulnerability involves its manipulation of the user's Kerberos password and other sensitive authentication information (i.e., session keys) within the workstation, thereby making it vulnerable to Trojan Horse threats which could capture such data for later use by an intruder. Another vulnerability involves the threat of repeated attacks at the intruder's leisure following interception of the initial response from the authentication server. This response contains the ticket granting server ticket (required for obtaining other tickets) and its associated session key, which is encrypted using a relatively weak password-derived key. A third vulnerability involves the inherent weakness of depending solely upon a single factor (i.e., a password) for the initial user authentication. Passwords can be easily borrowed or stolen.

The system, according to the invention, for authentication of a user to a variety of computer services on a network of heterogenous computer systems includes at least one user workstation and one authorization server connected to each other through a network. A user couples a personally protectable coprocessor (smart card) to the workstation by means of a bidirectional communication channel.

The coprocessor is adapted to receive signals including first encrypted authentication information received from the workstation. The first encrypted information is decrypted, using a preselected key, by the coprocessor. The coprocessor is further adapted to assemble second authentication information and to encrypt the second information with a preselected second key. This second information is then transmitted to the workstation. The workstation then communicates the information onto the network.

In preferred embodiments, the preselected first and second keys may either be preprogrammed into the coprocessor or be received by the coprocessor from the authorization server.

In another embodiment, the preprogrammed first and second keys may be stored in an encrypted form and be decrypted using a key derived from a user supplied password.

In another aspect of the invention, the system includes at least one user workstation connected to a network. A user couples a personally protectable coprocessor (smart card) to the workstation by means of a bidirectional communication channel.

The coprocessor is adapted to receive signals including first encrypted authentication information received from the workstation. The first encrypted information is decrypted, using a preselected preprogrammed key, by the coprocessor. The coprocessor is further adapted to assemble second authentication information and to encrypt the second information with a preselected preprogrammed second key. This second information is then transmitted to the workstation. The workstation then communicates the information onto the network.

In greater detail, the invention disclosed here is based upon moving critical cryptographic processing from the workstation into a user-unique smart card and storing the user key in encrypted form on the smart card. The user key would be encrypted in a key derived from a password. In this way, neither possession of the card alone nor knowledge of the password alone would be sufficient to authenticate a user. Encryption and decryption operations and the storage of unencrypted authentication information would occur only within a personally protectable coprocessor (i.e., that of the smart card). Since the user can remove and carry the smart card on the person, the smart card, in effect, forms a personal protectable extension of the workstation processing environment.

Past implementation of user authentication required user intervention when requesting access to a new computer service. Typically, a user presented a user id and password combination for each service or computer system. Access to various computer services was not seamless in that user intervention was required prior to authorization. Each service or computer system required a unique user id and password pair which were known to both the user and the service or computer system.

The authentication mechanism of the present invention provides for authenticating a user on a remote untrusted workstation and allowing access by the user to various secured networked computer services with only a single user login operation.

FIG. 1 is a simplified block diagram illustrating a typical prior art network of computer systems and services.

FIG. 2 is a simplified block diagram illustrating a typical prior art network of computer systems and services in a hostile environment.

FIG. 3 is a simplified block diagram illustrating a typical network of computer systems and services augmented by the present invention.

FIG. 4 is a simplified block diagram illustrating a Kerberos system augmented by the invention.

FIG. 5 is a simplified diagram of the system during the first phase of user authentication.

FIG. 6 is a simplified diagram of the system during the second phase of user authentication.

FIG. 7 is a simplified diagram of the system during the third phase of user authentication.

Kerberos utilizes a trusted central authentication server, referred to herein as the Kerberos Authentication Server (KAS). This central server contains a database of system entities (registered users and services) and their private cryptographic keys. These private keys, known only to the respective entity and the KAS, allow the KAS to communicate privately with the Kerberos agent of each system service (referred to herein as server Kerberos) and with the Kerberos agent of each registered user who wishes to be logged in (referred to herein as client Kerberos). The central server also contains a ticket granting service to provide a trusted means for logged in users to prove their identity to system services. Finally, it contains a key generation service which supplies authorized pairs of entities with temporary cryptographic keys (session keys).

The Kerberos protocol is based on the concept of tickets and authenticators. A ticket is issued by the KAS for a single user and a specified service. It contains the service id, the user id, the user's (workstation) address, a timestamp, the ticket's lifetime and a randomly chosen session key to be used by this user and this service. This information is protected by encryption under the service's private key. Since this key is known only to the service and the KAS, the service is assured of the authenticity of the ticket. Once a ticket is issued, it can be used many times by the named user to gain access to the indicated service until the ticket expires.

Unlike the ticket, the authenticator is built by client Kerberos. A new one must be generated every time the user wishes to use a ticket. An authenticator contains the user's id, the user's (workstation) address, and a timestamp. The authenticator is encrypted with the session key which is associated with the ticket. Encryption of the authenticator provides integrity of the authenticator and assures the service that the user is the system entity who received the original ticket. The further agreement of the user id in the authenticator with the one in the ticket and the address with the one from which the ticket arrived provides further assurance. Agreement of the timestamp with the current time assures the service that this is a fresh ticket/authenticator paid and not a replay of an old pair.

A new user or the administrator of a new system service must first register with Kerberos. Registration consists of making a new entry in the KAS database and issuing an id and private key. In the case of a user, the private key is issued in the form of a password. The administrator of the system service must load the service's private key into the server Kerberos software.

With reference to FIG. 3., the system, according to the invention, for authentication of a user 10 to a variety of computer services 20, 22 and 24 on a network 18 of heterogenous computer systems is comprised of at least one user workstation 14 and one authorization server 32 connected to each other through a network 18. A user 10 couples a personally protectable coprocessor 30 to the workstation 14 by means of a bidirectional communication channel 31.

In connection with the authentication procedure, the smart card is initialized at the central authorization center. The smart card is programmed with the user key which is encrypted using a key derived from a user supplied password. The encrypted user key is stored in nonvolatile memory which is only readable by the smart card. The user key and user id are also stored in the central physically secure authentication server at this time. The card is now ready for use by the user.

Following registration, user interaction with Kerberos consists of three phases. The first phase occurs during login as illustrated in FIG. 5. The user 10 first enters his user id 41 into the workstation 14 and sends a request 43 to the KAS 32. A ticket to the ticket granting service and its associated session key 44 are then generated by the KAS 32 and sent to the user's workstation 14, the session key being encrypted by the KAS 32 in a private key derived from the user's password. The user then enters a password 42 which is converted into a key and sent to the smart card 30. If the password derived key is correct, the session key is properly decrypted by the smart card 30. If the entered password is incorrect, the session key will not be decrypted.

In the second phase as illustrated in FIG. 6, the user 10, desiring to access a specific system service 20, presents the ticket granting service ticket and an associated authenticator 51 to the ticket granting service running on the KAS 32 to request a ticket for the desired system service 20. The authenticator is encrypted by the smart card 30. The ticket and associated authenticator 51 identifies and authenticates the user 10 to the ticket granting service. The ticket granting service then generates and sends an appropriate server ticket and server session key 52 to the user's workstation, the server session key being encrypted in the session key associated with the ticket granting service. This encrypted session key is then decrypted within by the user's smart card 30. In the third phase illustrated in FIG. 7, the user's workstation 14 and smart card 30 encrypts an appropriate authenticator for the desired server ticket, the user then presents the server ticket and associated authenticator 61 to the service 20, and, following validation by the server, obtains access. As illustrated in FIG. 4, the smart card 30 augments client Kerberos 70 running on the user's untrusted workstation 14 by moving the cryptographic processing 71 into the smart card 30. All encryption and decryption required for access to the authorization server 32 or a network service 20 is done within the smart card 30. With greater detail, the smart card augmented Kerberos would function as follows:

In addition to enhancing security, it is possible for the invention to maintain interoperability with existing authentication systems. For example, the invention allows smart card augmented Kerberos components to be gradually introduced into an operational environment as time and resources permit. This invention provides that neither the Kerberos authentication server (KAS) nor the server Kerberos implementations be affected in any way.

Smart cards are small credit card sized processing systems. A smart card typically contains a microcontroller (CPU), an amount of volatile random access memory (RAM), an amount of electrically erasable programmable read only memory (EEPROM), an interface to communicate outside of the card and an "operating system" residing in masked read only memory (ROM). Numerous vendors currently produce such cards, each with different CPU, RAM, EEPROM, ROM and programming characteristics. For a prototype of the present invention, the .OMEGA.megaCard.TM. by Sota Electronics, Inc. was used.

Advances in encryption and smart card technology have reached the point where significant amounts of information can be stored and significant processing can be performed entirely within the isolated environment of the card itself. When this technology is combined with user-unique information (e.g., a password) that is useless except when processed by the appropriate smart card, a significantly stronger authentication mechanism can be constructed than is available with "standard" Kerberos. Kerberos itself has evolved to accommodate such augmentations.

With reference to Appendix A, the smart card is programmed to be an encryption service provider for the encryption of Kerberos authenticators and the decryption of Kerberos KAS/TGS responses. It implements the DES CBC mode, performing an encryption or decryption operation on 8 byte blocks of data using a DES key and an initialization vector. The software architecture of the smart card consists of the operating system, I/O routines, interface routines, the control application, and DES algorithm. The operating system and I/O routines are provided in the smart card development system. Assembler interface routines were modified to allow Archimedes version 4.0 C-8051 to make calls to the operating system to read messages into the smart card, write messages out of the smart card, and write bytes to EEPROM. Both the control application and the DES algorithm are written in C.

The control application implements the control protocol to communicate with client Kerberos and performs the requested encryption service on the input data. There are two additional functions in support of the encryption service: decrypting the user key for decryption of the first KAS message and downloading a session key for encryption of authenticators. The control protocol has been implemented such that each request message sent to or from the smart card has a corresponding response message (acknowledgment) returned before another message may be sent. This serves to keep the client Kerberos and the smart card message exchanges tightly coupled and helped in smart card software debugging. There are some smart card initialization procedures regarding card reset, card login, and execution of the control application. Once the smart card control application is running, all messages sent to the smart card are delivered to the control application.

In support of KAS/TGS response decryption, the following operations are performed. To process the initial KAS response, it is first necessary to decrypt the Kerberos user key (stored in encrypted form in EEPROM). To do this, client Kerberos sends a hash of the user password to the smart card to be used as a DES key. The smart card decrypts the user key using this hashed password key. Client Kerberos then sends the KAS response to the smart card, one block at a time in a Download Block message. The last block is sent in a Decrypt message, notifying the smart card to start the decryption process. The last block is sent in a Decrypt message, notifying the smart card to start the decryption process. The smart card assumes that the first response to be decrypted following initialization comes from the KAS. This response is encrypted in the user key and contains the TGS session key. Subsequent responses are assumed to come from the TGS. These responses are encrypted in the TGS session key and contain server session keys. Decrypted blocks are sent back in a Return message. The last decrypted block is sent back in an End message. All decrypted session keys are re-encrypted in the TGS session key before being sent back. The decrypted user key is destroyed after the first response is processed. Thereafter, the smart card uses the stored TGS session key for all decryptions.

For subsequent support of the TGS authenticator encryption, the following operations are performed. The appropriate session key is sent to the smart card in the Send Session Key message. The session key is decrypted with the TGS session key and stored in memory. Next, the TGS authenticator is sent down to the smart card one block at a time in a Download Block message. The last block is sent as an Encrypt message, notifying the smart card to start the encryption process. The TGS authenticator is then encrypted in the session key previously downloaded. As each block is encrypted, it is sent back to the client Kerberos in a Return message. The last block is sent in an End message.

Given that the smart card was not required to act as a bulk encryptor for message data streams, the implementation of the DES algorithm on the smart card was driven by memory constraints rather than encryption rate, with the understanding that higher encryption rates could be achieved by trading space for time. We chose a straightforward implementation of the DES algorithm as illustrated in Press, W. H., Flannery, B. P., Teulosky, S. A., and Vetterling, W. T., "Numerical Recipes: The Art of Scientific Computing," Cambridge University Press, Cambridge, UK, 1986, pp. 218-220. The DES algorithm is used for exemplary purposes only. One skilled in the art may substitute an alternate encryption algorithm.

While the Kerberos implementation is illustrated here, it should be clear to one trained in the art that the invention is not limited to Kerberos, but may also be used in conjunction with other authorization systems to provide a secure method to authenticate users. ##SPC1##