 |
Claims  |
|
|
We claim:
1. A cryptography system to support an application requiring cryptographic
functions, the cryptography system comprising:
a cryptographic application program interface (CAPI) to interface with the
application and handle its requests for a cryptographic function;
at least one cryptography service provider (CSP) independent from, but
dynamically accessible by, the CAPI;
the CSP providing the cryptographic function requested by the application,
the CSP also managing and protecting at least one encryption key used in
the cryptographic function to prevent exposure of the encryption key in a
non-encrypted form to the CAPI and application; and
a private application program interface (PAPI) to interface the CSP with a
user, the PAPI enabling the user to observe, confirm, or reject the
requested cryptographic function.
2. A cryptography system as recited in claim 1 wherein the CSP is digitally
signed with a digital signature of a certified trusted authority.
3. A cryptography system as recited in claim 2 wherein the CAPI verifies an
authenticity of the CSP by validating the digital signature of the
certified trusted authority.
4. A cryptography system as recited in claim 1 wherein the CSP computes a
digital signature of the cryptography system.
5. A cryptography system as recited in claim 1 wherein the CSP stores at
least one encryption key.
6. A cryptography system as recited in claim 1 wherein the CSP generates
the encryption key.
7. A cryptography system as recited in claim 1 wherein the CSP destroys the
encryption key following its use.
8. A cryptography system as recited in claim 1 wherein the CSP assigns a
handle to the encryption key, the handle being made available to the
application through the CAPI while the encryption key remains unavailable
to the application and the CAPI.
9. A cryptography system as recited in claim 1 wherein, when the
application requests encryption of a message, the CSP hashes at least some
data contained in the message.
10. A cryptography system as recited in claim 1 wherein the CSP is
implemented in software as dynamically linked libraries.
11. A cryptography system as recited in claim 1 wherein the CSP exports the
encryption key only in an encrypted form.
12. A cryptography system as recited in claim 1 wherein, when the
application requests encryption of a message, the CSP encrypts the message
using a symmetric encryption key and then encrypts the symmetric
encryption key using a public key from an asymmetric pair of private and
public encryption keys.
13. A cryptography system as recited in claim 1 wherein the CSP manages at
least one asymmetric pair of private and public encryption keys and
permanently retains the asymmetric private encryption key in confidence.
14. A cryptography system as recited in claim 1 further comprising multiple
CSPs to perform various ones of the cryptographic functions, said
cryptographic functions including encryption, decryption, signing, and
verification.
15. A cryptography system as recited in claim 1 wherein the PAPI presents,
to the user, an explanation of the cryptographic function being requested
by the application.
16. A cryptography system as recited in claim 1 wherein, when the
application requests a digital signature on a message, the PAPI presents
an opportunity for the user to confirm or deny attaching a digital
signature before the CSP digitally signs the message.
17. A cryptography system as recited in claim 1 wherein the PAPI verifies
the user's authenticity prior to enabling the user access to the
application through the CSP.
18. A cryptography system as recited in claim 1 wherein the PAPI enables
data entry from the user.
19. A cryptography system as recited in claim 1 wherein, when the
application requests use or exportation of a particular encryption key,
the PAPI selectively notifies the user when the particular encryption key
is to be used or exported.
20. In a computer system having a processing unit and a computer-readable
medium, a computer-implemented cryptography service provider stored on the
computer-readable medium for execution on the processing unit as part of a
cryptography system used to support a computer executable application
requiring encryption or decryption of electronic messages to be sent or
received by a user, the cryptography service provider comprising:
a key manager to manage encryption keys used to encrypt messages and to
prevent the encryption keys from being exported in a non-encrypted form
from the cryptography service provider;
an encryption/decryption device to encrypt or decrypt messages using the
encryption keys; and
the cryptography service provider being configured as a dynamic linked
library, software module which is dynamically accessible as needed by the
application to receive a plaintext message and to return an encrypted
message, or to receive an encrypted message and to return a plaintext
message, without exposing the encryption keys in their non-encrypted form
to the application.
21. A cryptography service provider as recited in claim 20 wherein the
encryption/decryption device encrypts individual messages using a
symmetric encryption key and then encrypts the symmetric encryption key
using a public key from an asymmetric pair of private and public
cryptographic keys.
22. A cryptography service provider as recited in claim 21 wherein the key
manager exports the symmetric encryption key only in an encrypted form.
23. A cryptography service provider as recited in claim 20 wherein the key
manager manages at least one asymmetric pair of private and public
cryptographic keys and permanently retains the asymmetric private
cryptographic key in confidence.
24. A cryptography service provider as recited in claim 20 where in the key
manager stores at least one unique encryption key.
25. A cryptography service provider as recited in claim 20 further
comprising a key generator to produce the encryption keys used to encrypt
the message.
26. A cryptography service provider as recited in claim 20 wherein the key
manager assigns handles to the encryption keys which are made available to
the application, while maintaining the encryption keys themselves
unavailable to the application.
27. A cryptography service provider as recited in claim 20 further
comprising a hashing calculator to hash at least some data contained in
the messages.
28. A method for supporting cryptographic functions requested by an
application, the method comprising the following steps:
supplying a request for a cryptographic function to a cryptographic
application program interface (CAPI);
selecting a cryptography service provider (CSP) to perform the desired
cryptographic function;
establishing communication between the CAPI and the CSP;
verifying an authenticity of the CSP;
performing the cryptographic function at the CSP using at least one
cryptographic key; and
preventing exposure of the encryption key in a non-encrypted form to the
CAPI or application.
29. A method as recited in claim 28 wherein the performing step comprises
performing a cryptographic function selected from a group comprising
encryption, decryption, digital signing, and verification.
30. A method as recited in claim 28 further comprising presenting
information concerning the requested cryptographic from the CSP through a
private application program interface (PAPI) to a user to enable the user
to observe, confirm, or reject the requested cryptographic function.
31. A method for encrypting a message comprising the following steps:
supplying a plaintext message to a cryptographic application program
interface (CAPI);
selecting a cryptography service provider (CSP) for encrypting the message;
establishing communication between the CAPI and the CSP;
verifying an authenticity of the CSP;
passing the plaintext message from the CAPI to the CSP;
encrypting the message at the CSP using an encryption key maintained by the
CSP to produce an encrypted message; and
passing the encrypted message from the CSP back to the CAPI without
exposing the encryption key in its non-encrypted form.
32. A method as recited in claim 31 wherein the encrypting step comprises
the following steps:
encrypting the message with a symmetric encryption key; and
encrypting the symmetric encryption key with a public key from an
asymmetric pair of private and public cryptographic keys.
33. A method as recited in claim 32 wherein the encrypting step comprises
the step of passing the encrypted symmetric encryption key to the CAPI
along with the message.
34. A method as recited in claim 31 wherein the verifying step comprises
the following steps:
attaching a digital signature of a certified trusted authority to the CSP;
and
validating the digital signature to authenticate the CSP.
35. A method as recited in claim 31 further comprising the step of
attaching a digital signature of the cryptography system to the message.
36. A method as recited in claim 31 further comprising the step of storing
within the CSP at least one unique encryption key.
37. A method as recited in claim 31 further comprising the step of
generating within the CSP the encryption key used to encrypt the message.
38. A method as recited in claim 31 further comprising the step of
destroying the encryption key following its use.
39. A method as recited in claim 31 further comprising the following steps:
assigning a handle to the encryption key; and
making the handle available to the CAPI while maintaining the encryption
key in confidence within the CSP.
40. A method as recited in claim 31 further comprising the step of hashing
within the CSP at least some data contained in the message.
41. A method as recited in claim 31 further comprising the following steps:
passing an explanation of the message to a private application program
interface (PAPI) used to interface the CSP with a user; and
presenting the explanation to the user.
42. A method as recited in claim 41 further comprising the step of
verifying at the PAPI an authenticity of the user prior to presenting the
explanation of the message.
43. A method as recited in claim 41 further comprising the step of enabling
data entry from the user through the PAPI.
44. A method as recited in claim 41 further comprising the step of
selectively notifying the user via the PAPI when a particular encryption
key is to be used.
45. A computer-readable medium having computer-executable instructions for
performing the steps in the method recited in claim 28.
46. A computer-readable medium having computer-executable instructions for
performing the steps in the method recited in claim 31.
47. A computer-readable medium having a computer-executable instructions
for implementing a cryptography system, comprising:
a cryptographic application program interface (CAPI) configured as a
software module to interface with a computer-implemented application and
to handle requests from the application for a cryptographic function;
at least one cryptography service provider (CSP) configured as a software
module independent from, but dynamically accessible by, the CAPI;
the CSP providing the cryptographic function requested by the software
application, the CSP also managing and protecting at least one encryption
key used in the cryptographic function to prevent exposure of the
encryption key in a non-encrypted form to the CAPI and software
application.
48. A computer-readable medium as recited in claim 47, further comprising a
private application program interface (PAPI) configured as a software
module independent from the CAPI and CSP, the PAPI being configured to
interface the CSP with a user and enable the user to observe, confirm, or
reject the requested cryptographic function.
49. A computer-readable medium as recited in claim 47, wherein:
the CSP module is digitally signed with a digital signature of a certified
trusted authority; and
the CAPI module verifies an authenticity of the CSP when accessing the CSP
by validating the digital signature of the certified trusted authority. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
TECHNICAL FIELD
This invention relates to cryptography systems. More particularly, this
invention relates to a computer implemented architecture for performing
cryptographic primitives including encrypting, decrypting, signing and
verifying/authenticating functions.
BACKGROUND OF THE INVENTION
Cryptography is the an and science of keeping messages secure from
eavesdroppers and adversaries. Historically, valuable messages were kept
secure by personal envoys who hand carried sensitive information from a
sending party to a receiving party. While useful in its time, this
protection method is not very practical in a modem world where information
flows freely and changes rapidly.
In more recent history, with the advent of computers, wireless
communication, and other technological advances, information can be
exchanged very quickly among many different individuals who were often
spread all over the world. To provide a secure interchange of information
in the electronic arena, one traditional approach to mitigating the risk
of having sensitive information intercepted was to institute proprietary
computerized systems that were closed to the general public. Such
proprietary systems promoted security simply by restricting physical
access through high security protocols. A private communication network
linked only those terminals that were authorized, and only participants to
the system with the appropriate security clearance were permitted access
to the terminals. Hence, participants and information were authenticated
by definition, and the integrity and value of the information were
preserved within the confines of the closed processing system.
Unfortunately, proprietary systems are not useful in a grander context
which envisions the interchange of information among virtually any
individuals without limitation.
Cryptography has evolved in the electronic setting as a means to securely
transfer information over a communication system that is presumed to be
insecure, like the telephone lines or a public communications network
(e.g., the Internet). In this electronic computerized context,
cryptography provides the necessary tools to digitally secure sensitive
and valuable electronic messages in a manner that insures privacy between
the authenticate sender and authenticate recipient of the communique, even
though the message is subject to interception on the insecure
communication system.
Before sending an electronic message, the sender encrypts it. "Encryption"
transforms the message from its plaintext into some meaningless ciphertext
that is not understandable in its raw form and cannot be deciphered by an
eavesdropper. To ensure the recipient that the true sender originated the
message, and not some impostor, the sender "digitally signs" the message
with its own unique digital signature. The signed encrypted message is
then transmitted over the insecure network to the intended recipient. The
recipient receives and decrypts the encrypted message. "Decryption"
transforms the message from its ciphertext back to its plaintext. Only the
recipient is presumed to have the ability to decipher the message. The
recipient also "verifies" the authenticity of the digital signature to
assure itself that the contents are from the legitimate sender and have
not been subsequently altered.
Encryption, decryption, digital signing, and verification are principal
cryptographic primitives that are used in an electronic network setting to
facilitate the security, privacy, authenticity, and integrity of
information being exchanged. These cryptographic primitives commonly
involve the use of secret cryptographic keys. "Keys" are a numerical
value, often expressed digitally as a number of bits, which are used in
the cryptographic algorithms that encrypt and decrypt messages. The keys
are uniquely associated with a particular identity, such as a person,
group, physical object, business, or institution. The keys are kept secret
and used selectively by the identity to perform the cryptographic
primitives as required. For example, a person might use a key to encrypt
and sign a purchase order message intended for a merchant. The merchant
might then use a key to decrypt the message and verify the authenticity of
the signature.
In a network setting, it is desirable to locate cryptographic functions in
the computer operating system so that they are available to other
applications executing on the computer. Furthermore, it is desirable to
define an application program interface (API) which allows the
applications access to the cryptographic functions in a standardized way.
A cryptographic API raises a number of important security issues.
Cryptographic functions, such as encryption and signing, can be performed
using a number of different algorithms and formats. Security can vary
widely among the different approaches. A single module of the operating
system cannot possibly implement all possible algorithms and formats that
a user or application might want to use in a given situation.
On the other hand, cryptographic functionality involves the handling of
sensitive information and the maintenance of secure keys. It would be
advantageous for a user or application to be able to trust the
cryptographic system on the same level that an operating system is
typically trusted.
There are also potential hazards of using cryptographic functions in the
computerized network setting. Since the functions are carried out
electronically, the user might assume the cryptographic routines are
operating as expected, yet not be aware of ignorant or sophisticated
electronic attacks. Careless applications might use cryptographic
encryption or signature keys in ways that jeopardize the keys' secrecy.
Moreover, malicious applications might even deliberately compromise the
user's secrecy, or worse, perform unauthorized cryptographic operations.
For instance, a malicious application might attempt to decrypt the user's
secret files and transmit them to some adverse party. Another situation
might involve an application attempting to digitally sign notes or IOUs on
behalf of the user without the user's knowledge or consent. A computer
implemented cryptographic system must therefore provide the needed
security to prevent attack from poorly devised or malicious applications.
Today, there are several electronic systems that provide cryptographic
services in the computer forum. These include "Bsafe libraries" by RSA
Data Security Inc., "X/Open CAPI", and "PKCS#". However, each of these
systems permit direct access of the application to keying material. There
is no protection of these cryptographic resources from electronic attack.
Furthermore, the Bsafe system, which is the most widely used cryptography
system, directly attaches the cryptographic code to the application. There
is no contemplation of protecting the cryptographic functions within the
computer from ignorant or malicious attacks from other software
applications.
It would therefore be advantageous to provide a computer implemented
architecture for performing cryptographic primitives that maintains and
protects the user's keys and prevents undesired access and use of
cryptographic functions without authorization from the user.
SUMMARY OF THE INVENTION
This invention provides a cryptographic system and method that protect a
user's keys and prevents undesired access and use of cryptographic
functions without authorization from the user. The cryptographic system is
a unique tri-layer architecture. It includes a cryptographic application
program interface (CAPI) which provides functionality to an application,
one or more cryptographic service providers (CSPs) which implement the
functionality presented by the CAPI to the application, and one or more
private application program interfaces (PAPI) which allow the CSPs to
communicate directly with a user.
The CAPI layer provides the interface with an application that requests
cryptographic functions such as encryption, decryption, signing, or
verification. The CAPI selects the appropriate CSP for performing the
requested cryptographic function. The CSPs perform the cryptography
functions and manage the cryptographic keys used in the functions. For
instance, one or more CSPs might be configured to perform the encryption
function using certain types of cryptographic algorithms and keys; one or
more different CSPs might be configured to decrypt the messages; another
CSP might be embodied to digitally sign messages; while still another CSP
might be designed to verify signatures and messages. Preferably, the CSPs
are implemented as dynamic linked libraries (DLLs) that are loaded on
demand by the CAPI, and which can then be called by the application
through the CAPI.
The CAPI also authenticates the chosen CSP. Each CSP has a digital
signature of a trusted authority which can be authenticated by the CAPI to
ensure that impostor CSPs are not introduced to the system.
To promote security, the application is restricted from direct access to
the cryptographic keys maintained in the CSPs, but is permitted to
manipulate the keys through the use of handles assigned by the CSPs.
Cryptographic keys used in the encryption and decryption are not exported
from the CSPs in their raw form, but only in an encrypted form. Moreover,
certain confidential private keys are not permitted to leave the CSPs
under any circumstances. In this manner, the CSPs protect the keys from
compromise, while simultaneously offering a full range of cryptographic
functionality that the user/application requests.
The PAPI keeps the user informed as to the functions being performed by the
CSPs. The PAPI provides the user with direct access to the CSP,
independent of the application. The PAPI can present information to the
user that the user may not trust the application to provide. For instance,
the CSP can present through the PAPI an explanation of the transaction
being conducted by the CSP. The CAPI might also present a dialog box
asking for the user's confirmation each time an application requests a
digital signature to enable the user to confirm or reject digitally
signing the message. The PAPI might also be configured to notify the user
and seek permission to export certain cryptographic keys.
This system architecture can be advantageously adapted to many different
environments. By implementing the cryptographic services as independent
and separate CSPs that are only accessible through a CAPI layer, the
architecture affords maximum protection of sensitive cryptographic keys.
Additionally, by implementing the CSPs as DLLs, the cryptographic
functions themselves and the associated security levels can be easily
modified or replaced without affecting the higher level application. This
is useful for rapid conformation to acceptable and changing regulatory and
legal practices imposed by various governments. Finally, by providing the
PAPI layer, the architecture protects the user from malicious applications
that attempt to expose key information or gain unauthorized signatures of
the user.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a schematic of an electronic commerce system during a
registration process according to one aspect of this invention.
FIG. 2 is a schematic of the electronic commerce system during a
transaction process according to another aspect of this invention.
FIG. 3 is a flow diagram of the registration process in a method for
conducting an electronic commerce transaction according to yet another
aspect of this invention.
FIG. 4 is a flow diagram of a process for generating a registration packet
that is performed during the registration process.
FIG. 5 is a flow diagram of a process for verifying a registration packet
that is performed during the registration process.
FIGS. 6-8 present a flow diagram of the transaction process in the method
for conducting an electronic commerce transaction.
FIG. 9 is a data structure used in the interchange of data between
participants in the electronic commerce system.
FIG. 10 is a block diagram of a computing unit provided at each participant
in the electronic commerce system.
FIG. 11 is a block diagram of an architecture for a cryptography system
according to yet another aspect of this invention.
FIG. 12-14 are a flow diagram of encrypting and signing functions performed
by the cryptography system.
FIG. 15-16 are a flow diagram of decrypting and verifying functions
performed by the cryptography system.
FIG. 17 is a schematic of the electronic commerce system embodied as a
credit card system according to another aspect of this invention. FIG. 17
shows the credit card system is during the registration phase.
FIG. 18 is a schematic of the credit card system during the transaction
phase.
FIGS. 19-22 are block diagrams depicting the FIG. 11 cryptography system as
services to operating system applications resident at a purchaser,
merchant, acquirer, and binder participants to the FIG. 18 credit card
system.
FIG. 23 is a schematic of the electronic commerce system embodied as an
interactive entertainment system according to yet another aspect of this
invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
The following discussion assumes that the reader is familiar with
cryptography. For a basic introduction of cryptography, the reader is
directed to a text written by Bruce Schneier and entitled "Applied
Cryptography: Protocols, Algorithms, and Source Code in C," published by
John Wiley & Sons with copyright 1994, which is hereby incorporated by
reference.
This invention particularly concerns a cryptographic system architecture
and method for providing cryptographic functionality in a computer network
environment. Primary aspects of this invention are described in detail
with reference to FIGS. 10-16. The cryptographic system can be implemented
in any context that requires cryptographic services, including such
functions as encryption, decryption, digital signing, and authentication.
To provide an example context, however, aspects of this invention are
described in the context of an electronic commerce system which
facilitates the secure interchange of commercial documents and instruments
over an insecure communication system. By describing the invention in a
particular example context, the reader will appreciate how the unique
architecture and methodology can be incorporated into a practical setting.
From this, the reader will better understand the invention and how it can
be implemented in essentially any electronic environment which has need
for cryptographic functions. The following sections describe the example
context of an electronic commerce system.
Electronic Commerce System
FIGS. 1 and 2 show an electronic commerce system 20 for conducting secure
electronic commerce transactions. The electronic commerce system 20
includes multiple trading partners or participants, which are represented
by three participants 22(a), 22(b), and 22(c), and a certified trusted
authority 26. Each individual electronic commerce transaction involves at
least one commerce instrument and at least one commerce instrument. The
commerce document defines the type of commerce transaction. Examples of
commerce documents include purchase orders and receipts, contracts, and
payment instruction receipts. The commerce instrument defines a mode of
payment for the transaction. Examples of commerce instruments include
payment instructions (e.g., checks and credit cards) and currency.
Computing units 24(a), 24(b), and 24(c) are provided at respective ones of
the participants 22(a), 22(b), and 22(c). The computing units are depicted
for illustration purposes as IBM.RTM.-compatible personal computers,
although other forms of computing units may be used. For instance, the
computing units might be embodied as conventional computers (such as
mainframe computers, servers, PCs, laptops, notebooks, etc.) or as other
computational machines, such as banking ATMs (automated teller machines)
and set-top boxes used in an interactive television system.
A computer server 28 is provided at the certified trusted authority 26. In
the commercial context, the certified trusted authority is often referred
to as a "credential binder," "binding authority," or simply "binder." The
server 28 is thus referred to herein as the "credential binding server."
The computer server is capable of receiving simultaneous requests from the
multiple participants, as will be described in more detail below.
The computing units 24(a), 24(b), and 24(c) and computer server 28 are
interconnected with each other via one or more communication systems. The
communication systems can be embodied as a wire-based or wireless network.
Examples of communications systems include an ATM (asynchronous transfer
mode) switching network, a public network, a wide area network, an
interactive television (ITV) network, a credit card network, a satellite
network, and an RF network.
The electronic commerce system of this invention is extremely flexible and
can be adapted to many different commerce transactions, as will become
more evident from the continuing discussion. In the general model of the
electronic commerce system 20 shown in FIGS. 1 and 2, a "participant" can
be an individual person (such as a credit card holder, an ITV viewer, or a
banking member at an automated teller machine), an entity or business
(such as a merchant, cable operator, or service provider), or an
institution (such as a bank). The certified trusted authority is a third
party entity that every participant thoroughly trusts. This authority is
established and recognized by all involved. Example certifying authorities
in the financial environment include the federal reserve or a bank. The
commerce environment in which the electronic commerce system is
implemented defines the rules and information required to carry out the
transactions, and additionally defines who or what entity is the certified
trusted authority.
The electronic commerce system 20 can be implemented in different
environments. As one example, the electronic commerce system can be
implemented in an credit card network system. The electronic commerce
system employs essentially the same existing banking and credit card
commerce structure, while broadening access to that system to individual
consumers. This example implementation is described below in more detail
with reference to FIGS. 17 and 18. As another example, the electronic
commerce system can be implemented in an interactive entertainme | | |
