WO1999035783A1 - Client side public key authentication method and apparatus with short-lived certificates - Google Patents

Client side public key authentication method and apparatus with short-lived certificates Download PDF

Info

Publication number
WO1999035783A1
WO1999035783A1 PCT/US1999/000344 US9900344W WO9935783A1 WO 1999035783 A1 WO1999035783 A1 WO 1999035783A1 US 9900344 W US9900344 W US 9900344W WO 9935783 A1 WO9935783 A1 WO 9935783A1
Authority
WO
WIPO (PCT)
Prior art keywords
public key
user
computer
key
certificate
Prior art date
Application number
PCT/US1999/000344
Other languages
French (fr)
Inventor
Matthew Hur
Gennady Medvinsky
Joseph N. Kovara
Original Assignee
Cybersafe Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cybersafe Corporation filed Critical Cybersafe Corporation
Priority to AU24526/99A priority Critical patent/AU2452699A/en
Priority to KR1020007007557A priority patent/KR20010033972A/en
Priority to EP99904041A priority patent/EP1042885A1/en
Priority to JP2000528045A priority patent/JP2002501218A/en
Priority to CA002313328A priority patent/CA2313328A1/en
Publication of WO1999035783A1 publication Critical patent/WO1999035783A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/33User authentication using certificates
    • G06F21/335User authentication using certificates for accessing specific resources, e.g. using Kerberos tickets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2211/00Indexing scheme relating to details of data-processing equipment not covered by groups G06F3/00 - G06F13/00
    • G06F2211/007Encryption, En-/decode, En-/decipher, En-/decypher, Scramble, (De-)compress
    • G06F2211/008Public Key, Asymmetric Key, Asymmetric Encryption

