U.S. patent application number 10/194959 was filed with the patent office on 2003-05-29 for method and system for determining confidence in a digital transaction.
Invention is credited to Howell, Mark J., McCoy, Peter A., Russo, Anthony P..
Application Number | 20030101348 10/194959 |
Document ID | / |
Family ID | 27378853 |
Filed Date | 2003-05-29 |
United States Patent
Application |
20030101348 |
Kind Code |
A1 |
Russo, Anthony P. ; et
al. |
May 29, 2003 |
Method and system for determining confidence in a digital
transaction
Abstract
The present invention provides systems and methods utilizing
tokens to assign or mitigate risk. A software token is provided
that associates a secret--such as a private key or password--with
risk factors involved in protecting that secret from illicit
access. The token may include an indication or calculation of the
"overall risk of compromise" (OROC), generally represented as an
overall trust metric, associated with the secret. This token can
then be used to inform system operators or third parties of the
confidence of a given system transaction that depends on the
secret. A third party can then take whatever actions it deems
appropriate according to the estimated risk. For example, in one
embodiment of the present invention, the risk factor is used to
deny a transaction if the risk is deemed to great--that is if the
risk factor is greater than a predetermined (or sufficient)
value.
Inventors: |
Russo, Anthony P.; (New
York, NY) ; McCoy, Peter A.; (Santa Cruz, CA)
; Howell, Mark J.; (Tucson, AZ) |
Correspondence
Address: |
DORSEY & WHITNEY LLP
Suite 3400
Four Embarcadero Center
San Francisco
CA
94111-4187
US
|
Family ID: |
27378853 |
Appl. No.: |
10/194959 |
Filed: |
July 12, 2002 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10194959 |
Jul 12, 2002 |
|
|
|
10099554 |
Mar 13, 2002 |
|
|
|
10194959 |
Jul 12, 2002 |
|
|
|
10099558 |
Mar 13, 2002 |
|
|
|
60305120 |
Jul 12, 2001 |
|
|
|
Current U.S.
Class: |
713/185 |
Current CPC
Class: |
G06V 40/1335 20220101;
G06Q 30/06 20130101; H04L 9/3231 20130101; H04L 2209/08 20130101;
G06Q 20/4016 20130101; G06Q 20/04 20130101; G06Q 10/02 20130101;
H04L 2209/805 20130101 |
Class at
Publication: |
713/185 |
International
Class: |
H04K 001/00; H04L
009/00 |
Claims
We claim:
1. A transaction confidence token for use in a secure communication
system, said token comprising: an envelope comprising transaction
information; and a trust metric; and a seal comprising a digital
signature of said envelope.
2. A token according to claim 1, wherein said envelope further
comprises a time stamp.
3. A token according to claim 1, wherein said transaction
information includes information selected from the group consisting
of a web site address, a web session identifier, a monetary or
exchange value, an order number, an SKU number, and a credit card
number, and combinations thereof.
4. A token according to claim 1, wherein said trust metric is an
overall trust metric indicating a combined confidence level for
enrollment, storage, transmission, and authentication processes
employed for authentication of a transaction.
5. A token according to claim 1, wherein said trust metric
comprises a storage trust metric indicating a confidence level for
a storage process associated with authentication of a
transaction.
6. A token according to claim 1, wherein said trust metric
comprises a transmission trust metric indicating a confidence level
for a transmission process associated with authentication of a
transaction.
7. A token according to claim 1, wherein said trust metric
comprises an authentication trust metric indicating a confidence
level for an authentication process associated with authentication
of a transaction.
8. A token according to claim 1, wherein said trust metric
comprises an enrollment trust metric indicating a confidence level
for an enrollment process associated with authentication of a
transaction.
9. A token according to claim 1, wherein said trust metric
comprises an overall trust metric and said envelope further
comprises at least one metric chosen from the group consisting of
an enrollment trust metric, a storage trust metric, a transmission
trust metric, an authentication trust metric, and combinations
thereof.
10. A token according to claim 1, wherein said digital signature is
signed with a private key.
11. A method for assuring a secure transaction comprising:
receiving a transaction confidence token comprising a trust metric
associated with said transaction; determining if said trust metric
indicates a sufficient trust level; and processing said transaction
if said trust metric indicates or exceeds said sufficient trust
level.
11. A method according to claim 10, further comprising: requiring a
mitigating factor if said trust metric indicates less than said
sufficient trust level.
12. A method according to claim 11, wherein said mitigating factor
is chosen based on said trust metric.
13. A method according to claim 11, wherein said mitigating factor
is chosen from the group consisting of a fee, a waiting period, an
authentication procedure, and combinations thereof.
14. A method according to claim 11, further comprising: processing
said transaction after receiving said mitigating factor.
15. A method according to claim 10, further comprising:
constructing a transaction confidence token comprising said trust
metric; and transmitting said transaction confidence token to a
server.
16. A method for assuring a secure transaction comprising:
receiving a transaction confidence token comprising a trust metric
associated with said transaction; determining if said trust metric
indicates an acceptable risk level; and processing said transaction
if said trust metric indicates or is less than said acceptable risk
level.
17. A method according to claim 16, further comprising: requiring a
mitigating factor if said trust metric indicates greater than said
acceptable risk level.
18. A method according to claim 17, further comprising: processing
said transaction after receiving said mitigating factor.
Description
RELATED APPLICATIONS
[0001] This application further relates to the following co-pending
applications:
[0002] U.S. application Ser. No. ______, filed ______, entitled
"BIOMETRICALLY ENHANCED DIGITAL CERTIFICATES AND SYSTEM AND METHOD
FOR MAKING AND USING" (Attorney Docket No. A-70596/RMA/JML);
[0003] U.S. application Ser. No. ______, filed ______, entitled
"SECURE NETWORK AND NETWORKED DEVICES USING BIOMETRICS" (Attorney
Docket No. A70595/RMA/JML); and
[0004] U.S. application Ser. No. ______, filed ______, entitled
"METHOD AND SYSTEM FOR BIOMETRIC IMAGE ASSEMBLY FROM MULTIPLE
PARTIAL BIOMETRIC FRAME SCANS" (Attorney Docket No.
A-70591/RMA/JML); all of which are hereby incorporated by
reference.
[0005] This application claims the benefit under 35 U.S.C.
.sctn.119 and/or 35 U.S.C. .sctn.120 of the filing date of: U.S.
Provisional Application Serial No. 60/305,120, filed Jul. 12, 2001,
which is hereby incorporated by reference, and entitled SYSTEM,
METHOD, DEVICE AND COMPUTER PROGRAM FOR NON-REPUDIATED WIRELESS
TRANSACTIONS; U.S. patent application Ser. No. 10/099,554 filed
Mar. 13, 2002 and entitled SYSTEM, METHOD, AND OPERATING MODEL FOR
MOBILE WIRELESS NETWORK-BASED TRANSACTION AUTHENTICATION AND
NON-REPUDIATION; and U.S. patent application Ser. No. 10/099,558
filed Mar. 13, 2002 and entitled FINGERPRINT BIOMETRIC CAPTURE
DEVICE AND METHOD WITH INTEGRATED ON-CHIP DATA BUFFERING; each of
which applications are incorporated by reference herein.
FIELD OF THE INVENTION
[0006] The present invention relates generally to the field of
methods, computer programs and computer program products, devices,
and systems for encryption systems, especially public key
infrastructure (PKI) systems, and also to the field of biometrics,
especially but not limited to biometrics such as human fingerprints
and human voiceprints.
BACKGROUND OF THE INVENTION
[0007] The security and integrity of information systems depends in
part on authentication of individual users--accurately and reliably
determining the identity of a user attempting to use the system.
Once a user is authenticated, a system is then able to authorize
the user to retrieve certain information or perform certain actions
appropriate to the system's understanding of the user's identity.
Examples of such actions include downloading a document, completing
a financial transaction, or digitally signing a purchase.
[0008] Numerous methods have been developed for authenticating
users. Generally, as will be understood by those skilled in the
art, authentication methods are grouped into three categories, also
called authentication factors: (1) something you know--a secret
such as a password or a PIN or other information; (2) something you
have--such as a smartcard, the key to a mechanical lock, an ID
badge, or other physical object; and (3) something you are--a
measure of a person such as a fingerprint or voiceprint. Each
method has advantages and disadvantages including those relating to
ways that a system may be fooled into accepting a normally
unauthorized user in cases where, for example, a password has been
guessed or a key has been stolen.
[0009] The third category above--referred to herein as `something
you are` authentication methods--are the subject of the biometrics
field. Biometric identification is used to verify the identity of a
person by measuring selected features of some physical
characteristic and comparing those measurements with those filed
for the person in a reference database or stored in a token (such
as a smartcard) carried by the person. Physical characteristics
that are used today include fingerprints, voiceprints, hand
geometry, the pattern of blood vessels on the wrist or on the
retina of the eye, the topography of the iris of the eye, facial
patterns, and the dynamics of writing a signature or typing on a
keyboard. Biometric identification methods are widely used today
for securing physical access to buildings and securing data
networks and personal computers.
[0010] A secure system is based upon either a mutually-shared
secret or a private key of a public-private key pair. During the
enrollment process, the secret is first selected or created, then
agreed upon and stored for later use. There are generally four
major sources of risk associated with the secret being compromised:
(1) the secret can be guessed by an unauthorized user; (2) the
secret was observed by an unauthorized user during creation or
subsequent transmission; (3) the stored secret can be retrieved and
employed by an unauthorized user after creation; and/or (4) the
stored secret was issued to the wrong party.
[0011] Each of the above broad categories has its own specific risk
factors depending on the type of secret, where and how it is stored
and how it is created. For example, the risk of guessing is
dependent on a variety of factors including, but not limited to,
the type of secret (for example, a password, a private PKI key, a
symmetric key, or the like), the length of the secret (for example,
number of characters in the password or number of bits in the
private key), and the randomness of the secret (for example, an
entropy calculation plus, in the case of a password, whether the
password matches a dictionary word). The risk of observation during
transmission is dependent on factors including, but not limited to:
whether it was transmitted at all (generally, there is no
transmission of the secret in PKI); what type of encryption was
used, if any, during transmission; and the network used for the
transmission (for example, whether it was transmitted using a
telephone, an internet, a private network, or other network or
communication link or channel).
[0012] The risk of a stored secret being illicitly retrieved is
dependent on factors including, but not limited to: the number of
devices where instances of the secret are stored (for example, a
secret may be stored on a user's PC as well as in a system
database); the storage medium used for each stored instance (hard
disk, paper notes, smart card, portable memory device such as a
flash memory card, PKCS-11 token (as discussed further in "PKCS #11
v2.11: Cryptrographic Token Interface Standard" published June 2001
by RSA Laboratories, hereby incorporated by reference), or the
like); whether the secret is stored in plain text or encrypted; if
stored encrypted, the risk associated with the encryption key used;
what kind of biometrics used, if any, to restrict access to the
storage medium; the security of passphrase used, if any, to
retrieve secret; the security of biometric system(s) used, if any,
to retrieve secret; and the security of physical token used, if
any, to retrieve secret--for example if a token is used, the
security of that token is dependent upon whether someone else has
had access to it, or if it has been lost or stolen; what
combinations of passphrase, biometric, and token are required, if
any; and the security of the enrolled biometric template.
[0013] The risk associated with the secret being issued to the
wrong person is dependent on factors including, but not limited to:
the specific method or methods used to verify the user's identity
prior to issuing the secret; the degree of human interaction, if
any, involved in the verification process (i.e. is it supervised
and verified by a trained human being); what specific biometric
system or systems, if any, is used to aid verification; which
government agencies (such as for example the FBI, Secret Service,
or other agency), if any, aid in the verification process; and
which trusted documents, if any, were required for verification
(for example bank statement, social security number, passport, or
the like).
[0014] Systems used for e-commerce, online banking and other
financially related areas rely on security to prevent unauthorized
users from accessing services for monetary gain. For example,
well-designed systems try to prevent would-be buyers from
purchasing goods and services with someone else's credit card by
requiring a PIN or a password.
[0015] More generally, the security and integrity of information
systems depends primarily on keeping data confidential so that only
authorized users may see or act against the data, and assuring the
integrity of data so that the data can not be changed or tampered
with undetected. The field of cryptography provides well-known
tools for assuring confidentiality and integrity using encryption
techniques such as ciphers and hash algorithms.
[0016] One widely known and implemented body of these tools, and
procedures and practices for their use, is called Public Key
Infrastructure (PKI). PKI gets its name from its use of a class of
cryptographic algorithm called a public key algorithm. As is widely
known to those versed in the cryptographic field, a public key
algorithm is a cryptographic algorithm that operates using two
different but mathematically-related keys, a public key that may be
shared with any party and a private key which must be kept secret,
such that (for must such algorithms) data encrypted with the public
key may only be decrypted with the private key, and vice-versa. PKI
standards are well known, X.509 for example, described in Housley,
R., "Internet X.509 Public Key Infrastructure Certificate and CRL
Profile," RFC 2459, January 1999, and ITU-T Recommendation X.509
(1997 E): Information Technology--Open Systems Interconnection--The
Directory: Authentication Framework, June 1997, both of which are
hereby incorporated by reference.
[0017] These standards provide powerful mechanisms for safe and
private storage and transmission of confidential data so that it
remains hidden from unauthorized parties. The standards provide for
digital signatures, which provide the receiving party of some data
with an assurance of the identity of the transmitting party. PKI
standards further provide for digital certificates, which provide a
tamper-resistant, portable record of the association of a public
key with a person's or organization's name, attested to and signed
by a trusted party, thus presenting a form of unique, irrefutable
digital identity or credential for that person or organization. PKI
standards also provide other useful and powerful mechanisms that
can contribute to the security and integrity of information
systems.
[0018] PKI is widely used in commercial and non-commercial systems,
both over the Internet and in more closed or local applications.
Most web browsers, for example, use PKI and PKI-based standards to
interoperate with web servers when high security is desired, as
when a user specifies a credit card number for payment while
placing an online order. The proliferation of electronic commerce
has led many jurisdictions around the world to begin to develop
legal standards with the intended result that a correctly
constituted digital signature would be every bit as legally binding
as a handwritten signature is today.
[0019] PKI provides powerful mechanisms, but it has weaknesses. One
way for digital identities to be compromised is for an impostor to
somehow get a copy of the private key that is associated with the
public key embedded in a certificate, thus invalidating an
assumption that only the person or organization to which the
certificate is issued has access to the (secret) private key.
Anyone with both the certificate (which is meant to be public
information, freely exchanged with anyone) and the associated
private key (which is meant to be secret) can impersonate someone
else and compromise the security and integrity of an information
system dependent on the valid use of a certificate and associated
private key.
[0020] Most systems, therefore, secure the private key such that
the user must authenticate before the private key can be used for
any task. Many such systems require a password ("something you
know") or a smartcard ("something you have"), or both. Some systems
provide additional security by putting the private key on a
smartcard that is resistant to tampering or copying. Other systems
may also employ biometrics ("something you are") to ensure that the
person using the private key is in fact the true owner of the
certificate.
[0021] However, smart cards may be lost, damaged, or stolen.
Passwords may be forgotten or guessed. Biometrics systems can be
fooled. These concerns are part of what is called in the field "the
last-meter problem", the problem of making sure that an otherwise
secure system isn't compromised by a failure to correctly
authenticate the person using (and usually physically adjacent to)
some part of the system. The last-meter problem can present
opportunities for impostors in PKI systems. Mathematically, the
theoretical probability of a PKI system being fooled or otherwise
compromised is extremely low (much less than 1 in a billion, for
instance). However, once the "last meter problem" is taken into
account, the security of such a system is greatly reduced, as the
"last meter problem" becomes the weakest link in an otherwise very
secure chain.
[0022] Today's PKI systems do not take into account the risk
associated with the "last meter problem" when assessing the trust
level to associate with users of such systems.
[0023] Accordingly, it is an object of the present invention to
provide an indication of the security of a given transaction.
SUMMARY
[0024] In a first embodiment, the invention provides a transaction
confidence token for use in a secure communication system,
comprising an envelope and a seal. The envelope comprises
transaction information and a trust metric. The seal contains a
digital signature of the envelope. In preferred embodiments, the
envelope further includes a timestamp. In some embodiments, the
transaction information contained in the envelope includes a web
site address, a web session identifier, a monetary or exchange
value, an order number, an SKU number, a credit card number, or any
combinations thereof.
[0025] In one embodiment, the trust metric within the envelope is
an overall trust metric indicating a combined confidence level for
enrollment, storage, transmission, and authentication processes
employed for authentication of a transaction.
[0026] In another embodiment, the trust metric comprises a storage
trust metric indicating a confidence level for a storage process
associated with authentication of a transaction. In yet another
embodiment, the trust metric comprises a transmission trust metric
indicating a confidence level for a transmission process associated
with authentication of a transaction. In still another embodiment,
the trust metric comprises an authentication trust metric
indicating a confidence level for an authentication process
associated with authentication of a transaction. In a further
embodiment, the trust metric comprises an enrollment trust metric
indicating a confidence level for an enrollment process associated
with authentication of a transaction. In other embodiments, a
plurality of trust metrics are provided in the envelope. In one
embodiment, a first trust metric comprises an overall trust metric
and at least a second trust metric is provided chosen from the
group consisting of an enrollment trust metric, a storage trust
metric, a transmission trust metric, an authentication trust
metric, and combinations thereof.
[0027] In some embodiments, the digital signature contained in the
seal is signed with a private key.
[0028] The present invention further provides methods for assuring
a secure transaction. In one embodiment, a method for assuring a
secure transaction comprises receiving a transaction confidence
token comprising a trust metric associated with the transaction,
determining if the trust metric indicates a sufficient trust level;
and processing the transaction if the trust metric indicates or
exceeds said sufficient trust level.
[0029] In some embodiments, a method further comprises requiring a
mitigating factor if said trust metric indicates less than said
sufficient trust level. The mitigating factor may be chosen based
on the trust metric. The mitigating factor may be chosen from the
group consisting of a fee, a waiting period, an authentication
procedure, and combinations thereof.
[0030] In yet other embodiments, the method further comprises
processing the transaction after receiving a mitigating factor.
[0031] In other embodiments, the method further comprises
constructing a transaction confidence token comprising a trust
metric, and transmitting said transaction confidence token to a
server.
[0032] In other embodiments, a method for assuring a secure
transaction comprises receiving a transaction confidence token
comprising a trust metric associated with said transaction,
determining if said trust metric indicates an acceptable risk
level; and processing said transaction if said trust metric
indicates or is less than said acceptable risk level.
[0033] In some embodiments, the method further comprises requiring
a mitigating factor if said trust metric indicates greater than
said acceptable risk level. In still other embodiments, the method
further includes processing said transaction after receiving said
mitigating factor.
BRIEF DESCRIPTION OF THE DRAWINGS
[0034] The present invention may be better understood, and its
features and advantages made apparent to those skilled in the art
by referencing the accompanying drawings.
[0035] FIG. 1 is a schematic representation of one embodiment of a
transaction confidence token according to an embodiment of the
present invention.
[0036] FIG. 2 is a schematic flowchart showing a method of
processing a transaction according to an embodiment of the present
invention.
[0037] FIG. 3 is a schematic flowchart outlining a process for
using a transaction confidence token according to an embodiment of
the present invention.
DETAILED DESCRIPTION OF THE EMBODIMENTS
[0038] Many systems today, especially those that use PKI, involve
transactions that depend on keeping a secret protected from use by
third parties. If there is any risk that the secret is compromised,
then that risk is propagated to the provider of the transaction
itself. For example, if an internet-based system allows a user to
purchase an item by entering any valid credit card number, then the
risk to the credit card company or merchant related to an
unauthorized purchase is dependent on how well that credit card
number can be kept secret, for example, how well authenticated are
the parties to whom the secret is made available.
[0039] This invention introduces the concept of a software token
that associates a secret--such as a private key or password--with
risk factors involved in protecting that secret from illicit
access. Furthermore, in preferred embodiments of the present
invention, the token includes an indication or calculation of the
"overall risk of compromise" (OROC), generally represented as an
overall trust metric, associated with the secret. In some
embodiments of the present invention, the token also includes a
calculation of individual risk factor probabilities used to
determine the OROC, or overall trust metric. This token can then be
used to inform system operators or third parties of the confidence
of a given system transaction that depends on the secret. A third
party can then take whatever actions it deems appropriate according
to the estimated risk. For example, in one embodiment of the
present invention, the risk factor is used to deny a transaction if
the risk is deemed to great--that is if the risk factor is greater
than a predetermined (or sufficient) value. In another embodiment,
the risk factor is used to charge the user a fee in an effort to
mitigate the risk, or where some fee may already be charged to the
user for the transaction to charge different fees according to the
assessed risk or trust level. The fee may be a flat fee charged to
all transactions having less than a sufficient trust level or the
fee may vary according to the trust level indicated by the
token.
[0040] Most authentication systems are geared to answer the
question of whether the party trying to use the system is the party
it claims to be with either a yes or no, even though the
authentication method or methods employed are imperfect. The
present invention provides a mechanism for a system to add an
estimate of risk or confidence on that yes or no answer, and for
other systems to use that confidence information to their
advantage. In one embodiment, it also provides a mechanism for
documenting the party's identity so as to provide a non-repudiation
mechanism for the transaction.
[0041] That is, the present invention provides systems utilizing
tokens to assign or mitigate risk.
[0042] FIG. 1 depicts a schematic representation of transaction
confidence token 100 according to one embodiment of the present
invention.
[0043] A token, such as token 100, is created using available
information regarding risk factors, examples of which are discussed
above. Token 100 can be in the form of a separate packet of stored
data associated with the secret, integrated either with the secret
itself or, in the case of PKI, with the associated digital
certificate.
[0044] The present invention provides transaction confidence tokens
comprising at least one trust metric. As used herein, `trust
metric` generally refers to a measure of a risk factor. Examples of
typical risk factors are discussed above. In one embodiment, token
100 comprises information on at least one risk factor discussed
above. In another embodiment, token 100 comprises an overall
risk-of-compromise (OROC) value, or overall trust metric 110, which
may take one or more risk factors into consideration. In a
preferred embodiment, token 100 is created and stored in a database
during both enrollment and subsequent transactions, includes all
the fields shown in FIG. 1. In other embodiments, only a subset of
fields shown in FIG. 1 are present.
[0045] In one embodiment of the present invention, trust metrics,
such as overall trust metric 110, are given by an absolute
probability ranging from 0.0 to 1.0, calculated using a weighted
Bayesian equation. Other ranges and equations for calculating trust
metrics may also or alternatively be employed. In preferred
embodiments of the present invention, trust metrics are given by an
arbitrary mapping of risk information to three categories--low,
medium, and high. Any number of categories may alternatively be
used, with each category represented by a unique indicator. The
risk information may alternatively be provided by a continuous
range of values rather than in discrete categories. Overall trust
metric 110 represents a weighted combination of individual risk
probabilities of a plurality of risk factors. In a preferred
embodiment, a system uses token 100 to deny or accept a
transaction. In other embodiments, a system charges a fee, or
imposes another mitigation factor--such as a waiting period or
another required authentication--based on risk information
contained in token 100.
[0046] Accordingly, transaction confidence token 100 (FIG. 1) is
composed of two data structures: envelope 120 and seal 130.
Envelope 120 comprises transaction contents, or transaction
information 140 and at least one trust metric, although a plurality
of trust metrics are shown in FIG. 1. Further, envelope 120
comprises timestamp 150. In a preferred embodiment, transaction
information 140 represents a complete record of a
transaction--including, as appropriate, account numbers, web
session identifiers, monetary or exchange values, item quantities,
an SKU number, an order number, a credit card number, a web URL or
address, or other data describing the user's authenticated request.
In other embodiments, transaction information 140 comprises only
some of the above information associated with a transaction. In a
preferred embodiment, transaction information 140 comprises only a
transaction identifier or reference string such as a web session
identifier as is often used in web applications. In an alternative
embodiment, transaction information 140 field comprises a complete
transaction confidence token, which may in turn (i.e., recursively)
contain another transaction confidence token in its transaction
contents field, without particular limit. This embodiment allows
for multiple parties to attest to a transaction and attach their
own confidence to the transaction as it is processed by each of a
number of systems in series. The innermost transaction confidence
token corresponds to the original transaction when it is first
authenticated and signed by the originating party. Timestamp 150
generally comprises a string indicating a date and time at which
the authentication event which is the subject of the transaction
confidence token took place. Generally, any time indicator is
appropriate for timestamp 150. In a preferred embodiment, timestamp
150 is expressed in Universal Coordinated Time (UTC). Overall trust
metric 110 indicates a degree of overall confidence in a
transaction. In one embodiment, overall trust metric 110 provides a
degree of confidence in enrollment, storage, transmission, and
authentication processes employed for authentication of a
transaction. Overall trust metric 110 can be defined according to
the specifics of the application contemplated, but in a preferred
embodiment, there are three possible values corresponding to low,
medium, and high confidence. In a preferred embodiment, low
security refers to a password authentication against a 4-digit
numeric PIN stored in non-secure storage. Medium security refers to
a fingerprint authentication or strong password (alphanumeric,
mixed case, greater than 8 characters) against a secret in
non-secure storage, and high security is attributed to a
fingerprint authentication or strong password against a secret in
secure storage such as a smart card. Generally, any number of trust
categories can be assigned among any authentication processes.
[0047] Envelope 120 may comprise metrics related to measures of
individual aspects of an authentication process. That is, envelope
120 may comprise some or all of the following optional fields: (1)
Enrollment Trust Metric 160, (2) Storage Trust Metric 170, (3)
Transmission Trust Metric 180, and (4) Authentication Trust Metric
190.
[0048] Enrollment Trust Metric 160 indicates a degree of confidence
in security of an enrollment or personalization process under which
a secret was issued to an authenticating party. Enrollment trust
metric 160 can be defined according to specifics of the application
employed. In a preferred embodiment, there are three possible
values corresponding to low, medium, and high confidence. In one
embodiment, a low confidence enrollment trust metric is assigned to
self-enrollment where little or no manual verification of user
identity is carried out; a medium confidence enrollment trust
metric is assigned to online verification using a "weak secret"
such as a credit card number, which may be independently verified
to match the enrollee's name by the credit card issuer; and a high
confidence enrollment trust metric is assigned in an enrollment
situation where the user's identity is verified--using trusted
documents such as a passport, driver's license, or the like--by a
human being who works for the enrollment agency or represents
another predetermined organization.
[0049] Storage Trust Metric 170 indicates a degree of confidence in
the security of a method of storage used to store a secret. Storage
Trust Metric 170 can be defined according to the specifics of the
application employed. In a preferred embodiment, there are three
possible values corresponding to low, medium, and high confidence.
Here, in one embodiment, a storage trust metric indicating a low
confidence level is assigned to storage of a secret in unencrypted
form on a hard disk or FLASH memory of a PC or other computing
device; a storage trust metric indicating a medium confidence level
is assigned to storage of a secret in encrypted form on a hard
drive or FLASH memory of a PC or other computing device and
protected with a PIN or password; and a storage trust metric
indicating a high confidence level is assigned to storage of a
secret in secure storage, such as that of a smart card, and
protected with a PIN or password.
[0050] Transmission Trust Metric 180 indicates a degree of
confidence in security of a method of transmission, if any, of a
secret. This Transmission Trust Metric can be defined according to
specifics of the application employed, but in a preferred
embodiment, there are three possible values corresponding to low,
medium, and high confidence. In one embodiment, a transmission
trust metric indicating a low confidence level is assigned to a
transmission of a secret in unencrypted form via the internet or
local computer network; a transmission trust metric indicating a
medium confidence level is assigned to transmission of a secret in
encrypted form using SSL or TLS (as known in the art and described
further in Dierks, T., and Allen, C., "The TLS Protocol Version
1.0," RFC 2246, January 1999, hereby incorporated by reference) or
other common standard of network encryption; and a transmission
trust metric indicating a high confidence level applies to
transmission of a secret via armored car using a certified carrier
such as, for example, Brink's@, Inc.
[0051] Authentication Trust Metric 190 indicates a degree of
confidence in the security of a method of authentication for a
particular transaction. Authentication Trust Metric 190 can be
defined according to specifics of the application employed, but in
a preferred embodiment, there are three possible values
corresponding to low, medium, and high confidence. Accordingly, in
one embodiment, an authentication trust metric indicating a low
confidence level is assigned to authentication using a PIN or
password ("something you know"); an authentication trust metric
indicating a medium confidence level is assigned to authentication
using a physical token such as a PKCS-11 standard device or smart
card ("something you have"); and an authentication trust metric
indicating a high confidence level is assigned authentication
requiring use of a biometric such as fingerprint, voiceprint, or
face recognition ("something you are").
[0052] In other embodiments, greater or fewer trust levels are
provided. In still other embodiments a continuous range of trust
metric values is provided. In some embodiments, more than one type
of procedure, device, or method may be assigned an identical trust
metric value. For example, in some embodiments both encrypted and
unencrypted storage of a secret on a hard disk receive a trust
metric indicating a low trust level, while secure storage of a
secret--for example on a smart card protected with a PIN--receives
a trust metric indicating a high trust level. Although in preferred
embodiments, trust metrics provide an indication of security based
on measurable risk factors, in other embodiments trust metric
values are not constrained by theoretical security weaknesses. For
example, a particular storage method or enrollment procedure may be
assigned a stronger or weaker trust metric based on a preferred or
encouraged method for performing those functions.
[0053] Seal 130 of transaction confidence token 100 is a string of
bytes containing a digital signature of envelope 120, signed in a
preferred embodiment with the private key of the authenticating
party or system.
[0054] In a preferred embodiment, envelope 120 and seal 130 are
constructed according to PKCS #7--for a detailed description of the
standard, see, for example RSA Laboratories. PKCS #7: Cryptographic
Message Syntax Standard. Version 1.5, November 1993, hereby
incorporated by reference. Using that standard's signed-data
content type such that envelope 120 is embodied in a content
information (contentInfo) field and seal 130 is embodied in a
signer information (signerInfos) field. Note that PKCS #7 also
allows for the recursion of transaction information field 140 of
envelope 120 in a transaction confidence token.
[0055] In another embodiment, envelope 120 and seal 130 are
constructed according to the XML Signature Syntax and Processing
Recommendation--for a detailed description of the standard see, for
example Eastlake 3.sup.rd, D., Reagle, J., and Solo, D.,
"(Extensible Markup Language) XML-Signature Syntax and Processing,"
RFC 3275, March 2002, incorporated herein by reference.
[0056] Other encodings or structures of a transaction confidence
token are also possible.
[0057] The present invention further provides systems and methods
for using a transaction confidence token. For example, when a
requester (client) or server initiates a transaction requiring
authentication, such as in step 200 in FIG. 2, server 210 requests
the authentication and an associated transaction confidence token.
In other embodiments, no specific request is made by server 210.
During the course of the transaction Requester 220 allows access to
a secret, step 230, such as a private encryption key using an
authentication method, such as a biometric match. Numerous devices
and methods exist for securing a secret, including those described
in U.S. application Ser. No. ______, filed ______, entitled "Secure
Network And Networked Devices Using Biometrics" (Attorney Docket
No. A-70595/RMA/JML), incorporated herein by reference. Requester
220 generates, step 240, contents of a requested transaction, such
as the quantity and SKUs of item(s) to be purchased, in a form
suitable to be encoded in the transaction confidence token's
transaction contents, or transaction information field, such as
transaction information 140 in token 100 depicted in FIG. 1.
[0058] Requester 220 determines at least one trust metric, step
250, as described above and encodes at least one trust metric in
the transaction confidence token. Requester 220 signs the
transaction confidence token in step 260. Server 210 receives a
transaction confidence token associated with a transaction request
in step 270. Server 210 then adjusts its confidence level, in the
transaction, step 280, based on whether the signature is valid and
takes action appropriate to the confidence level, completing the
transaction in step 290.
[0059] The present invention further provides methods for a server
to act on a transaction confidence token. FIG. 3 provides a
schematic overview of an embodiment of such a method according to
the present invention. A server receives a transaction confidence
token, step 300, and verifies the signature of the transaction
confidence token, step 310, using, for example, the public key of
the originator of the transaction confidence token. If the
signature verification fails, indicating that the transaction
confidence token was not created by the purported originating
party, had been altered after its creation, or otherwise is
invalid, then the system may then discard the token, step 320, and
assume no confidence in the authenticity of the associated
transaction. In a preferred embodiment, a transaction confidence
token with an invalid signature is discarded and the associated
transaction request is discarded or rolled back according to
appropriate exception handling practice for the application
employing methods of the present invention.
[0060] If the signature verification succeeds, then the server
determines its confidence in the transaction, step 330, calculated
from one or more trust metric fields in the transaction confidence
token.
[0061] If another Server or plurality of Servers are to participate
in the transaction, step 340, the original receiving server may
construct a new transaction confidence token, and embed the current
transaction confidence token, optionally asserting its own degree
of confidence in the transaction, step 350. The server then
transmits, step 360, a new transaction confidence token (comprising
embedded first transaction confidence token) to other participating
Server(s), step 370.
[0062] The Server may then do its own processing of the transaction
request employing the confidence it has determined, step 370. For
example, if a trust metric within the transaction confidence token
indicates or exceeds a predetermined sufficient trust level, the
server processes the transaction. However, in one embodiment, if a
trust metric does not indicate a minimum sufficient trust level,
the server rejects the transaction. If a trust metric indicates a
minimum sufficient trust level but less than a sufficient trust
level, the server may require a mitigating factor. For example, the
server may require an additional authentication procedure, a fee,
or a waiting period in an effort to mitigate risk associated with a
predetermined range of trust metric values.
[0063] Although embodiments of the present invention discussed
above generally refer to `confidence levels` or `trust levels` with
increasing trust metric values associated with increasing trust or
confidence in a transaction, in other embodiments, trust metrics
are assigned and evaluated with respect to risk. That is, risk is
generally the opposite of trust and trust metrics may be assigned
such that increasing trust metric values corresponding to an
increasing risk associated with a transaction. In these
embodiments, less secure situations would receive a higher trust
metric value. For example, in some embodiments of the present
invention, a confidence level between 0.0 and 1.0 is calculated. A
corresponding risk level in this embodiment is given generally by
1--(confidence level).
[0064] That is, in another embodiment, if a trust metric within the
transaction confidence token indicates or exceeds a predetermined
maximum risk level, the risk is determined to be too great, and the
server the server rejects the transaction. However, if a trust
metric indicates less than a maximum risk level but greater than an
acceptable risk level, the server may require a mitigating factor
before processing the transaction. For example, the server may
require an additional authentication procedure, a fee, or a waiting
period in an effort to mitigate risk associated with a
predetermined range of trust metric values. If a trust metric
indicates less than an acceptable risk level, the server will
process the transaction.
[0065] Having described several methods and procedures, it will be
appreciated that the invention may advantageously implement the
methods and procedures described herein on a general purpose or
special purpose computing device, such as a device having a
processor for executing computer program code instructions and a
memory coupled to the processor for storing data and/or commands.
It will be appreciated that the computing device may be a single
computer or a plurality of networked computers and that the several
procedures associated with implementing the methods and procedures
described herein may be implemented on one or a plurality of
computing devices. In some embodiments the inventive procedures and
methods are implemented on standard server-client network
infrastructures with the inventive features added on top of such
infrastructure or compatible therewith.
[0066] The foregoing descriptions of specific embodiments and best
mode of the present invention have been presented for purposes of
illustration and description. They are not intended to be
exhaustive or to limit the invention to the precise forms
disclosed, and obviously many modifications and variations are
possible in light of the above teaching. The embodiments were
chosen and described in order to best explain the principles of the
invention and its practical application, to thereby enable others
skilled in the art to best utilize the invention and various
embodiments with various modifications as are suited to the
particular use contemplated. It is intended that the scope of the
invention be defined by the claims appended hereto and their
equivalents.
* * * * *