U.S. patent application number 09/940706 was filed with the patent office on 2003-03-13 for secure authentication using digital certificates.
This patent application is currently assigned to International Business Machines Corporation. Invention is credited to Gupta, Deepak.
Application Number | 20030051134 09/940706 |
Document ID | / |
Family ID | 25475288 |
Filed Date | 2003-03-13 |
United States Patent
Application |
20030051134 |
Kind Code |
A1 |
Gupta, Deepak |
March 13, 2003 |
Secure authentication using digital certificates
Abstract
The present invention provides in a method for providing secure
authentication using digital certificates, an improvement to enable
the selective transfer of authentication data. The said method
comprises presentation of basic authentication data certified by an
accepted certifying authority, at the commencement of a secure
transaction and transfer of additional individual authentication
data units against specific requests, as and when required, thereby
eliminating the risks associated with providing any authentication
data that is not required for a particular transaction. The instant
invention also provides a system and configured computer program
product for carrying out the above method.
Inventors: |
Gupta, Deepak; (Delhi,
IN) |
Correspondence
Address: |
Anthony England
1717 West Sixth Street
Suite 230
Austin
TX
78703
US
|
Assignee: |
International Business Machines
Corporation
Armonk
NY
|
Family ID: |
25475288 |
Appl. No.: |
09/940706 |
Filed: |
August 28, 2001 |
Current U.S.
Class: |
713/156 |
Current CPC
Class: |
H04L 63/04 20130101;
H04L 63/08 20130101; H04L 9/3263 20130101; H04L 2209/56
20130101 |
Class at
Publication: |
713/156 |
International
Class: |
H04L 009/00 |
Claims
1. In a method for providing secure authentication using digital
certificates, an improvement to enable the selective transfer of
authentication data comprising: presentation of basic
authentication data certified by an accepted certifying authority,
at the commencement of a secure transaction, transfer of additional
individual authentication data units against specific requests, as
and when required, thereby eliminating the risks associated with
providing any authentication data that is not required for a
particular transaction.
2. The improved method as claimed in claim 1 wherein the
authenticity of said additional individual authentication data is
established by using the public key provided in said basic
authentication data.
3. The improved method as claimed in claim 1 wherein the
authenticity of said additional individual authentication data is
established by signature of said accepted certifying authority.
4. The improved method as claimed in claim 1 wherein said
additional individual authentication data is provided without the
need for establishing a separate session.
5. The improved method as claimed in claim 1 further comprising the
facility to invalidate previously presented authentication data and
present new authentication data and present new authentication data
as and when required, thereby enabling establishment of new
transactions without the need for closing an existing session.
6. In a system for providing secure authentication using digital
certificates, an improvement to enable the selective transfer of
authentication data comprising: means for presenting basic
authentication data certified by an accepted certifying authority,
at the commencement of a secure transaction, means for transferring
additional individual authentication data units against specific
requests, as and when required, thereby eliminating the risks
associated with providing any authentication data that is not
required for a particular transaction.
7. The improved system as claimed in claim 6 wherein the
authenticity of said additional individual authentication data is
established by using the public key provided in said basic
authentication data.
8. The improved system as claimed in claim 6 wherein the
authenticity of said additional individual authentication data is
established by means of signature of said accepted certifying
authority.
9. The improved system as claimed in claim 6 wherein said
additional individual authentication data is provided without the
need for establishing a separate session.
10. The improved system as claimed in claim 6 further comprising
the means for invalidating previously presented authentication data
and present new authentication data and present new authentication
data as and when required, thereby enabling establishment of new
transactions without the need for closing an existing session.
11. In a computer program product comprising computer readable
program code stored on computer readable storage medium embodied
therein for providing secure authentication using digital
certificates, an improvement to enable the selective transfer of
authentication data comprising: computer readable program code
means configured for presenting basic authentication data certified
by an accepted certifying authority, at the commencement of a
secure transaction, computer readable program code means configured
for transferring additional individual authentication data units
against specific requests, as and when required, thereby
eliminating the risks associated with providing any authentication
data that is not required for a particular transaction.
12. The improved computer program product as claimed in claim 11
wherein the authenticity of said additional individual
authentication data is established by using the public key provided
in said basic authentication data.
13. The improved computer program product as claimed in claim 11
wherein the authenticity of said additional individual
authentication data is established by signature of said accepted
certifying authority.
14. The improved computer program product as claimed in claim 11
wherein said additional individual authentication data is provided
without the need for establishing a separate session.
15. The improved computer program product as claimed in claim 11
further comprising the computer readable program code means
configured for invalidating previously presented authentication
data and present new authentication data and present new
authentication data as and when required, thereby enabling
establishment of new transactions without the need for closing an
existing session.
Description
FIELD OF THE INVENTION
[0001] The present invention relates to an improved method, system
and computer program product for providing a secure authentication
using digital certificates.
BACKGROUND OF THE INVENTION
[0002] Security is one of the prime concerns in internet
applications these days. SSL is the most common means of securing
communication. For Authentication, SSL and almost all other
protocols use Digital Certificates or UserId/Passwords. Other
Authentication means include Biometrics etc. Normally, in
e-business related applications, the server is authenticated using
a Certificate signed by a Certifying Authority. The authentication
of the client is mostly dependent on the application. Sometimes it
is done via UserId Password, sometimes via Digital Certificates or
maybe not done at all.
[0003] The authentication, however, is singular and static. There
is no means to dynamically authenticate the user. The problem is
described in more detail below.
[0004] In SSL (Secure Socket Layer), the client needs to have a
certificate signed by a Certificate Authority which is listed as
trusted in the Servers Trusted Database. This enables it to access
the application depending upon the access allowed to the user
identified from the certificate. Now often, it is desirable that a
user acts as two roles. A typical example would be a manager acting
on behalf of his employee who may be on leave etc. In such cases,
the server will not accept another certificate unless the session
is broken and a new one established. Practically, speaking this
means closing the browser or the application or wait for sometime
for the timeout.
[0005] In SET (Secure Electronic Transaction), the client needs a
Digital Credit Card i.e. special Digital Certificate with users'
Credit Card information to buy things online. Now, he might wish to
use one card for some items while use another card for the other
items.
[0006] In SET, from the Merchant point of view also, he might wish
to offer some certificate to a group of clients and some to other.
That is to say, if the client wishes to buy high valued items, the
server wishes to present Certificate-A and if the client is buying
low priced items, he wishes to present Certificate-B. A typical
example would be a merchant who wishes to place his money from
Diamond items in one bank and the rest in another. Another example
would be a number of merchants selling stuff from a single
mall/store. They would like to present their own certificates
during payment on the SET protocol.
[0007] In Secure Email applications, the client authenticates
himself/herself using the Email Certificate i.e. a special Digital
Certificate with users' email information. With internet users
having more than one email IDs, the requirement to change their
Email preferences is all the more relevant even in case of personal
desktop. Users may wish to send some mails using their official ID
and others using their personal ones (hotmail etc).
[0008] In Secure Email applications, if the desktop is shared
between users, the next user will have to close and open the
application to view his mail i.e. to change the certificate. The
equivalent of `Switch ID` in Notes is not available.
[0009] Another major problem comes in applications that are
providing all the above. They have some applications that require
normal authentication using Digital Certificates. Simultaneously,
they might also have a store where users can buy using SET
certificates. He might also provide his users with the Secure Mail
option. Now each of these would require a different type of X509
Certificate or a combined Certificate with all the 3
extensions.
[0010] The problem with 3 different certificates has been discussed
above, i.e the user needs to timeout or restart the session to use
a different service.
[0011] The combined Certificate solves the problem to some extent.
However, there are some disadvantages.
[0012] 1. If a new application is to be added, the certificates
need to be reissued and retyped. Example would be: A site
implements a SET based store and the client get SET Certificates
from CAs, however after some time the site also provides a Secure
Email facility. in that case, the users need to have a combined
certificate. SO they have to get a new certificate. The
certificates being issued by the CA also need to be reformatted to
have an additional field related to E-mails. This would lead to
authentication data and present new authentication data and present
new authentication data as and when required, thereby enabling
establishment of new transactions without the need for closing an
existing session.
[0013] The present invention further provides in a system for
providing secure authentication using digital certificates, an
improvement to enable the selective transfer of authentication data
comprising:
[0014] means for presenting basic authentication data certified by
an accepted certifying authority, at the commencement of a secure
transaction,
[0015] means for transferring additional individual authentication
data units against specific requests, as and when required,
[0016] thereby eliminating the risks associated with providing any
authentication data that is not required for a particular
transaction.
[0017] The authenticity of said additional individual
authentication data is established by using the public key provided
in said basic authentication data.
[0018] The authenticity of said additional individual
authentication data is established by means of signature of said
accepted certifying authority.
[0019] The said additional individual authentication data is
provided without the need for establishing a separate session.
[0020] The above improved system further comprises the means for
invalidating previously presented authentication data and present
new authentication data and present new authentication data as and
when required, thereby enabling establishment of new transactions
without the need for closing an existing session.
[0021] The present invention also provides in a computer program
product comprising computer readable program code stored on
computer readable storage medium embodied therein for providing
secure authentication using digital certificates, an improvement to
enable the selective transfer of authentication data
comprising:
[0022] computer readable program code means configured for
presenting basic authentication data certified by an accepted
certifying authority, at the commencement of a secure
transaction,
[0023] computer readable program code means configured for
transferring additional individual authentication data units
against specific requests, as and when required,
[0024] thereby eliminating the risks associated with providing any
authentication data that is not required for a particular
transaction.
[0025] The authenticity of said additional individual
authentication data is established by using the public key provided
in said basic authentication data.
[0026] The authenticity of said additional individual
authentication data is established by signature of said accepted
certifying authority.
[0027] The said additional individual authentication data is
provided without the need for establishing a separate session.
[0028] The said improved computer program product further comprises
the computer readable program code means configured for
invalidating previously presented authentication data and present
new authentication data and present new authentication data as and
when required, thereby enabling establishment of new transactions
without the need for closing an existing session.
BRIEF DESCRIPTION OF THE DRAWINGS
[0029] The invention will now be described with reference to the
accompanying drawings
[0030] FIG. 1 shows the flow chart of the actions at the client,
according to this invention.
[0031] FIG. 2 shows the flow chart of the actions at the server,
according to this invention.
DETAILED DESCRIPTION OF THE INVENTION
[0032] In the proposed solution the user presents a General Purpose
Certificate called the `Identity Certificate` (IC) (1.1) at the
start of the secure session. This would essentially be the normal
X509 certificate with no extensions i.e. it will contain the Public
Key of the holder alongwith his credentials (Name, Organization
Unit, Organization, Address etc) and the Certificate Serial Number
and Certificate Authority's Signature.
[0033] Current Certificates look like the image given below.
1 This certificate has been verified i for the following uses: SSL
Server Certificate Email Signer Certificate Email Recipient
Certificate Status Responder Certificate Name: Class 4 Public
Primary Certification Authority - G2, VeriSign, Inc., US Issued
under: Verisign, Inc. Serial:
32.88:BE:9A:D2:F5:EB:13:47:FB:7F:C4:20:37:25:F8 Number: Validity:
Mon May 18, 1998 to Wed Aug. 02, 2028 Fingerprint:
26:6D:2C:19:98:B6:70:68:38:50:54:19:EC:90:34:60
[0034] The identity certificate for the same user could be:
2 This certificate has been verified i: Name: Class 4 Public
Primary Certification Authority - G2, VeriSign, Inc., US Issued
under: VeriSign, Inc. Serial:
32:88:8E:9A:D2:F5:EB:13:47:F8:7F:C4:20:37:25:F8 Number Validity:
Mon May 18, 1998 to Wed 02, 2028 Fingerprint:
26:6D:2C:19:98:B6:70:68:38:50:54:19:EC:90:34:60
[0035] Alongwith the IC, the entities would hold individual bits of
information signed by their own private key (which may be signed by
the CA or not). These would be called the `Application Unit Self
Certificate` (AUSC) where the AUSC would be different for different
bits of information. Depending upon the transaction the user or the
server would determine if additional authentication is required
(1.2). If such authentication is necessary the holder would present
the required AUSC (1.3) or continue session (1.4). The AUSCs can be
signed by the Certification Authority or may not be signed by the
CA. This is optional and the server has a choice to demand what it
requires. This will be a configurable option in the web servers
configuration file. Client Applications (including browsers) can
also generate these Certificates on the fly in case the CA
signature is not required. Clients will also have an option to
initiate a handshake with the Server in which they will provide the
AUSC to the server.
[0036] At the server end, the server will verify and accept the IC
presented by the client (2.1). It would then determine whether or
not any additional authentication was required (2.2) depending on
the nature of the transaction as well as configured options. If
additional authentication is necessary, the server would request
such additional data (2.3) from the clients. Finally, the server
would validate the AUSCs presented by the clients (2.4) by
verifying the certification of the AUSCs presented by the client by
the certification authority and other requirements specified on the
configuration data. AUSCs would provide the extra bits of
information required to access various services on the web site and
only relevant AUSCs will be sent by the client to the server. In
case, a similar AUSC has been already provided, it will be
overwritten by the new AUSC. The server will have an access control
mechanism (this will be the same as in current applications), in
which it can administer which Identity Certificates can provide
what types of AUSCs.
[0037] For example each user can have all the extensions fields
currently in a SET certificate in a SET USC. He/She can have his
email information in a Email USC. This would enable him to present
the information selectively as and when required. In other words,
the user can log on to the application with his IC and present his
AUSCs as and when required.
[0038] An Email USC might look like:
3 This certificate has been verified i: Name: Email unit Self
Certificate Value: deepakgupta@in.ibm.com Issued under: VeriSign,
Inc./Self Serial: 32:88:8E:9A:D2:F5:EB:13:47:F8:7F:C4:20:37:25:F8
Number. Validity: Mon May 18, 1998 to Wed 02, 2028 Fingerprint:
26:6D:2C:19:98:B6:70:68:38:50:54:19:EC:90:34:60
[0039] In the above, after presenting the Identity Certificate, if
the user wishes to use Secure Email, the user may present his/her
Email USC to the server and the server will be able to extract the
public information, the email Id and other relevant information
from the Email USC.
[0040] So if a website offers only general secured surfing on its
site, the user can only present his IC to the server. This would
authenticate the client to the server. The process of verifying
would be the same as is being done for normal X509 Digital
Certificates these days. This would include verifying the CA's
signature on the Certificate and then identifying the user from the
name on the Certificate. The point to note here is that after
verification process, the users public key is also with the server.
The only deviation in the present invention from normal SSL
handshake would be that the server would store the clients public
key in the session. This can be persisted in a database or stored
in the memory depending upon the type of server/application
used.
[0041] Subsequently, the site adds the secure email facility to its
web site, the user can then also present his/her Email USC to the
server. The process of authenticating remains the same as before.
However, when the client wishes to use the secure email facility,
the server asks for the Email USC from the client which can then be
presented. Since the user is already authenticated, the server
holds the public key of the client. So the signature on the USC
(which is of the client) can be verified by the server. Hence the
email information of the client is passed on to the server securely
without the CA having to issue another certificate. Same holds true
for SET based applications and other applications.
[0042] Another advantage of the same is that the client can only
expose the required fields to the server and hide the fields it
does not want to show. For example if the client wishes to only
surf a secured site, the client would not like to reveal any SET
credentials and email address to the server on which the client is
surfing. Having a common certificate would not help. Having USCs
would solve the problem automatically.
[0043] The client would also have an option in the client software
(including browsers) to invalidate a previously presented
Certificate and present a new one. This would be similar to
implementing the LogOut Option by the websites i.e. a request to
break the session and start a new one. Nothing special is being
claimed or proposed here except from the fact that the option of
providing the LogOut option is built in with the client
applications. Currently the web sites provide a link or button to
do so. Building it in the client applications would allow the users
to change their Identity Certificates also in between without
closing their browsers (or other client applications) and
restarting them.
[0044] Working:
[0045] The flow of activities between the Server and the Client, as
shown in FIGS. 1 & 2 would be:
[0046] 1. Normal Handshake as in the current protocols with the
Client presenting the Identity Certificate only. (1.1)
[0047] 2. The server verifies the IC (2.1) and determines whether
or not additional authentication is required (2.2). If additional
authentication is necessary the server generates a request on the
client (2.3)
[0048] 3. The client received the request from the server and
determines the nature of the additional requirements (1.2).
Optionally, the client may also itself determine what additional
authentication data it needs to send (1.2). The client accordingly
presents the required AUSC to the server (1.3)
[0049] 4. The server verifies the AUSC using clients' public key or
by verifying certification by certifying authority, based on
requirements specified in configuration data (2.4) The Server can
specify in the Server configuration, if it will accept AUSCs signed
only by the user of the signature of the CA is mandatory on the
AUSCs also. This would be as per the security requirements of the
web site.
[0050] 5. The session continues (1.4) and (2.5). At any point of
time, the server can request the client for a particular AUSC.
Also, at any point of time, the client can initiate and present
another AUSC. If a similar AUSC has been presented before, the
previous one will be overwritten by the new one.
[0051] At the server, each Identity Certificate/User can be given
fine grained access. Which user can present which types of AUSC and
the rights associated with all ICs and AUSCs can be defined. (The
mechanism for the same would be similar to the one used currently
for normal Digital Certificates).
[0052] In the above discussion, the examples have been explained
assuming the client having the IC and the ASUCs, however the same
can be implemented at the server side also. This would allow the
websites to switch their certificates depending upon the activities
of the client. The reasons for having multiple certificates at
server can be many. A relevant situation would be a merchant in SET
who wished to switch his Bank if the client is buying high valued
items OR he may wish to put his money from some special items in a
separate acquirer Bank OR he may wish to have higher bit encryption
for high valued items and so on.
[0053] The examples have mentioned SET and Secure Email, however
they are only examples, the solution is towards all applications
that require Digital Certificates and special extensions to the
same.
[0054] The proposed solution is also scalable and any new
application that comes in future can be simply added in the
framework by means of a simple new Application USC.
* * * * *