Definitions

  • kerberos refers to kerberos and any trusted third party system that shares symmetric keys with users and services.
  • a kerberos-like system has been found highly useful in a number of situations, it is believed that previous kerberos-type systems typically have not been deployed so as to provide advantages associated with public key systems (such as, e.g. , digital signatures).
  • public key (PK) system two corresponding (“asymmetric")keys are used in connection with protecting information. Information which is encrypted with one of the two keys can be decrypted only with the other key.
  • certificate lifetime policies will be set so as to provide certificates with lifetimes sufficiently short that checking against CRL's can be reduced or eliminated without significantly diminishing overall security. Accordingly, each time the system generates (or re-signs) a certificate for this user (i.e. a certificate containing the user's public key) the certificate will have a different expiration time. Typically, a new certificate (based on identical public key) will generate only after the expiration of the previous certificate, although other protocols could also be used. Thus, the result of the present system will typically be issuance of a series or sequence of certificates for any given user (typically on a daily or workday basis) but in which the certificates for this user are not completely identical, i.e.
  • the smartcard image is encrypted, for example with a private key.
  • the simulated smartcard client 714 will then decrypt the smartcard image.
  • the decrypted image may contain, e.g., public keys, private keys, symmetric keys, certificates and similar information. Some or all of the information (preferably including especially sensitive information such as a private key) may be encrypted under a password known only to the end user.
  • blocks shown underneath the client application 514 are items which are client side items, i.e. which use or constitute software residing, typically, on a PC or other computer used by an end user, while items on the right side of the figure represent server-side items i.e.
  • FIG. 8A and 8B provide two (of many) possible examples of such further operation.
  • the client application 514 may, e.g., generate or store public key credentials 814 (typically using standard cryptographic API's 512).
  • public key credentials are, in the embodiment of Fig. 8 A, handled in a fashion which is transparent to the client application 514.
  • the simulated smartcard client 714 will send a message 816 to the simulated smartcard server 726 to update the simulated smartcard image on the server side.
  • An initial password is generated for a new user and stored on the security server 718 (or a storage device couple therewith) preferably resetting the password 722 such that after the user preforms an initial log on, the password will be flagged as being in an expired state (thus forcing the user to change the password).

Abstract

An authentication system with an ability to effectively implement a system for providing short-lived certificates is described. A key distribution center (KDC) (116) generates and stores public private key pairs and certificate templates. A user is assigned a user public private key pair which is stored in the KDC (116). A user (114) who authenticates to the KDC (e.g. using a password according to, e.g., a kerberos system) prompts the system to recertify the user's public key by generating and signing a short-lived certificate.

Description

CLIENT SIDE PUBLIC KEY AUTHENTICATION METHOD AND APPARATUS WITH SHORT-LIVED CERTIFICATES
The present invention is directed to a public key authentication system and, in particular, to a system making it practical to implement client side public key authentication.
BACKGROUND INFORMATION One of the earliest information security systems was the development of ciphers and systems of encryption and decryption for the purpose of assuring privacy (protecting information from unauthorized readers). More recently, and especially with the introduction of electronic communication and computer-based information systems, information security systems have also been used for other purposes such as authentication (assuring that a message truly originated at its purported origin) and authorization (preventing access to hardware, software or data by unauthorized persons). The present invention, although having applicability or relationships in many areas of information security, is most apparently directed toward client side public key authentication. Typically, after authentication has occurred, the authentication can form a basis for later decisions, such as making access control decisions.
Many security systems are fundamentally related to systems of data encryption. The relationship of encryption to information privacy is apparent, although systems for encrypting and decrypting data have developed to include many elaborate schemes. Encryption can be related to identification and authentication in a number of ways. Most apparently, if the receiver of an encrypted message trusts that only one other person possesses the key by which the message was encrypted, then identification and, to some extent, authentication, is achieved upon successful decryption. By using encryption for authentication purposes, its role in access control is apparent since control to a resource can be predicated upon authentication of the person seeking access. In a password-based authentication system, encryption may play a role in avoiding disclosure of passwords to unauthorized parties (such as by encrypting passwords before they are transmitted or stored, or transforming the password into a symmetric key and using it in an encryption based protocol to authenticate the user). Encryption systems are often categorized into secret key ("symmetric key") systems and public key ("asymmetric key") systems (sometime called a public-key private-key system), although there are other systems, as well. In a typical secret or symmetric key system, the same key is used for both encrypting and decrypting. In this system, it is important to maintain secrecy of the key, (albeit a shared secret) e.g. , such that only authorized persons have knowledge or possession of the shared secret key. Thus, one of the difficulties with the secret key system is mamtaining key secrecy. Another problem is key proliferation. If a party wishes to have private communication with two or more other parties but does not necessarily wish all parties to have access to all such communications, it will, in general, be necessary to have a different secret key shared between each pair of persons. Maintaining and distributing such keys becomes unwieldy in large organizations. One approach is to establish a trusted third party (TTP) in such a fashion that would require each party to have only a single key: that between himself and the TTP, with the TTP acting as an intermediary to establish any particular desired communication channel. This system, while useful for many purposes, presents difficult problems of how to assure security of the TTP itself and maintaining the host's key secret. One implementation of a TTP which has achieved some degree of success is that generally known as kerberos, described more thoroughly below. In general, a "kerberos-like system," as used herein, refers to kerberos and any trusted third party system that shares symmetric keys with users and services. Although a kerberos-like system has been found highly useful in a number of situations, it is believed that previous kerberos-type systems typically have not been deployed so as to provide advantages associated with public key systems (such as, e.g. , digital signatures). In a public key (PK) system, two corresponding ("asymmetric")keys are used in connection with protecting information. Information which is encrypted with one of the two keys can be decrypted only with the other key. In some public key systems, either of the two keys can be used to encrypt and the other key to decrypt. In other systems, one key must be used only for encryption and the other only for decryption. One important feature of public key systems is that it is computationally infeasible to use knowledge of one of the keys to deduce the other key. In a typical public key system, each user of the system possesses a set of two such keys. One of the keys is maintained private while the other is freely published. If a sender encrypts a message with the recipient's public key, only the intended recipient can decrypt the message (since only the recipient is in possession of the private key corresponding to the published public key). If the sender, before performing the above encryption, first encrypts the message with the sender's private key, the recipient, upon performing first a decryption (using the recipient's private key), then a decryption on the result (using the sender's public key) is assured not only of privacy but of authentication since only the sender could have encrypted a message such that the sender's public key successfully decrypts it. In one digital signature scheme, a one-way hash is first applied to a message and the hash of the message is encrypted with the sender's private key.
In this scenario, the degree of confidence that the recipient has in the source of the message depends on the degree of the recipient's confidence that the sender's public key corresponds to a private key that was possessed only by the sender. In many current systems, a number of generally well-trusted certification authorities have been established to provide this degree of confidence. In the system currently in widest use, these authorities provide public key certificates. Under the most widely used certificate standard (Standard X.509 developed by the International Standards Organization (ISO) and the Comitέ Consultatif Internationale Telegraphique et Telephonique (CCITT)), such certificates include a public key, the name of the person who possesses or is associated with the public key, and other information which may, e.g., include an expiration date, all of which are digitally signed by a trusted party (and are thus in encrypted or otherwise modified form). The digital signature may be provided, e.g., according to the digital signature standard (DSS) (National Institute of Standards and
Technology (NISD)). Typically, a digital signature involves applying a one-way hash and then encrypting with the private key of, in this case, the certification authority. Such digital signature is provided using the private key of the trusted party which, in turn, is authenticated using the trusted party's certificate signed by yet another trusted party, so that there may be a multi-level hierarchy of trusted parties. Although public key systems are used in a number of situations, including certain Internet browsing situations, experience has shown that public key systems can have their own difficulties. To provide an acceptable level of security, the key which a user maintains secret is not feasible to remember (typically being a large number such as a 1024-bit binary number) and thus, to be practical, must be stored, making it vulnerable to breach of security and, in many systems, requiring use of a particular piece of hardware (e.g., a Smartcard or, in some cases, a particular computer).
In one previous system, a Smartcard formed part of an authentication system. A number of Smartcard systems and uses are known. For example, the Secure Socket Layer (SSL) protocol requires a digital signature for a client application to establish communication with certain services. In some environments, a Smartcard will hold information used to provide such a digital signature, so that users can access such resources if they possess an appropriate Smartcard (and without the need to, e.g. memorize a key). Other Smartcard authentication procedures using public and private key pairs are also known. The principle Smartcard interfaces currently in use are
PKCS #11 (Public Key Cryptography Standard, RSA Data Security, Inc.) and PC/SC (Personal Computer/Smartcard).
As noted above, a certificate is typically provided with an expiration date. Such expiration dates typically are on the order of a year or more from issuance, thus making certificates, in current systems, relatively long-lived. There are number of reasons for this. One of the features that makes a public key system attractive is its ease of use, and it would be counter to this goal if users had to obtain key pairs and publish new public keys on a very frequent basis. Nevertheless, in some circumstances, it is desirable to revoke a previously published certificate. For example, a public key pair which is used to control an employee's access to sensitive company information might be revoked when the employee leaves the company. Accordingly, previous public key systems have typically come to rely on checking certificates against a certificate revocation list (CRL). The X.509 standard provides an example of CRL representation. Unfortunately, this requires distribution, e.g. intranet- or Internet-wide distribution, of CRLs, and requires an additional checking or comparison step. These items can be burdensome or even render the system infeasible in relatively large enterprises or networks.
Another difficulty associated with public key systems is distribution and management of the private keys. For example, as a company hires new employees, it may want to provide some employees with public-private key pairs, but it becomes problematic to distribute the private keys in such a manner as to avoid revealing the private keys to other parties. Although employees' private keys should remain private if they are to serve the intended purpose, there are circumstances where a company may need to access such keys (e.g. to obtain company-owned information which was encrypted by a now-deceased employee). However, maintaining a employees' keys, e.g., in escrow would typically involve substantial management effort and expense.
Accordingly, it would be useful to provide a system in which public key technology can be used, e.g., for securing computer networks while reducing or eliminating the burden of the CRL-checking system, without compromising security (e.g., form departed employees or others who, under a conventional system, would have their certificates revoked). It would also be useful to provide a system which reduces or eliminates the effort and expense associated with private key distribution and management. It would further be useful to provide a public key system in which the goal of private key storage can be achieved while reducing or eliminating the hardware- dependence and/or security risks associated with previous systems.
Additionally, it would be useful to provide such an improved public key system while taking advantage of features of already-used systems to minimize the amount of development, programming and changes to current systems in order to implement such features.
SUMMARY OF THE INVENTION The present invention provides a system for automatically generating short-lived public key certificates (PKC), i.e. with a validity period less than 1 month preferably less than 1 week, more preferably less than 1 day and even more preferably less than about 12 hours, e.g., for session-oriented authentication or other security purposes, such as authorization. In one embodiment, each time a user authenticates using a first authentication system (e.g., every time a user logs onto the system and authenticates him or herself), a new but short-lived PKC will be generated and delivered to the user. It is anticipated that typically, the public key will be re-certified relatively frequently (e.g. every 8 hours, every workday, etc.); the public-private key pair itself remains unchanged, and is relatively long-lived (e.g. with a lifetime of about 1 year or more).
This newly generated PKC can then be used in a fashion similar to that for which PKCs were used in previous systems, including systems for controlling access to resources such as web pages or other resources.
In one embodiment, the system not only delivers the short-lived PKC but also delivers the private key corresponding to the PKC s public key. This relieves the user from having to be responsible for storing a public key or from being restricted to using particular hardware on which the private key is stored (although such a hardware-based approach could be used if preferred). Because the PKC is short-lived, it is possible to achieve a relatively high degree of trust without the need (or with a reduced need) for processing CRLs. In the case of, for example, a departed employee, the system will be configured to refuse to issue any more (short-lived) certificates for such employees and because previously-valid issued certificates will have expired (or will shortly expire), checking against a CRL is unnecessary.
In one embodiment, since both the private key and public key are returned to the computer of the person seeking access, it is possible, if desired, to implement a simulated Smartcard in which the private key and public key, cached locally in the computer of the person seeking access, are used to simulate the presence of a physical Smartcard. For example, in connection with a PKCS #11 interface, the simulation can take the form of fijlfffling Smart API Calls such as, e.g., C-SIGN, C-VERIFY. In this way, the present invention can take advantage of relatively mature application prograinming interfaces (APIs) for Smartcards to implement a public key-based, client side authentication, without the need for actual Smartcard hardware (such as without the need for users to obtain and carry actual Smartcards).
In one embodiment, a TTP system which may be, for example, similar to a kerberos system, can be adapted for use as the short-lived certificate generating system.
Such a system combines some of the advantages of a kerberos-type system, such as being password based and tolerant of users who log on at different computers ("roving users") with certain advantages of a public key system (such as facilitating access to resources which are protected via a public key infrastructure or system) while avoiding the above-noted difficulties with public key systems, such as private key distribution and management difficulties, the need for maintaining and using CRLs and storing private keys in relatively insecure or inconvenient fashions.
BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a schematic block diagram of a kerberos-type system according to previous procedures;
Fig. 2 is a flowchart of a public key/Smartcard authentication system according to previous systems;
Fig. 3 is a flow chart depicting certificate generation and use according to an embodiment of the present invention; Fig. 4 is a block diagram of certain components of a system illustrating use of the procedure of Fig. 3;
Fig. 5 is a block diagram of a system for use with a simulated smartcard and/or a hardware smartcard, according to an embodiment of the present invention;
Fig. 6 is a block diagram of a system for use with a simulated smartcard and/or a hardware smartcard, according to an embodiment of the present invention;
Fig. 7 is a block diagram illustrating a system for logging in to a simulated smartcard, according to an embodiment of the present invention;
Fig. 8A and 8B are block diagrams illustrating examples of how a system according to the present invention can provide support for third-party Public Key Infrastructures (PKI); and
Fig. 9 is a block diagram illustrating user enrollment in the context of a simulated smartcard system, according to an embodiment of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Before describing features of embodiments of the present invention, certain features of previous systems will first be described. Fig. 1 depicts an authentication procedure using a kerberos system. Although the kerberos system uses a password for authentication, the system is particularly secure because it never transmits passwords, either encrypted or unencrypted, over the network. In the depicted embodiment the system can provide a number of different services, including a ticket-granting service (described below) and various other services that may be desired by the user. In the depicted embodiment, the person who desires to use a particular resource or service 112 (which may be, for example, a software service such as a particular application program, may be data, may be a particular hardware resource or combination thereof) attempts to log onto the system, entering (usually in response to a prompt) a password known only to the person being authenticated. Preferably, for a typical user session, this is the only time the user will need this password during a (normal-length, e.g. 8-10 hour) session (although, if desired the system can be configured to require re-input of the password to perform certain tasks, such as administration tasks on the security system). The person makes the log-on attempt using a client computer 114 coupled, e.g. , via a local area network (LAN) or other communication system to a key distribution center (KDC) 116. In response, the client 114 sends a request message (AS-REQ) 118 to the KDC. The request 118 indicates the name of the person requesting the service but does not include the password. The KDC 116 responds 122 with an encrypted "ticket granting ticket" (TGT) (AS-REP). The ticket granting ticket includes two main components: a ticket for the client to use the ticket granting service
(the majority of which, including the session key, is encrypted with the key of the ticket granting service) and a session key for the client and ticket granting service, encrypted with the client key. When the user wishes to begin using a particular service 112, an additional transaction with the KDC is needed. The client computer 114 transmits a ticket request 124 (TGS-REQ) to the KDC 116. The request includes a number of components including an authenticator (generated by the client) for the client to use the service, encrypted with the session key(the session key is sealed in the TGT); the ticket for a client to use the ticket granting service, the majority of which is encrypted with the key of the ticket granting service (both of which were included in the ticket granting ticket 122) and the name of the service 112. In response, the key distribution center 116 transmits to the client a ticket 126 (TGS-REP) (the majority of which is encrypted) which contains a ticket for the client to use the server, at least partially encrypted with the server's key, and a copy of the session key, encrypted with the session key that is shared between the client and the ticket granting server. At this point, the client now has sufficient items to gain access to the service 112 as desired. This is achieved by transmitting from the client to the service 112 a message containing an authenticator and a ticket. In response, the service provides the desired server response to the client. The service 112 can treat the ticket as authentic because only the KDC and the service 112 share the secret key with which the ticket is encrypted. As depicted in Fig. 2, a public key system operates in a substantially different form. Typically a user generates a public-private key pair 202. The user stores the private key 204 in any of a number of fashions, such as in a file on a client computer or on a Smartcard. Such storage in previous systems is believed to raise difficulties. Storing in a file located on a particular computer impairs "roving users" since the user can only use or access his stored private key on the particular computer where it was stored. That is, the system is inconvenient or infeasible for users who need or desire the ability to log onto any of a plurality of different computers (e.g., any of a plurality of nodes in a local area network or other network) and still be able to use a public key system-controlled resource. It is further believed that storing private keys in a file on a computer, even if protected by encryption or other measures, represents a security vulnerability of the system. Storage of a private key on a Smartcard is at least theoretically compatible with roving users but in many situations is infeasible because of the cost and administrative overhead involved in equipping a plurality of machines with Smartcard readers and distributing Smartcards to various users.
The user submits the public key for certification to a trusted entity such as a certification authority (CA), e.g. via a PKCS #10 request. Upon verifying the requestor's identity (out of band) the CA issues an X.509 certificate to certify the user's public key 212. The certificate is then sent back to the user and typically will be publicly available, such as by publication in a directory such as an X.500 or LDAP (Lightweight Directory Access Protocol) directory, both well-know to those of skill in the art. The CA also periodically issues certificate revocation lists (CRL's) 214 as described above. One mechanism for distributing CRL's is via LDAP. In certain previous systems, a user wishing to access a resource would retrieve the private key (typically in an automatic fashion) 218. Using any of a number of systems known in the art for public key system based authentication, a resource control device will verify, using e.g. the user's public key (certified by the CA) that the user has been properly and correctly identified 222. Because of the long lifetime of certificates in previous systems, the resource control device will then perform a comparison with the CRL in order to determine whether the certificate has been revoked 224. As noted above, the comparison 224 represents an additional step in the process of controlling access. Additionally, there is an administrative cost in producing, distributing, storing and otherwise tracking CRLs, particularly when CRLs are promulgated with sufficient frequency to detect use of even recently-revoked certificates.
In order to address these and other problems, in previous systems, one embodiment uses a certificate generation system as depicted in Fig. 3. Although, as will be apparent to those of skill in the art after understanding the present disclosure, a number of different systems could be used for generating certificates, in one embodiment a modified kerberos-like system is used. In the embodiment depicted in Fig. 3, one of the components of the modified kerberos-like system is a key distribution center (KDC) 416 (Fig. 4). The key distribution center 416 can be similar to that described in connection with Fig. 1 but modified (e.g. provided with different software) for the procedure described below. In the system and procedure of Fig. 3, initially (e.g. at installation time), the KDC 416 will generate a public-private key pair 312. The system will also generate a certificate template (such as an X.509 certificate) 314. The KDC 416 will then use the KDC's private key to sign the template. These steps 312, 314, 316 are substantially similar to procedures followed by root certification authorities (but not, typically, by network servers or KDC's) in previous systems. When a user registers, the client administration will generate a long-lived public-private key pair associated with that particular user and will store 318 the key pair in the KDC 416, associated with an identifier of the user. When the user begins a session, such as by logging on to a network, the user will enter a password, causing the client 114 to send 322 an AS-REQ message 118 to the KDC 416, as described previously in connection with Fig. 1. In the embodiment of Figs. 3 and 4, in response to the AS-REQ 118, the system will re-certify the user's public key. Specifically, the system will generate and sign an X.509 certificate for the user 324. Thus, whereas in previous public key systems, a CA would generate and publish a certificate once (upon initial issuance) according to the system of Figs. 3 and 4, the system will generate a certificate containing the user's public key multiple times, typically, each time the user logs on to the system resulting, over time, in a sequence of certificates for this user.
An additional difference between the present system and typical public key systems is that the certificate is short-lived, i.e., contains an expiration time/date which is significantly less than the one- to two-year (or longer) certificate expiration date in previous public key systems, preferably expiring in less than six months, or preferably less than a month, more preferably less than a week, even more preferably less than 24 hours, and yet more preferably expiring less than 12 and preferably around 8-10 hours after issuance. It is anticipated that the expiration date of such short-lived certificates will vary with the needs of the company or other enterprise implementing such systems, and preferably one or more normal or default lifetimes for certificates can be established, e.g. by a system administrator (following proper authentication). It is anticipated that certificate lifetime policies will be set so as to provide certificates with lifetimes sufficiently short that checking against CRL's can be reduced or eliminated without significantly diminishing overall security. Accordingly, each time the system generates (or re-signs) a certificate for this user (i.e. a certificate containing the user's public key) the certificate will have a different expiration time. Typically, a new certificate (based on identical public key) will generate only after the expiration of the previous certificate, although other protocols could also be used. Thus, the result of the present system will typically be issuance of a series or sequence of certificates for any given user (typically on a daily or workday basis) but in which the certificates for this user are not completely identical, i.e. will differ from one another with regard to the expiration time-date (but, for a given user, will have identical public keys). This is in contrast with previous public key systems in which a certificate, once it was issued, was not thereafter issued again for the same public key in a different form or with different information (specifically with different expiration time/date). In one embodiment, other data may be added to or modified in the series of shortlived certificates for a user. For example, data indicating which resources a given user is authorized to use (or other authorization data) can be included in the short-lived certificates. One example of such authorization information is information indicating one or more user groups with which a user is affiliated, e.g. whose members are authorized to use certain resources. It is believed inclusion of such authorization data, which typically may change on a relatively short time frame, (e.g. days or weeks) would not have been appropriate for inclusion in (and, it is believed, was not included in) previous (long- lived) certificates, but is feasible for inclusion in short-lived certificates according to embodiments of the present invention.
After generation of the certificate, the system will then transmit or deliver 326 the certificate 422 to the client 144. In one possible embodiment, the delivery is made as part of the (modified) AS-REP response, analogous to that described above in connection with Fig. 1. After the user has logged on and has received the certificate 422, anytime during the valid lifetime of the certificate that the user wishes to authenticate to a resource, including a public key-controlled resource 418, the user can do so, e.g. using the certificate, typically without the need to enter the password again. After the short-lived certificate has expired, in order for the user to authenticate to a resource, the user will need to repeat the procedure described above in order to obtain another short-lived certificate, thus typically requiring re-entering the password.
Preferably, the system delivers not only the certificate, but also the private key of the user 328 (i.e. which corresponds to the public key on which the certificate is based), preferably protected by a shared secret such as a session key generated by the kerberos- like system. In this way, the user is able to retrieve the private key for use as described in Fig. 2 (218) but without having to store the private key in a file on the client computer 114 (where, as noted above, it may be relatively vulnerable). Additionally, by providing a central location for storing users' private keys, central administration of private keys (and implementation of key policies) is made feasible, in contrast to previous PK systems, which were typically based on a paradigm of private keys being widely distributed (i.e. individually stored by individual users). Moreover, since, according to the present system, a user can use any of a plurality of computers to log onto the system using his or her password, this system supports roving users, but without the requirement for a physical Smartcard. The client computer 114, being in possession of both the private key and the certificate, can access 332 a public key controlled resource 424. A public/private key pair may be used in connection with authenticating to a number of resources. As one example, an access control decision can be made based on an authentication process which involves use of a Smartcard, e.g. using a hardware Smartcard 516 in connection with a Smartcard interface 518 such as a PKCS #11 application programming interface 512 (Figs. 5 and 6). However, the present invention affords an additional opportunity. According to the embodiment generally illustrated in
Fig. 5, it is possible to provide a simulated Smartcard/Smartcard interface in place of, or, as illustrated, in addition to, the hardware Smartcard 516 and interface 518. From the perspective of the application 514 (such as, for example, a browser 517) and API 512, there will be no difference between a simulated Smartcard/Smartcard interface 522 and the hardware Smartcard/interface 516, 518. When a user is logging into the card (e.g. using the C-LOGIN call in the PKCS #11 API), the user's password will be used to authenticate to the KDC 416 and retrieve the private key and a freshly generated X.509 certificate 422. These credentials are then cached locally 524 (or remotely). From the cache 524 the credentials may be used to fulfill Smartcard API calls (e.g. C-SIGN, C- VERIFY). The approach of Figs. 5 and 6 permits transparent access to an application 514 via a PKCS #11 API, i.e. using a relatively mature API but without the cost and administrative overhead associated with hardware Smartcards.
As illustrated in Fig. 7, in one example, a process for logging in to a simulated smartcard may begin when a client application 514 uses a standard API such as PKCS #11, MS-CAPL CDSA and the like, to initiate log on of user into a smartcard. Preferably the process of the present invention is transparent to the client application 514 in the sense that the messages and/or data sent from and received by the client application during the process will be the same regardless of whether the client application 514 is logging on to the simulated smartcard as depicted in Fig. 7 or logs on to a physical smartcard. The particular interface 512 which is used will typically depend on what client application 514 is performing the login (e.g. it is likely a Microsoft® would use an MS-CAPI interface while other browsers or applications might use PKCS #11 or other interfaces 712). In the illustrated embodiment, the simulated smartcard client 714 (implemented with software typically residing on a client side computer) will authenticate to 716 a security server 718, typically an authentication service such as a Kerberos-like authentication service. Typically, the simulated smartcard client 714 will request a password and/or login name from the user before formulating and sending an authentication request 716. The security server 718 responds by sending 722 authentication credentials to the simulated smartcard client 714. The authentication credentials which are sent 722 may include those described above in connection with the embodiments of the present invention and/or previous systems. However, preferably the information sent 722 is sufficient to permit the simulated smartcard client 714 to send a message 724 to a simulated smartcard server 726 sufficient to authenticate to the simulated smartcard server. Typically the information 722 sent to the simulated smartcard client 714 will include a ticket (generally as described above) for the smartcard service. In response to receipt of an authenticated request 724, the simulated smartcard server 726 returns a (preferably encrypted) smartcard image 728.
As used herein, the "smartcard image" includes at least some information which, in a physical smartcard system, would be stored on or derived from a physical smartcard.
Examples include public keys, private keys, symmetric keys, certificates and the like. In one embodiment, the smartcard image is encrypted, for example with a private key. The simulated smartcard client 714 will then decrypt the smartcard image. The decrypted image may contain, e.g., public keys, private keys, symmetric keys, certificates and similar information. Some or all of the information (preferably including especially sensitive information such as a private key) may be encrypted under a password known only to the end user. In general, in Fig. 7 through 8, blocks shown underneath the client application 514 are items which are client side items, i.e. which use or constitute software residing, typically, on a PC or other computer used by an end user, while items on the right side of the figure represent server-side items i.e. which use or constitute software residing at remote locations such as remotely located network servers. Although, in the embodiment depicted in Fig. 7, a security server 718 and simulated smartcard server 726 are shown as separate blocks, it is also possible to configure a system in which one or more of the components depicted as separate blocks are, in fact on a single server computer, e.g. in which the security server 718 and simulated smartcard server 726 are located on a single server computer. It is possible, in this situation, to combine steps 2, 3 and 4 so that the simulated smartcard client 714 sends an authentication request 716 to the security server/simulated smartcard server which responds by sending a (preferably encrypted) smartcard image 728 back to the simulated smartcard client 714.
After receiving the smartcard image, the smartcard client 714 will then check for expired public key certificates on the (decrypted) smartcard image. If an expired certificate is found, the simulated smartcard client 714 will submit a re-certification request 732 to a server-side certification authority 734. Typically certifications returned to the simulated smartcard client 714 will be short-lived certificates generally as described above. The simulated smartcard client 714 will then use the objects on the smartcard image to fulfil cryptographic operations provided by the cryptographic API's 512 responding 736 to the client application 514 in a manner substantially identical to the manner of response that would have been provided had a physical smartcard system been used.
After a simulated smartcard login as depicted in Fig. 7, further smartcard operations may be involved in executing the client application 514. Figs. 8A and 8B provide two (of many) possible examples of such further operation. In the example of Fig. 5 A, following login and download of the smartcard image 812 (performed generally as described above in connection with Fig. 7), the client application 514 may, e.g., generate or store public key credentials 814 (typically using standard cryptographic API's 512). Such public key credentials are, in the embodiment of Fig. 8 A, handled in a fashion which is transparent to the client application 514. In the depicted embodiment, the simulated smartcard client 714 will send a message 816 to the simulated smartcard server 726 to update the simulated smartcard image on the server side. This illustrates one fashion of incorporating a third party's credentials in the system of the present invention and accordingly providing support for third party certification authorities.
Fig. 8B provides another example. In the embodiment of Fig. 5 A the client application 514 communicates with a third party certification authority 822, 824 which is neither on a client machine nor a server of the present security system. For example, the client application 514 may contact a third party certification authority to get certified. However, after such communication 822, when the client 514 sends a message 814' for smartcard storage, the present system provides for simulated smartcard storage, in a manner similar to that described above in connection with Fig. 8A, by sending the information 816' prime to the simulated smartcard server 726 for storage.
Fig. 9 illustrates use of the system, according to an embodiment of the present invention, for enrolling new users in the simulated smartcard system. In the embodiment of Fig. 9, an administrator, e.g. using an administrator server 912, prepares a certificate template (preferably assisted by software for generating such templates) which is sent for storage 914 on a simulated smartcard server 726 (or a storage device 916 associated therewith). The template specifies at least some of the components of the certificate for use in the system. Typically, the template will contain, e.g., the user's distinguished name, the issuer's distinguished name and the like. An initial password is generated for a new user and stored on the security server 718 (or a storage device couple therewith) preferably resetting the password 722 such that after the user preforms an initial log on, the password will be flagged as being in an expired state (thus forcing the user to change the password).
The generation of a new public-private key pair for the user could be performed either on the client side computer 714 or on a server (e.g. 912). Client side key generation might be used when it is desired to reduce the computing load on server computers. However, particularly in situations where many users are being added at one time, it may be useful to generate the new pairs on the server side 912 to facilitate setting up the system to accommodate a number of new users. The passwords discussed above are distributed to the various users. Preferably this is done out-of-band (without transmitting the password over the computer network, such as by providing the password in a personal meeting, over the telephone and the like). As each new user logs into the system for the first time 922, the user preferably will be required to change his or her password (as described above). If the key pair was not previously generated on the server side, the simulated smartcard client 714 will generate the key pair. The smartcard image is then downloaded to the client, e.g. using a procedure 812 similar to that described above. The keys are then generated and written back to the smartcard image on the server side, e.g. using a procedure 816 similar to that described above in connection with Fig. 8A.
In light of the above description, a number of advantages of the present invention can be seen. The present invention provides a turnkey solution making public key authentication feasible. In one embodiment, the present invention employs a symmetric key authentication to enable use of an application which may be protected by an asymmetric key system. The present invention makes it practical to implement client side public key authentication by solving the private key management and certificate revocation problems. The invention provides for public key authentication without the need for (or with reduced need for) CRLs and/or without the need for client-stored or smartcard- stored private keys. The present invention provides for relatively frequent public key recertification (e.g. every work day) without the need for frequent regeneration of new key pairs, which is a computationally expensive operation. The present invention can be implemented using (in modified fashion) certain previous systems or standards such as a modified kerberos and/or PKCS #11, MS-CAPI or CDSA implementations, thereby taking advantage of certain relatively mature or developed systems (or features of such systems) while avoiding certain disadvantages previously considered to be an unavoidable part of such systems. The present invention provides an opportunity to implement central administration of both a public key system and kerberos system to accommodate both types of uses. The present invention provides a single system which can both use or implement a public key system and act as a certification authority.
A number of variations and modifications of the present invention can also be used. Although the depicted and described embodiments employ a TTP system such as a kerberos-type system for generating and delivering short-lived certificates, other systems could also be used for generating and delivering short-lived certificates. It is possible to provide a system in which different facilities are used for generating and for delivering the certificates. It is possible to provide a system in which delivery of a short-lived certificate is not necessarily accompanied by delivery of a private key or a kerberos ticket.
It is, in general, possible to use some features of the invention without using others. For example, it is possible to provide a system which generates short-lived certificates without using a simulated Smartcard system or vice versa. Although it is anticipated that the short-lived certificates will be used in connection authentication, it is possible to use short-lived certificates in connection with other security measures, authorization, encryption or other privacy measures and the like. Although it is anticipated that the short-lived certificates will be used primarily in connection with session-oriented applications (such as Internet sites, browsers or servers controlled using a public key system), it is at least theoretically possible to use short-lived certificates in connection with other uses such as store and forward (e.g., secure electronic mail) uses. Although an example has been provided describing use of Smartcards or simulated Smartcards in connection with intranet or Internet browser access, Smartcards or simulated Smartcards can be used in connection with other items, such as electronic mail ("e-mail"). Although use of a KDC or other system for generating short-lived certificates has been described, it is possible to configure they system to issue moderate- life or (standard) long-lived certificates. Although certificate and/or private key delivery is described as occurring as part of a kerberos AS-REP message, it is possible to provide for delivery separately from the AS-REP message. If desired, the system can be configured to deliver only private key and certificates to the client (i.e. without delivering ticket granting tickets or other tickets), or the system may be configured to allow the user to specify whether delivery of both public key credentials and kerberos tickets, and/or both certificate and private key is needed or desired. Although the invention has been described by way of a preferred embodiment and certain variations and modifications, other variations and modifications can also be used, the invention being defined by the following claims.

Claims

What is claimed is:
1. A computer-implemented method for issuing public key certificates for a user in a network which includes at least a first client computer coupled, by said network to at least a first key distribution computer configured to output tickets according to a ticket protocol, the method comprising: storing, in a memory accessible to said key distribution computer, at least a public key of said user; receiving in said client computer at least a first password of said user; verifying validity of said password in said client computer; transmitting from said client computer, over said network, to said key distribution computer, at least a first message which includes an indication of the identity of said user; transmitting at a first time, in response to said first message, from said key distribution computer, over said network, to said client computer, both a ticket according to said ticket protocol and a short-lived public key certificate containing said public key of said user.
2. A computer-implemented method as claimed in claim 1 wherein said ticket protocol is a kerberos protocol.
3. A computer-implemented method as claimed in claim 1 further comprising transmitting, in response to said first message, from said key distribution computer, over said network, to said client computer, a private key of said user corresponding to said public key of said user.
4. A computer-implemented method as claimed in claim 1 wherein said shortlived public key certificate has an expiration time less than about one week after said first time.
5. A computer-implemented method as claimed in claim 1 wherein said shortlived public key certificate has an expiration time less than about 12 hours after said first time.
6. A computer-implemented method as claimed in claim 1 further comprising using said short-lived public key certificate to provide authentication of said user.
7. A computer-implemented method as claimed in claim 1 further comprising using said short-lived public key certificate for authorizing said user to use a resource which is controlled by a public key system.
8. A computer-implemented method as claimed in claim 1 wherein said public key certificate is an X.509 certificate.
9. Apparatus for issuing public key certificates for a user in a network, the network including at least a first client computer coupled, by said network to at least a first key distribution computer configured to output tickets according to a ticket protocol, the apparatus comprising: a memory, accessible to said key distribution computer, for storing at least a public key of said user; said client computer and said key distribution computer being programmed to receive, in said client computer, at least a first password of said user; verify validity of said password in said client computer; transmit from said client computer, over said network, to said key distribution computer, at least a first message which includes an indication of the identity of said user; transmit, at a first time, in response to said first message, from said key distribution computer, over said network, to said client computer, both a ticket according to said ticket protocol and a short-lived public key certificate containing said public key of said user.
10. An apparatus, as claimed in claim 9 wherein said ticket protocol is a kerberos protocol.
11. Apparatus as claimed in claim 9, said key distribution computer configured to further transmit, in response to said first message, from said key distribution computer, over said network, to said client computer, a private key of said user corresponding to said public key of said user.
12. Apparatus as claimed in claim 9 wherein said short-lived public key certificate has an expiration time less than about one week after said first time.
13. Apparatus as claimed in claim 9 wherein said short-lived public key certificate has an expiration time less than about 12 hours after said first time.
14. Apparatus as claimed in claim 9 further comprising using said short-lived public key certificate to provide authentication of said user.
15. Apparatus as claimed in claim 9 further comprising using said short-lived public key certificate for authorizing said user to use a resource which is controlled by a public key system.
16. Apparatus, as claimed in claim 9 wherein said public key certificate is an X.509 certificate.
17. Apparatus for issuing public key certificates for a user in a network which includes at least a first client computer coupled, by said network to at least a first key distribution computer configured to output tickets according to a ticket protocol, the method comprising: memory means, accessible to said key distribution computer, for storing at least a public key of said user; means, coupled to said client computer, for receiving at least a first password of said user; means, in said client computer, for verifying validity of said password; means, coupled to said client computer, for transmitting from said client computer, over said network, to said key distribution computer, at least a first message which includes an indication of the identity of said user; means, in said key distribution computer, for generating and transmitting at a first time, in response to said first message, from said key distribution computer, over said network, to said client computer, both a ticket according to said ticket protocol and a short-lived public key certificate containing said public key of said user.
18. Apparatus as claimed in claim 17 further comprising means for transmitting, in response to said first message, from said key distribution computer, over said network, to said client computer, a private key of said user corresponding to said public key of said user.
19. Apparatus, as claimed in claim 17, wherein said short-lived public key certificate has an expiration time less than about one week after said first time.
20. Apparatus, as claimed in claim 17 wherein said short-lived public key certificate has an expiration time less than about 12 hours after said first time.
21. Apparatus as claimed in claim 17 further comprising using said short-lived public key certificate to provide authentication of said user.
22. Apparatus as claimed in claim 17 further comprising using said short-lived public key certificate for authorizing said user to use a resource which is controlled by a public key system.
23. Apparatus as claimed in claim 17 wherein said public key certificate is an X.509 certificate.
24. A computer-implemented method for issuing public key certificates for a user comprising: storing, in a memory coupled to said computer, a plurality of public keys, including a public key associated with said user; receiving, in said computer, at a plurality of arbitrary times, messages which include an identification of said user; outputting, in response to each of at least a first plurality of said messages, a public key certificate for said user including an indication of said public key associated with said user and an indication of an expiration time for said certificate, wherein a sequence of public key certificates are output which have identical indication of public key but different and sequential expiration times.
25. A computer-implemented method as claimed in claim 24 wherein a private key of said user corresponding to said public key of said user is output substantially whenever said public key certificate is output.
26. A computer-implemented method as claimed in claim 24 wherein, each public key certificate in said sequence has a validity period extending from substantially when said certificate is output until, the expiration time of said public key certificate, and wherein each public key certificate in said sequence has a validity period of less than about one week so that said sequence of public key certificates is a sequence of short-lived certificates.
27. A computer- implemented method as claimed in claim 24 wherein each of said public key certificates in said sequence has a validity period of less than about one day.
28. A computer-implemented method as claimed in claim 24 wherein each of said public key certificates in said sequence has a validity period of less than about 12 hours.
29. Apparatus for issuing public key certificates for a user comprising: a memory coupled to a computer, for storing a plurality of public keys, including a public key associated with said user; said computer being programmed to have the capability of receiving, at a plurality of arbitrary times, messages which include an identification of said user; said computer being programmed to output, in response to each of at least a first plurality of said messages, a public key certificate for said user including an indication of said public key associated with said user and an indication of an expiration time for said certificate, wherein a sequence of public key certificates are output which have identical indication of public key but different and sequential expiration times.
30. Apparatus as claimed in claim 29 wherein said computer is programmed such that a private key of said user corresponding to said public key of said user is output substantially whenever said public key certificate is output.
31. Apparatus as claimed in claim 29 wherein each public key certificate in said sequence has a validity period extending from substantially when said certificate is output until, the expiration time of said public key certificate, and wherein each public key certificate in said sequence has a validity period of less than about one week so that said sequence of public key certificates is a sequence of short-lived certificates.
32. Apparatus as claimed in claim 29 wherein each of said public key certificates in said sequence has a validity period of less than about one day.
33. Apparatus as claimed in claim 29 wherein each of said public key certificates in said sequence has a validity period of less than about 12 hours.
34. Apparatus for issuing public key certificates for a user comprising: memory means, coupled to a computer, for storing a plurality of public keys, including a public key associated with said user; said computer being programmed to receive, at a plurality of arbitrary times, messages which include an identification of said user; said computer being programmed to output, in response to each of at least a first plurality of said messages, a public key certificate for said user including an indication of said public key associated with said user and an indication of an expiration time for said certificate, wherein a sequence of public key certificates are output which have identical indication of public key but different and sequential expiration times.
35. Apparatus as claimed in claim 34 further comprising means for outputting a private key of said user corresponding to said public key of said user substantially whenever said public key certificate is output.
36. Apparatus as claimed in claim 34 wherein, each public key certificate in said sequence has a validity period extending from substantially when said certificate is output until, the expiration time of said public key certificate, and wherein each public key certificate in said sequence has a validity period of less than about one week so that said sequence of public key certificates is a sequence of short-lived certificates.
37. A computer- implemented method as claimed in claim 36 wherein each of said public key certificates in said sequence has a validity period of less than about one day.
38. A computer-implemented method as claimed in claim 36 wherein each of said public key certificates in said sequence has a validity period of less than about 12 hours.
39. A computer-implemented method for issuing public key certificates for a user comprising: receiving, in said computer, a messages which include an identification of said user; outputting, in response to said step of receiving, a short-lived public key certificate.
40. Apparatus for issuing public key certificates for a user comprising: a computer programmed to receive messages which include an identification of said user and to output, in response to said messages, short-lived public key certificates.
41. Apparatus for issuing public key certificates for a user comprising: computer-implemented means for receiving messages which include an identification of said user; computer-implemented means for outputting short-lived public key certificates in response to receiving said messages.
42. In a computer-implemented authentication system configured to authenticate users in accordance with a first Smartcard protocol, a method for authenticating to a resource comprising: providing a public/private key pair of a first user; and using said key pair to simulate the response which a Smartcard generates in accordance with said Smartcard protocol.
43. A method as claimed in claim 42 wherein the public key of said public/private key pair is certified by an unexpired short-lived public key certificate of said user.
44. A computer-implemented public-key certification method comprising: obtaining a public-key and private-key pair; generating a series of public-key certificates for said public-key, with a frequency of at least two public-key certificates per year.
45. A method, as claimed in claim 44, wherein said frequency is at least about 12 public-key certificates per year.
46. A method, as claimed in claim 44, wherein said frequency is at least about five public-key certificates per week.
47. A method, as claimed in claim 44 wherein said public-key certificates include an expiration defining a certificate lifetime of less than about six months.
48. A method, as claimed in claim 44, wherein said public-key certificates include an expiration defining a certificate lifetime of less than about one week.
49. A method, as claimed in claim 44, wherein said public-key private-key pair has an expiration defining a public-key private-key lifetime of at least about one year.
50. A method, as claimed in claim 44, wherein said public-key private-key pair has an expiration defining a public-key private-key lifetime of less than about one day.
51. A method, as claimed in claim 50, wherein said public-key certificates include an expiration defining a certificate lifetime of less than about one day.
52. A method, for use in a computer system having at least one client computer and at least one server computer coupled by a communications link, the method comprising: storing in a memory coupled to said computer system, first information representing at least some data of a type normally stored on a smart card; using a kerberos-like system for password-based authentication of a user to said server; and retrieving said first information following said password-based authentication..
53. A method, as claimed in claim 52, further comprising using said first information to simulate use of a hardware Smartcard.
54. A method, as claimed in claim 52, wherein said first information includes at least one of a symmetric key, an asymmetric key pair, and a key certificate.
55. A method, as claimed in claim 44, wherein said public key certificates further include authorization information.
56. A method, as claimed in claim 55, wherein said authorization information includes group affiliation information.
57. A method, as claimed in claim 56, further comprising using said authorization information in a resource authorization system.
58. Apparatus for user authentication comprising : means for receiving a hardware Smartcard and using said received hardware
Smartcard to authenticate a user; and means for simulating a hardware Smartcard, in the absence of a hardware Smartcard, to authenticate a user.
59. A computer-implemented method for simulating logging in to a physical smartcard, comprising: prompting, by a client computer, for a password from a user in response to a client application login request; sending a message to at least a first server computer which includes a request identifying the user, in the absence of sending said password to said server computer; sending, from said server computer to said client computer, a smartcard image, at least partially encrypted; and sending a message to said client application to simulate a response from a physical smartcard, using at least some information from said smartcard image.
60. A method, as claimed in claim 59, wherein said smartcard image includes a public key certificate, and further comprising: determining if said public key certificate is expired; sending a certification request to a server computer when said public key certificate is expired.
61. A method, as claimed in claim 59, further comprising: transmitting information from said client computer to said first server computer for updating said smartcard image.
62. Apparatus for simulating logging in to a physical smart-card, comprising: means for prompting, by a client computer, for a password from a user in response to a client application login request; means for sending a message to at least a first server computer which includes a request identifying the user, in the absence of sending said password to said server computer; means for sending, from said server compuer to said client computer, a smartcard image, at least partially encrypted; and means for sending a message to said client application to simulate a response from a physical smartcard, using at least some information from said smartcard image.
63. Apparatus for simulating logging in to a physical smartcard in a network, the network including at least a first client computer coupled, by said network, to at least a first server computer, comprising: a memory, accessible to said server computer, for storing information representative of at least a first smartcard image; said client and server computers being programmed to prompt, by said client computer, for a password from a user in response to a client application login request; send a message to at least said first server computer which includes a request identifying the user, in the absence of sending said password to said server computer; send, from said server compuer to said client computer, a smartcard image, at least partially encrypted; and send a message to said client application to simulate a response from a physical smartcard, using at least some information from said smartcard image.
PCT/US1999/000344 1998-01-09 1999-01-06 Client side public key authentication method and apparatus with short-lived certificates WO1999035783A1 (en)

Priority Applications (5)

Application Number Priority Date Filing Date Title
AU24526/99A AU2452699A (en) 1998-01-09 1999-01-06 Client side public key authentication method and apparatus with short-lived certificates
KR1020007007557A KR20010033972A (en) 1998-01-09 1999-01-06 Client side public key authentication method and apparatus with short-lived certificates
EP99904041A EP1042885A1 (en) 1998-01-09 1999-01-06 Client side public key authentication method and apparatus with short-lived certificates
JP2000528045A JP2002501218A (en) 1998-01-09 1999-01-06 Client-side public key authentication method and device using short-lived certificate
CA002313328A CA2313328A1 (en) 1998-01-09 1999-01-06 Client side public key authentication method and apparatus with short-lived certificates

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US7108498P 1998-01-09 1998-01-09
US60/071,084 1998-01-09
US8543798A 1998-05-27 1998-05-27
US09/085,437 1998-05-27

Publications (1)

Publication Number Publication Date
WO1999035783A1 true WO1999035783A1 (en) 1999-07-15

Family

ID=26751814

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/000344 WO1999035783A1 (en) 1998-01-09 1999-01-06 Client side public key authentication method and apparatus with short-lived certificates

Country Status (6)

Country Link
EP (1) EP1042885A1 (en)
JP (1) JP2002501218A (en)
KR (1) KR20010033972A (en)
AU (1) AU2452699A (en)
CA (1) CA2313328A1 (en)
WO (1) WO1999035783A1 (en)

Cited By (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000072503A1 (en) * 1999-05-25 2000-11-30 Silverbrook Research Pty Ltd Interactive device network registration protocol
WO2001008351A1 (en) * 1999-07-22 2001-02-01 Rsa Security Inc. System and method for certificate exchange
WO2001027886A1 (en) * 1999-10-12 2001-04-19 Sonera Smarttrust Oy Distribution of certifiers
JP2001189720A (en) * 1999-10-19 2001-07-10 Sony Corp Enciphered communication system, token and enciphered communication method
EP1117207A2 (en) * 2000-01-14 2001-07-18 Hewlett-Packard Company Public key infrastructure
EP1117204A2 (en) * 2000-01-14 2001-07-18 Hewlett-Packard Company, A Delaware Corporation Authorization infrastructure based on public key cryptography
WO2001052470A2 (en) * 2000-01-14 2001-07-19 Hewlett-Packard Company Public key validation service
EP1162781A2 (en) * 2000-06-09 2001-12-12 TRW Inc. System and method for generation of a signature certificate in a public key infrastructure
WO2002017557A1 (en) * 2000-08-22 2002-02-28 Smarttrust Systems Oy Secured identity chain
WO2002044858A2 (en) * 2000-11-03 2002-06-06 Citrix Systems, Inc. System and method for securing a non-secure communication channel
WO2002044874A2 (en) * 2000-11-29 2002-06-06 Schlumberger Systems Sa Method, apparatus and computer program product for interoperable cryptographic material
JP2002169465A (en) * 2000-08-31 2002-06-14 Sony Corp Public key certificate utilization system, public key certificate utilization method and information processor as well as program recording medium
WO2002065696A1 (en) * 2001-02-14 2002-08-22 Gatespace Ab A security architecture
WO2002067158A1 (en) * 2001-02-17 2002-08-29 Hewlett-Packard Company Method and system for controlling the on-line supply of digital products or the access to on-line services
EP1280041A2 (en) * 2001-07-27 2003-01-29 Hewlett-Packard Company Authentication for computer networks
WO2003017069A2 (en) * 2001-08-14 2003-02-27 Elan Digital Systems Limited Data integrity
JP2003092565A (en) * 2001-09-17 2003-03-28 Toshiba Corp System, method, device and program for public key foundation
EP1309214A1 (en) * 2001-11-05 2003-05-07 Nokia Corporation Delivery of mobile station operational and self-performance test results to network in response to encrypted request message
WO2003075539A1 (en) * 2002-02-28 2003-09-12 General Instrument Corporation Detection of duplicate client identities in a communication system
KR100441077B1 (en) * 2000-06-08 2004-07-19 인터내셔널 비지네스 머신즈 코포레이션 Method and graphical user interface for allowing independent devices to work together as a single token interface
US6802002B1 (en) 2000-01-14 2004-10-05 Hewlett-Packard Development Company, L.P. Method and apparatus for providing field confidentiality in digital certificates
US6807577B1 (en) 2000-09-14 2004-10-19 International Business Machines Corporation System and method for network log-on by associating legacy profiles with user certificates
DE10124111B4 (en) * 2000-05-17 2006-05-04 Fujitsu Ltd., Kawasaki System and method for distributed group management
US7178724B2 (en) 2003-04-21 2007-02-20 Stmicroelectronics, Inc. Smart card device and method used for transmitting and receiving secure e-mails
US7245902B2 (en) 2002-01-16 2007-07-17 2 Ergo Limited Secure messaging via a mobile communications network
US7269726B1 (en) 2000-01-14 2007-09-11 Hewlett-Packard Development Company, L.P. Lightweight public key infrastructure employing unsigned certificates
US7293176B2 (en) 2000-07-17 2007-11-06 Citrix Systems, Inc. Strong mutual authentication of devices
WO2008017913A2 (en) * 2006-08-07 2008-02-14 Nokia Corporation Connecting a first device and a second device
EP1521426B1 (en) * 2003-09-30 2008-03-19 Ricoh Company, Ltd. Communication apparatus, communication system, certificate transmission method and program
US7685630B2 (en) 2006-05-04 2010-03-23 Citrix Online, Llc Methods and systems for providing scalable authentication
JP2011060291A (en) * 1999-08-31 2011-03-24 American Express Travel Related Services Co Inc Method and device for conducting electronic transactions
JP2012032843A (en) * 2001-08-13 2012-02-16 Univ Leland Stanford Jr System and method for id-based encryption and related cryptographic techniques
DE10259269B4 (en) * 2002-12-17 2013-10-31 Symantec Corporation (n.d.Ges.d. Staates Delaware) Device and method for individualized encryption and decryption as well as signature and signature verification via central components
US8694772B2 (en) 2008-08-04 2014-04-08 Industrial Technology Research Institute Method and system for managing network identity

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2810841B1 (en) * 2000-06-22 2005-07-29 Bull Cp8 METHOD FOR THE PROCESSING AND TRANSMISSION OF DIGITAL DATA ON A MOBILE TELEPHONY NETWORK, PARTICULARLY TO THE "GSM" STANDARD, AND ON-BOARD ELECTRONIC CHIP SYSTEM
KR20020042083A (en) * 2000-11-30 2002-06-05 오경수 Method for double encryption of private key and sending/receiving the private key for transportation and roaming service of the private key in the public key infrastructure
US7100200B2 (en) * 2001-06-13 2006-08-29 Citrix Systems, Inc. Method and apparatus for transmitting authentication credentials of a user across communication sessions
KR100495817B1 (en) * 2002-12-10 2005-06-16 주식회사 케이티 system of user authentication process for wireless network and method thereof
JP4611680B2 (en) * 2003-07-25 2011-01-12 株式会社リコー COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM
JP5348148B2 (en) * 2003-07-25 2013-11-20 株式会社リコー COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM
JP4712326B2 (en) * 2003-07-25 2011-06-29 株式会社リコー COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM
KR101010795B1 (en) * 2003-11-27 2011-01-25 엘지전자 주식회사 Multicasting method for mobile phone
JP2005333596A (en) * 2004-05-21 2005-12-02 Toshiba Corp Electronic application system, and electronic application apparatus
JP5464794B2 (en) * 2006-07-24 2014-04-09 コニカミノルタ株式会社 Network management method and network management system
WO2010013699A1 (en) 2008-07-28 2010-02-04 日本電気株式会社 Signature system
JP2011114730A (en) * 2009-11-27 2011-06-09 Cybertrust Japan Co Ltd Mail encryption/transmission system and program
CN115719224A (en) 2016-01-25 2023-02-28 创新先进技术有限公司 Credit payment method and device based on mobile terminal card simulation
CN106997527A (en) 2016-01-25 2017-08-01 阿里巴巴集团控股有限公司 Credit payment method and device based on mobile terminal P2P
JP6647259B2 (en) * 2017-09-19 2020-02-14 セコム株式会社 Certificate management device
SG11202008452PA (en) * 2018-03-02 2020-09-29 Nitto Denko Corp System and method for securing data communication between computers
JP6894469B2 (en) * 2019-06-11 2021-06-30 株式会社ユビキタスAiコーポレーション Information processing device and its control program

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5200999A (en) * 1991-09-27 1993-04-06 International Business Machines Corporation Public key cryptosystem key management based on control vectors
US5347580A (en) * 1992-04-23 1994-09-13 International Business Machines Corporation Authentication method and system with a smartcard
US5521966A (en) * 1993-12-14 1996-05-28 At&T Corp. Method and system for mediating transactions that use portable smart cards
US5655077A (en) * 1994-12-13 1997-08-05 Microsoft Corporation Method and system for authenticating access to heterogeneous computing services
US5687235A (en) * 1995-10-26 1997-11-11 Novell, Inc. Certificate revocation performance optimization
US5737419A (en) * 1994-11-09 1998-04-07 Bell Atlantic Network Services, Inc. Computer system for securing communications using split private key asymmetric cryptography
US5774552A (en) * 1995-12-13 1998-06-30 Ncr Corporation Method and apparatus for retrieving X.509 certificates from an X.500 directory

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5200999A (en) * 1991-09-27 1993-04-06 International Business Machines Corporation Public key cryptosystem key management based on control vectors
US5347580A (en) * 1992-04-23 1994-09-13 International Business Machines Corporation Authentication method and system with a smartcard
US5521966A (en) * 1993-12-14 1996-05-28 At&T Corp. Method and system for mediating transactions that use portable smart cards
US5737419A (en) * 1994-11-09 1998-04-07 Bell Atlantic Network Services, Inc. Computer system for securing communications using split private key asymmetric cryptography
US5655077A (en) * 1994-12-13 1997-08-05 Microsoft Corporation Method and system for authenticating access to heterogeneous computing services
US5687235A (en) * 1995-10-26 1997-11-11 Novell, Inc. Certificate revocation performance optimization
US5774552A (en) * 1995-12-13 1998-06-30 Ncr Corporation Method and apparatus for retrieving X.509 certificates from an X.500 directory

Cited By (61)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7805610B2 (en) 1919-05-25 2010-09-28 Silverbrook Research Pty Ltd System for registration of sensing device with printer
US7278018B2 (en) 1999-05-25 2007-10-02 Silverbrook Research Pty Ltd Optical sensing device for reading coded data on a surface and registration network for same
WO2000072503A1 (en) * 1999-05-25 2000-11-30 Silverbrook Research Pty Ltd Interactive device network registration protocol
US7360089B2 (en) 1999-05-25 2008-04-15 Silverbrook Research Pty Ltd Registration network for optical sensing device including printer as base station
US7529936B2 (en) 1999-05-25 2009-05-05 Silverbrook Research Pty Ltd Registration network for an optical sensing device
US6789191B1 (en) 1999-05-25 2004-09-07 Silverbrook Research Pty Ltd Interactive device network registration protocol
US7461250B1 (en) 1999-07-22 2008-12-02 Rsa Security, Inc. System and method for certificate exchange
WO2001008351A1 (en) * 1999-07-22 2001-02-01 Rsa Security Inc. System and method for certificate exchange
JP2011060291A (en) * 1999-08-31 2011-03-24 American Express Travel Related Services Co Inc Method and device for conducting electronic transactions
WO2001027886A1 (en) * 1999-10-12 2001-04-19 Sonera Smarttrust Oy Distribution of certifiers
JP2001189720A (en) * 1999-10-19 2001-07-10 Sony Corp Enciphered communication system, token and enciphered communication method
WO2001052470A3 (en) * 2000-01-14 2002-01-17 Hewlett Packard Co Public key validation service
EP1117204A2 (en) * 2000-01-14 2001-07-18 Hewlett-Packard Company, A Delaware Corporation Authorization infrastructure based on public key cryptography
US7340600B1 (en) 2000-01-14 2008-03-04 Hewlett-Packard Development Company, L.P. Authorization infrastructure based on public key cryptography
US7010683B2 (en) 2000-01-14 2006-03-07 Howlett-Packard Development Company, L.P. Public key validation service
EP1117207A2 (en) * 2000-01-14 2001-07-18 Hewlett-Packard Company Public key infrastructure
US6802002B1 (en) 2000-01-14 2004-10-05 Hewlett-Packard Development Company, L.P. Method and apparatus for providing field confidentiality in digital certificates
US7269726B1 (en) 2000-01-14 2007-09-11 Hewlett-Packard Development Company, L.P. Lightweight public key infrastructure employing unsigned certificates
EP1117204A3 (en) * 2000-01-14 2003-10-01 Hewlett-Packard Company, A Delaware Corporation Authorization infrastructure based on public key cryptography
WO2001052470A2 (en) * 2000-01-14 2001-07-19 Hewlett-Packard Company Public key validation service
EP1117207A3 (en) * 2000-01-14 2002-10-09 Hewlett-Packard Company Public key infrastructure
US6763459B1 (en) 2000-01-14 2004-07-13 Hewlett-Packard Company, L.P. Lightweight public key infrastructure employing disposable certificates
US7185194B2 (en) 2000-05-17 2007-02-27 Fujitsu Limited System and method for distributed group management
DE10124111B4 (en) * 2000-05-17 2006-05-04 Fujitsu Ltd., Kawasaki System and method for distributed group management
KR100441077B1 (en) * 2000-06-08 2004-07-19 인터내셔널 비지네스 머신즈 코포레이션 Method and graphical user interface for allowing independent devices to work together as a single token interface
EP1162781A3 (en) * 2000-06-09 2003-05-28 TRW Inc. System and method for generation of a signature certificate in a public key infrastructure
EP1162781A2 (en) * 2000-06-09 2001-12-12 TRW Inc. System and method for generation of a signature certificate in a public key infrastructure
US7293176B2 (en) 2000-07-17 2007-11-06 Citrix Systems, Inc. Strong mutual authentication of devices
WO2002017557A1 (en) * 2000-08-22 2002-02-28 Smarttrust Systems Oy Secured identity chain
JP4626033B2 (en) * 2000-08-31 2011-02-02 ソニー株式会社 Public key certificate utilization system, public key certificate utilization method, information processing apparatus, and program providing medium
JP2002169465A (en) * 2000-08-31 2002-06-14 Sony Corp Public key certificate utilization system, public key certificate utilization method and information processor as well as program recording medium
US6807577B1 (en) 2000-09-14 2004-10-19 International Business Machines Corporation System and method for network log-on by associating legacy profiles with user certificates
WO2002044858A3 (en) * 2000-11-03 2003-05-01 Citrix Systems Inc System and method for securing a non-secure communication channel
AU2002235149B2 (en) * 2000-11-03 2005-12-01 Citrix Systems, Inc. System and method for securing a non-secure communication channel
US6986040B1 (en) 2000-11-03 2006-01-10 Citrix Systems, Inc. System and method of exploiting the security of a secure communication channel to secure a non-secure communication channel
WO2002044858A2 (en) * 2000-11-03 2002-06-06 Citrix Systems, Inc. System and method for securing a non-secure communication channel
WO2002044874A3 (en) * 2000-11-29 2003-07-31 Schlumberger Systems Sa Method, apparatus and computer program product for interoperable cryptographic material
WO2002044874A2 (en) * 2000-11-29 2002-06-06 Schlumberger Systems Sa Method, apparatus and computer program product for interoperable cryptographic material
WO2002065696A1 (en) * 2001-02-14 2002-08-22 Gatespace Ab A security architecture
WO2002067158A1 (en) * 2001-02-17 2002-08-29 Hewlett-Packard Company Method and system for controlling the on-line supply of digital products or the access to on-line services
EP1280041A3 (en) * 2001-07-27 2003-04-23 Hewlett-Packard Company Authentication for computer networks
EP1280041A2 (en) * 2001-07-27 2003-01-29 Hewlett-Packard Company Authentication for computer networks
US9356779B2 (en) 2001-08-13 2016-05-31 The Board Of Trustees Of The Leland Stanford Junior University Systems and methods for identity-based encryption and related cryptographic techniques
JP2012032843A (en) * 2001-08-13 2012-02-16 Univ Leland Stanford Jr System and method for id-based encryption and related cryptographic techniques
WO2003017069A3 (en) * 2001-08-14 2004-05-21 Elan Digital Systems Ltd Data integrity
WO2003017069A2 (en) * 2001-08-14 2003-02-27 Elan Digital Systems Limited Data integrity
EP1310923A3 (en) * 2001-09-17 2004-04-07 Kabushiki Kaisha Toshiba Public key infrastructure (PKI) based system, method, device and program
JP2003092565A (en) * 2001-09-17 2003-03-28 Toshiba Corp System, method, device and program for public key foundation
KR100451879B1 (en) * 2001-09-17 2004-10-08 가부시끼가이샤 도시바 Public key infrastructure(pki)-based system, method and device, and recording medium
EP1309214A1 (en) * 2001-11-05 2003-05-07 Nokia Corporation Delivery of mobile station operational and self-performance test results to network in response to encrypted request message
US7369846B2 (en) 2001-11-05 2008-05-06 Nokia Corporation Delivery of mobile station operational and self-performance test results to network in response to encrypted request message
US7245902B2 (en) 2002-01-16 2007-07-17 2 Ergo Limited Secure messaging via a mobile communications network
WO2003075539A1 (en) * 2002-02-28 2003-09-12 General Instrument Corporation Detection of duplicate client identities in a communication system
DE10259269B4 (en) * 2002-12-17 2013-10-31 Symantec Corporation (n.d.Ges.d. Staates Delaware) Device and method for individualized encryption and decryption as well as signature and signature verification via central components
US7178724B2 (en) 2003-04-21 2007-02-20 Stmicroelectronics, Inc. Smart card device and method used for transmitting and receiving secure e-mails
EP1521426B1 (en) * 2003-09-30 2008-03-19 Ricoh Company, Ltd. Communication apparatus, communication system, certificate transmission method and program
US8015399B2 (en) 2003-09-30 2011-09-06 Ricoh Company, Ltd. Communication apparatus, communication system, certificate transmission method and program
US7685630B2 (en) 2006-05-04 2010-03-23 Citrix Online, Llc Methods and systems for providing scalable authentication
WO2008017913A3 (en) * 2006-08-07 2008-04-10 Nokia Corp Connecting a first device and a second device
WO2008017913A2 (en) * 2006-08-07 2008-02-14 Nokia Corporation Connecting a first device and a second device
US8694772B2 (en) 2008-08-04 2014-04-08 Industrial Technology Research Institute Method and system for managing network identity

Also Published As

Publication number Publication date
KR20010033972A (en) 2001-04-25
AU2452699A (en) 1999-07-26
JP2002501218A (en) 2002-01-15
EP1042885A1 (en) 2000-10-11
CA2313328A1 (en) 1999-07-15

Similar Documents

Publication Publication Date Title
WO1999035783A1 (en) Client side public key authentication method and apparatus with short-lived certificates
US9544297B2 (en) Method for secured data processing
US6317829B1 (en) Public key cryptography based security system to facilitate secure roaming of users
US7624269B2 (en) Secure messaging system with derived keys
US8281136B2 (en) Techniques for key distribution for use in encrypted communications
US7395549B1 (en) Method and apparatus for providing a key distribution center without storing long-term server secrets
EP0695985B1 (en) Logon certificates
US7890767B2 (en) Virtual smart card system and method
EP1500226B1 (en) System and method for storage and retrieval of a cryptographic secret from a plurality of network enabled clients
US6826686B1 (en) Method and apparatus for secure password transmission and password changes
US6092201A (en) Method and apparatus for extending secure communication operations via a shared list
US8315393B2 (en) System for on-line and off-line decryption
US8302171B2 (en) System and method for privilege delegation and control
US7698565B1 (en) Crypto-proxy server and method of using the same
US20030115452A1 (en) One time password entry to access multiple network sites
US20020087862A1 (en) Trusted intermediary
US7065642B2 (en) System and method for generation and use of asymmetric crypto-keys each having a public portion and multiple private portions
GB2385955A (en) Key certification using certificate chains
US7412059B1 (en) Public-key encryption system
Zhou et al. An efficient public-key framework
Alagappan et al. SPX Guide
Macdonell MiniCA: A web-based certificate authority

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 09462365

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 24526/99

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: 1999904041

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2313328

Country of ref document: CA

Ref country code: CA

Ref document number: 2313328

Kind code of ref document: A

Format of ref document f/p: F

WWE Wipo information: entry into national phase

Ref document number: 1020007007557

Country of ref document: KR

ENP Entry into the national phase

Ref country code: JP

Ref document number: 2000 528045

Kind code of ref document: A

Format of ref document f/p: F

WWP Wipo information: published in national office

Ref document number: 1999904041

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWP Wipo information: published in national office

Ref document number: 1020007007557

Country of ref document: KR

WWW Wipo information: withdrawn in national office

Ref document number: 1999904041

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 1020007007557

Country of ref document: KR