Note: Descriptions are shown in the official language in which they were submitted.
CA 02313328 2000-06-07
s
CLIENT SIDE PUBLIC KEY AL~CATION
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).
CA 02313328 2000-06-07
s
2
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
S 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 maintaining
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 (PIE 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
CA 02313328 2000-06-07
s
3
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 Comity Consultatif Internationale Telegraphique et Telephonique
(CCI1'17),
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 parry
which, in
turn, is authenticated using the trusted party's certificate signed by yet
another trusted
party, so that there may be a mufti-level hierarchy of trusted parties.
CA 02313328 2000-06-07
4
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 Smartrard 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.
' 30 intranet- or Internet-wide distribution, of CRLs, and requires an
additional checking
CA 02313328 2000-06-07
s
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
5 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
CA 02313328 2000-06-07
s
6
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.); th:: 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 fulfilling Smart API Calls such as, e.g., C-SIGN, C-VERIFY.
In this
way, the present invention can take advantage of relatively mature application
programming 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
CA 02313328 2000-06-07
7
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 EMBODIIvVIENTS
Before describing features of embodiments of the present invention, certain
features of previous systems will first be described. Fig. 1 depicts an
authentication
CA 02313328 2000-06-07
s
8
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 (LAIC or other communication system to a key
distribution center (KDC) 116. In response, the client 114 sends a request
message
(AS-RED 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-RED 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
CA 02313328 2000-06-07
9
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
-w: 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
_ 30 periodically issues certificate revocation lists (CRL's) 214 as described
above. One
mechanism for distributing CRL's is via LDAP.
CA 02313328 2000-06-07
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 users public key (terrified by the CA) that the user
has been properly
5 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
10 otherwise tracking CRLs, particularly when CRLs are promulgated with
suffcient
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
_ 30 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
CA 02313328 2000-06-07
11
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 difi'erence between the present system and typical public key
systems
is that the certificate is short-lived, i.e., contains an expiration timeldate
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 di$'er 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).
CA 02313328 2000-06-07
12
In one embodiment, other data may be added to or modified in the series of
short-
lived 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
-y 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
CA 02313328 2000-06-07
13
systerr~ 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-
. ' ~~ER~Y'. 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-CAPI, 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 Microsoftm would use an MS-CAPI
interface
CA 02313328 2000-06-07
3
14
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
cuff dent 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
CA 02313328 2000-06-07
s
is
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 fiuther operation. In the
example of Fig.
-;. SA, 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. 8A, 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. SA 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
CA 02313328 2000-06-07
16
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
CA 02313328 2000-06-07
17
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 andlor 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.
CA 02313328 2000-06-07
,.
18
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.
