U.S. patent application number 11/295417 was filed with the patent office on 2006-04-27 for method for integrating online and offline cryptographic signatures and providing secure revocation.
Invention is credited to Carl A. Gunter, Trevor Jim.
Application Number | 20060090075 11/295417 |
Document ID | / |
Family ID | 35482791 |
Filed Date | 2006-04-27 |
United States Patent
Application |
20060090075 |
Kind Code |
A1 |
Jim; Trevor ; et
al. |
April 27, 2006 |
Method for integrating online and offline cryptographic signatures
and providing secure revocation
Abstract
A verification method and system including a verifier which can
both interpret policies and determine if they are satisfied, and
request and obtain relevant certificates. This new architecture
includes a verifier which itself can both direct a retrieval
mechanism and use a local database of information. Users and
applications can obtain and supply certificates to the verifier and
the local database. The verifier may invoke a retrieval mechanism
to obtain necessary certificates from other authenticated data
servers and store them in a secondary database. The flexibility to
allow for both on-line and off-line authenticated data server
responses for verification is encompassed, as is an enhanced system
for security including revocation of certificates using a polarity
discipline, which allows data used for revocation to be handled
with the same system used for other verification data without
imperiling security.
Inventors: |
Jim; Trevor; (Princeton,
NJ) ; Gunter; Carl A.; (Philadelphia, PA) |
Correspondence
Address: |
RATNERPRESTIA
P O BOX 980
VALLEY FORGE
PA
19482-0980
US
|
Family ID: |
35482791 |
Appl. No.: |
11/295417 |
Filed: |
December 6, 2005 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09561806 |
Apr 29, 2000 |
6981148 |
|
|
11295417 |
Dec 6, 2005 |
|
|
|
60131937 |
Apr 30, 1999 |
|
|
|
Current U.S.
Class: |
713/176 ;
726/1 |
Current CPC
Class: |
H04L 63/102 20130101;
H04L 63/12 20130101; Y10S 707/99939 20130101; H04L 9/3263 20130101;
Y10S 707/99933 20130101 |
Class at
Publication: |
713/176 ;
726/001 |
International
Class: |
H04L 9/00 20060101
H04L009/00 |
Claims
1. The method for verification by a verifier of information
comprising the steps of: receiving a verification request for
verification information from a requesting application, said
verification request expressed in a programming language which
includes two syntactically distinct classes of names and variables,
one of said classes expressing positive information, and the second
of said classes negative information; examining available policies
and certificates to determine whether said verification request is
satisfiable; based upon one or more of said verification request,
said policies, and said certificates, optionally generating a query
based upon said verification request; sending said query to an
authenticated data server; receiving a response from said
authenticated data server based upon said query; determining
whether said response includes information indicating said
verification request is satisfiable; sending information on the
satisfiability of said vertification request to said requesting
application.
2. The method of claim 1, where said class expressing negative
information expresses the revocation of certificates or
permissions.
3. The method of claim 1, where said steps sending said query to an
authenticated data server comprises the step of sending said query
to an authenticated data server via a distributed computer network,
and said step of and receiving a response from said authenticated
data server based upon said query comprises the step of receiving a
response from said authenticated data server based upon said query
via said distributed computer network.
4. The method of claim 3, where said distributed computer network
is the Internet.
5. The method of claim 1, where said step of determining whether
said response includes information indicating said verification
request is satisfiable comprises the step of evaluating whether an
on-line or an off-line response has been received.
6. The method of claim 1, where said programming language is an XML
markup language.
Description
[0001] This application is a Continuation of U.S. patent
application Ser. No. 09/561,806 filed Apr. 29, 2000 which claimed
priority from Provisional Application No. 60/131,937.
TECHNICAL FIELD
[0002] The present invention relates generally to secured
communications and, more particularly, to a scheme for increasing
the efficiency of policy checking for verifying data.
BACKGROUND OF THE INVENTION
[0003] In order to verify and certify the origin of certain data, a
system may be used in which users have public keys which must be
certified in order to provide security. This type of system, a
public key infrastructure (PKI), relies on certification of public
keys.
[0004] In such a public key (or "asymmetric") scheme, each user has
a private key and a public key. The user can use the private key to
compute a signature for a given message. Upon receipt of a signed
message, the recipient can use the public key for the purported
sender to determine whether the message was, indeed, signed using
the sender's private key. Security is maintained because the
private key can not be determined using the public key; therefore
by keeping the private key private and disseminating the public key
widely, the user will have the advantages of security and wide
verifiability of signatures.
[0005] However, the system will not work unless it can be clearly
ascertained that the public key the recipient associates with a
particular sender is actually that sender's public key. For
example, if a message arrives that is purportedly from Alice but is
actually from an impostor, the recipient will not know that it is
not from Alice if the public key that the recipient believes to be
Alice's is actually one for which the impostor has the private
key.
[0006] This system also works in reverse--a message may be sent to
a recipient encrypted using the recipient's public key. The
decryption can be accomplished only with the private key, and
again, it is therefore important to ensure that the proper public
key is being used, or an impostor may be able to intercept and
decrypt the communication.
[0007] In order to control for this, certificates are issued (and
revoked) by a authenticated data server. The authenticated data
server contains certificates which are themselves signed using the
public key/private key system. The certificates may be stored
locally. For example, in prior art FIG. 1, a user 10, running an
application 20, may provide the application with certificates, as
indicated by the arrow from user 10 to application 20. The
application 20 may provide that certificate to verification
component (verifier) 30, as indicated by the arrow between them.
The verifier 30 may also receive certificates from a local database
40. The database 40 may also receive certificates from the
application 20. In order to determine whether needed certificates
are available, the verifier 30 must be able to interpret a policy,
received from the user 10 or application 20, which determines which
certificates will be used. If the right certificates are not
available locally, the user 10 must then attempt to retrieve them
over network 70 from remote database 60 via the retrieval component
50. A few applications 20 may be smart enough to retrieve missing
certificates without user intervention, but these are not
widespread.
[0008] The problem with the prior art system is that there is
duplication of two kinds: between the verifier 30 and the
application 20 and between different applications 20. In order to
see how there can be duplication between the verifier 30 and the
application 20, suppose application 20 is an email application
using the PGP system (PGP stands for "Pretty Good Privacy" and is
described in P. Zimmerman, The Official PGP User's Guide, MIT Press
1995). If the email application is being used to send an encrypted
message to Bob, and the policy is "rely on either Alice or Trent
for key bindings" the email application will invoke the verifier
30, which will examine the policy and look for a certificate for
Bob signed by Alice or Trent in the local database 40 or for other
information which could verify Bob's key (for example, a
certificate signed by Alice which allows Eve to provide key
bindings in her stead, and a certificate signed by Eve which can
verify Bob's key.) If no such certificate is found, it reports
failure to the email application. If the email application were
"smart" it would examine the policy to determine what certificates
are needed from remote database 60, and therefore which query to
send to retrieval component 50. If email application is not this
advanced, it may be left to the user 10 to request the necessary
certificates. In this case, both the verifier 30 and the
application 20 or user 10 are examining the policy. In the case of
the smart application 20, the logic for understanding policies is
duplicated in the verifier 30 and the application 20, and that it
will be executed not once or even twice, but three times: once for
the failed verification, a second time by the application 20 to
formulate the query to the retrieval component 50 or the user, and
a final time by the verifier when the application submits the
retrieved certificates for approval.
[0009] Another sort of duplication exists between different
applications. An application that wants to have automated
certificate retrieval may not be able to use the retrieval
mechanism of an existing second application. The code in the second
application may be proprietary or specific to that application, or
the writer of the first application may not trust the writers of
the second system. Policy languages and verifiers of prior art
systems (such as PolicyMaker (described in M. Blaze et al.,
"Decentralized Trust Management", Proceedings of the 17th Symposium
on Security and Privacy, pp. 164-173 IEEE Computer Society Press,
1996) and SPKI/SDSI (described in C. M. Ellison et al., "SPKI
Certificate Theory" available at
<http://ietf.org/rfc/rfc2693.txt?number=2693>)) were made as
general as possible in order to eliminate this sort of duplication
in policy language interpretation and verification. However, it has
not been eliminated for policy-directed retrieval.
[0010] In order to provide policy-directed certificate retrieval,
the prior art verifier 30 receives responses to its query from the
remote database 60 over the network 70 in a format which includes
the query or a hash of the query. This requires the remote database
60 and related remote system (not pictured) to be on-line (to
contain a private key and encryption software) in order to provide
security (signing) for the responses sent to the verifier 30. This
is a clear security problem, as the remote database 60 is attached
to the network 70, and therefore vulnerable to unauthorized access.
Off-line signing solves the security problem, however the
flexibility of the system is limited and storage needs at the
remote database 60 may be increased.
[0011] Additionally, prior art retrieval devices provide revocation
capabilities. This is useful in order to revoke the validity of
information that has already been sent out into the distributed
secure system. The prior art method of ensuring that information
relied upon has not been revoked is to establish a separate
protocol which is invoked in order to find out if issued
certificates have been revoked. Attempts have also been made to
provide revocation by providing certificates which indicate
non-membership. (Described in Moni Naor and Kobbi Nissim,
"Certificate Revocation and certificate update", 7.sup.th USENIX
Security Symposium, 1998.) If not used properly, this can cause
security loopholes. An adversary can collect certificates and
present contradictory certificates in order to overcome security
restrictions. For example, if a certificate indicates that Ann is a
member of the group students, and school individuals has been
defined as a group consisting of the combinations of subgroups
teachers, administrators and students, then Ann may be able to
receive a certificate verifying that Ann is a member of the group
school individuals. However, if school employees has been defined
as the group consisting of those in the group school individuals
who are not in the group students, and Ann graduates or leaves the
school and can obtain a certificate indicating that she is no
longer in the group students, then she may be able to present
herself as a school employee even though she is not. To do this,
she could present that certificate ("Ann is not a student") and her
earlier certificate ("Ann is a school individual") and may qualify
as a school employee, as she can show that she satisfies the
definition. This is clearly a security loophole--an adversary may
collect different certificates and present them in ways which allow
revocation certificates to be used to overcome security
restrictions.
[0012] It is clear that certificates will be used by more and more
applications in the coming years. For example, consider the
documents involved in pre-approval of a mortgage. Today, these
documents are passed along by mail, fax, computer network, orally
(over the telephone), through personal contact, and so on. The
authentication of documents generally relies on letterheads and the
security of communication channels like the telephone or personal
meetings. The person requesting the mortgage and the one granting
it would like to come to mutual agreement. This agreement involves
information transfer, which could be verified by a security system.
In addition to provision of security for these transactions, a
system which can integrate security and the organization of the
data flow and requests would be a significant improvement over the
prior art.
SUMMARY OF THE INVENTION
[0013] It is, therefore, an object of the invention to provide a
secure system that eliminates duplication in policy interpretation
between applications or between an application and verifier and
allows for on-line and off-line verification by the remote
server.
[0014] It is a further object of the invention to provide a secure
system which allows for revocation of certificates without
introducing security loopholes which may allow revocation
certificates to be used to frustrate security policies.
[0015] The above objects are met by the present invention which
encompasses a verification method and system including a verifier
which can both interpret policies and determine if they are
satisfied, and request and obtain relevant certificates. This new
architecture includes a verifier which itself can both direct a
retrieval mechanism and use a local database. As with the prior art
architecture, users and applications can obtain and supply
certificates to the verifier and the local database, and the
verifier may invoke a retrieval mechanism to obtain necessary
certificates from other authenticated data servers and store them
in a secondary database. The invention also encompasses the
flexibility to allow for both on-line and off-line authenticated
data server responses for verification, and an enhanced system for
security including revocation of certificates using a polarity
discipline, which allows data used for revocation to be handled
with the same system used for other verification data without
imperiling security.
BRIEF DESCRIPTION OF THE DRAWINGS
[0016] FIG. 1 is a block functional and data flow diagram for a
prior art security architecture.
[0017] FIG. 2 is a block functional and data flow diagram for a
security architecture according to the present invention.
[0018] FIG. 3 is a flowchart of the query evaluation according to
the present invention.
[0019] FIG. 4 is a table of the internal language according to the
present invention.
[0020] FIG. 5 is a table of the clauses of the internal language
according to the present invention.
[0021] FIG. 6 is a table of the polarity rules for the internal
language according to the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0022] In the preferred embodiment, the system according to the
present invention, QCM (Query Certificate Manager) utilizes a
language in which queries can be presented to QCM by an
application. QCM is a language based upon the language of sets. In
the preferred embodiment, users of QCM write programs in a
higher-level language (the external language) which is translated
into the QCM internal language in which the programs (security
policies) are decomposed and optimized.
[0023] FIG. 2 shows how retrieval in the QCM verifier system can be
accomplished. The user 210 or application 220 can send certificates
to the QCM verifier 230 or to a local database 240. The QCM
verifier 230 also has access to a retrieval mechanism 250, which
can communicate over the network 270 to an authenticated data
server 260. Other applications with retrieval mechanisms 280 can
also act as authenticated data servers in accordance with the
method and system of this invention. In a preferred embodiment, the
network 270 is the Internet.
[0024] In one embodiment the syntax of the QCM language is based
upon set language, and is similar to that of SPKI and other prior
art systems. In another embodiment it is based on XML markup
language, standardized by the W3 Consortium
<http://www.w3.org>. When the QCM verifier 230 is asked to
evaluate a policy using the certificates available to it, a
successful evaluation results in the data needed or a positive
indication of success. If not, the expression will evaluate to
something else. In the preferred embodiment, the result which
indicates that the certificates available are not sufficient is the
empty set.
[0025] If the QCM verifier 230 can not find the appropriate
certificate, it may send a query to the authenticated data server
260. The query will be optimized to produce a smaller rather than a
larger reply from the authenticated data server. For example, if
the certificate being sought is one for Alice's public key, the
query can ask for all certificates regarding all keys resident in
the authenticated data server. However, a query directed toward all
certificates for Alice's public key will be used by the QCM
verifier 230. The responses from the authenticated data server 260
are signed. This response is then used by the QCM verifier 230 to
determine the public key being sought.
[0026] In order to allow for flexibility in authenticated data
server security, the authenticated data server 260 may produce
either an on-line or off-line answer. An on-line answer is produced
if the authenticated data server 260 contains a private key and the
ability to sign its responses using that private key. On-line
responses can be direct replies. Direct replies will contain the
answer to the question posed to the authenticated data server 260,
the identity of the authenticated data server 260, and the query or
a hash of it (in order to ensure that the response is valid for the
query given). Because the authenticated data server does not know
in advance what queries it will receive, it could not have prepared
the certificate in advance. This is why that the private key has to
be online and available to the authenticated data server 260, and
the authenticated data server 260 has to sign each certificate
dynamically.
[0027] QCM also has an offline signing mode, in which the
authenticated data server 260 contains a number of presigned
certificates indicating that a certain key is associated with a
certain user or containing other verification information. Instead
of returning a response including the query sent, the QCM verifier
230 would evaluate the query, keep track of which presigned
certificate(s) would be useful in producing an answer, and return
that certificate (or those certificates) as a response. The
requesting verifier would then need to evaluate the query using the
certificate(s) returned in order to get data requested. This will
require more processing time than the evaluation of a direct reply,
but the authenticated data server 260 need not have signing
capability, but need only have the capability to evaluate queries
and transmit relevant certificates.
[0028] The data to be verified can be key bindings, access control
information, or any other data for which verification is necessary.
By way of illustration, the preferred embodiment will be described
with reference to a system for responding to requests for a user's
public key, or for verification that a particular user is
associated with a particular public key. If the authenticated data
server 260 contains information that can associate the user with
the key, a yes answer verifying the association (or a certificate
which would enable the verifier to evaluate the query to verify the
association) would be returned from the authenticated data server
260. If no such verification can be made, the query will evaluate
to the empty set, indicating not necessarily that the
identification of user to key is unsound, but rather that no such
association could be positively confirmed.
[0029] In order to secure communications with an authenticated data
server 260, the QCM verifier 230 will use the public key of that
server and all responses from the server should be signed by the
server's private key. In the preferred embodiment, "chains of
trust" can be created. The QCM verifier 230 can contain more than
one authenticated data server 260 which it will rely upon for
secure certificates. This constitutes a chain of trust of length 1,
that is, the verifier determines which authenticated data servers
it directly trusts. A chain of trust of length 2 can also be used,
in which authenticated data servers whose security can be verified
by an authenticated data server 260 that the verifier directly
trusts can provide certificates used to evaluate queries. Any
finite length chain of trust can be used, though in practice,
longer chains will be considered less secure.
[0030] In a preferred embodiment, a QCM verifier 230 contains a
strategy for "pushing" or "pulling" certificates given a query. For
example, if a first QCM verifier receives a certificate that it can
not use to evaluate a query, but must send a query to a second QCM
verifier, should it "push" along the certificate, which might be
useful to that second QCM verifier? If the second QCM verifier does
not receive data that it needs, it may "pull" the data from the
first QCM verifier. A strategy for when to perform such "pushing"
and "pulling" should be incorporated in QCM verifiers in a
preferred embodiment.
[0031] An application invokes QCM by giving it a query and a set of
certificates. This input passes through a number of phases, as
shown in FIG. 3. The first phase the input passes through is
parsing, 300. The query and certificates are parsed into the QCM
verifier's abstract syntax, and the syntax and form of the query is
checked.
[0032] After parsing 300, the signatures of the parsed certificates
are verified and their provenance is checked at step 310, that is,
the certificate is checked to ensure that the entity signing is to
be trusted on the matter the certificate concerns. The recovery
phase 320 uses the output of the checker, the inclusions from the
certificates, and the parsed query to form definitions, which are
the best form the available data can be arranged in order to
simplify the query process. When the definitions are combined with
the local policy definitions in the database local to the QCM
verifier in step 330, the result is a program, which is passed
through an optimizer 340, in order to transform the program into a
more efficient program and decide the form of any remote queries
that will be sent during the set evaluation phase 350.
[0033] The program is then run through a set evaluator which can
send queries and receive values from authenticated data servers, in
the remote evaluation phase 360. Queries can be sent in parallel
for remote evaluation. When the set evaluation phase is completed,
a value is returned which is the result of the query.
[0034] When the authenticated data server performs online signing,
a query simply arrives at the authenticated data server and is sent
to a local evaluator, which results in an unsigned value. That
value can then be signed and returned across the network. When the
authenticated data server can not perform online signing, the query
is parsed at the authenticated data server and the value of the
query is calculated. However, the value is discarded, and the set
of certificates used by the authenticated data server to calculate
the value of the query (which certificates have already been signed
using the authenticated data server's public key) are returned to
the QCM verifier. The QCM verifier can then verify that the
certificates were sent by the authenticated data server, and use
the certificates to evaluate the query itself as it used the
original certificates presented. This will result in the same value
achieved at the authenticated data server.
[0035] In order to provide for certificate revocation, in a
preferred embodiment the internal language of QCM will include both
positive variables and negative variables, and positive names and
negative names, as shown in FIG. 4. The clauses of QCM's
denotational semantics are given in FIG. 5. QCM will also include
polarity rules which will govern operations including the polarized
variables and names, and allow for both positive and negative
certificates. These rules are given in the table in FIG. 6.
[0036] A positive certificate would include positive information
about the system, for example "V certifies that K.sub.A is Ann's
public key" or "V certifies that Ann may use resource X." A
negative certificate would denote negative information about the
system, for example "V certifies that the certificate with serial
number 315' has been revoked." "V certifies that Ann's permission
to use resource X has been revoked." Because of the structure of
QCM and the differing treatment of positive and negative
certificates, the language has the monotonicity property. Thus, the
present invention avoids the prior art security loophole which
allows an adversary to present only certain certificates thus foil
a security measure while still allowing for revocation. Because
both positive and negative certificates are handled by the same
internal system, complexity and processing time are cut down.
[0037] The security aspects of this invention can be combined with
other, broader functionality. For example, in the mortgage
application example previously discussed, secure information must
be transferred, which could be verified by certificates (for
example, the mortgage application can be signed). However, there
may be other situations in which an extension of the QCM system can
be used both to verify and to guide the process. For example, the
potential mortgage grantor would like a secure response to credit
report inquiries and bank account queries. The credit agency and
applicant's bank will require applicant's permission before
disclosing this information. The QCM system can be used to allow
the credit agency and bank to send the information securely after
querying the applicant for permission for a particular potential
mortgage grantor to receive the information. The same push and pull
of certificates for security can be used to provide the applicant
with requests, or, to provide for information if the applicant has
pre-approved of requests for the applicant's permission to disclose
the information. Both the security of information and the flow of
information can be structured by the use of the QCM system in this
extended functionality.
* * * * *
References