US20060090075A1 - Method for integrating online and offline cryptographic signatures and providing secure revocation - Google Patents

Method for integrating online and offline cryptographic signatures and providing secure revocation Download PDF

Info

Publication number
US20060090075A1
US20060090075A1 US11/295,417 US29541705A US2006090075A1 US 20060090075 A1 US20060090075 A1 US 20060090075A1 US 29541705 A US29541705 A US 29541705A US 2006090075 A1 US2006090075 A1 US 2006090075A1
Authority
US
United States
Prior art keywords
certificates
query
verifier
data server
authenticated data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/295,417
Inventor
Trevor Jim
Carl Gunter
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to US11/295,417 priority Critical patent/US20060090075A1/en
Publication of US20060090075A1 publication Critical patent/US20060090075A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102Entity profiles
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99931Database or file accessing
    • Y10S707/99933Query processing, i.e. searching
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99931Database or file accessing
    • Y10S707/99939Privileged access

Definitions

  • the present invention relates generally to secured communications and, more particularly, to a scheme for increasing the efficiency of policy checking for verifying 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.
  • PKI public key infrastructure
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 .
  • the verifier 30 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.
  • 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.
  • both the verifier 30 and the application 20 or user 10 are examining the policy.
  • 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.
  • 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 17 th Symposium on Security and Privacy , pp. 164-173 IEEE Computer Society Press, 1996) and SPKI/SDSI (described in C. M.
  • 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.
  • 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.
  • 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 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.
  • Ann may be able to receive a certificate verifying that Ann is a member of the group school individuals.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 1 is a block functional and data flow diagram for a prior art security architecture.
  • FIG. 2 is a block functional and data flow diagram for a security architecture according to the present invention.
  • FIG. 3 is a flowchart of the query evaluation according to the present invention.
  • FIG. 4 is a table of the internal language according to the present invention.
  • FIG. 5 is a table of the clauses of the internal language according to the present invention.
  • FIG. 6 is a table of the polarity rules for the internal language according to the present invention.
  • QCM Query Certificate Manager
  • QCM is a language based upon the language of sets.
  • 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.
  • 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.
  • the network 270 is the Internet.
  • 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>.
  • 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.
  • the QCM verifier 230 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.
  • 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.
  • the 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.
  • the data to be verified can be key bindings, access control information, or any other data for which verification is necessary.
  • 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.
  • 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.
  • “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.
  • 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.
  • 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.
  • 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.
  • 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 .
  • 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.
  • a query 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.
  • the query 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.
  • 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 .
  • a positive certificate would include positive information about the system, for example “V certifies that K 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.
  • the security aspects of this invention can be combined with other, broader functionality.
  • secure information must be transferred, which could be verified by certificates (for example, the mortgage application can be signed).
  • certificates for example, the mortgage application can be signed.
  • an extension of the QCM system can be used both to verify and to guide the process.
  • 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.

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.

Description

  • 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
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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”, 7th 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.
  • 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
  • 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.
  • 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.
  • 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
  • FIG. 1 is a block functional and data flow diagram for a prior art security architecture.
  • FIG. 2 is a block functional and data flow diagram for a security architecture according to the present invention.
  • FIG. 3 is a flowchart of the query evaluation according to the present invention.
  • FIG. 4 is a table of the internal language according to the present invention.
  • FIG. 5 is a table of the clauses of the internal language according to the present invention.
  • FIG. 6 is a table of the polarity rules for the internal language according to the present invention.
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • A positive certificate would include positive information about the system, for example “V certifies that KA 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.
  • 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.

Claims (6)

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.
US11/295,417 1999-04-30 2005-12-06 Method for integrating online and offline cryptographic signatures and providing secure revocation Abandoned US20060090075A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/295,417 US20060090075A1 (en) 1999-04-30 2005-12-06 Method for integrating online and offline cryptographic signatures and providing secure revocation

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13193799P 1999-04-30 1999-04-30
US09/561,806 US6981148B1 (en) 1999-04-30 2000-04-29 Method for integrating online and offline cryptographic signatures and providing secure revocation
US11/295,417 US20060090075A1 (en) 1999-04-30 2005-12-06 Method for integrating online and offline cryptographic signatures and providing secure revocation

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US09/561,806 Continuation US6981148B1 (en) 1999-04-30 2000-04-29 Method for integrating online and offline cryptographic signatures and providing secure revocation

Publications (1)

Publication Number Publication Date
US20060090075A1 true US20060090075A1 (en) 2006-04-27

Family

ID=35482791

Family Applications (2)

Application Number Title Priority Date Filing Date
US09/561,806 Expired - Lifetime US6981148B1 (en) 1999-04-30 2000-04-29 Method for integrating online and offline cryptographic signatures and providing secure revocation
US11/295,417 Abandoned US20060090075A1 (en) 1999-04-30 2005-12-06 Method for integrating online and offline cryptographic signatures and providing secure revocation

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US09/561,806 Expired - Lifetime US6981148B1 (en) 1999-04-30 2000-04-29 Method for integrating online and offline cryptographic signatures and providing secure revocation

Country Status (1)

Country Link
US (2) US6981148B1 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090208015A1 (en) * 2008-02-15 2009-08-20 Microsoft Corporation Offline consumption of protected information
US20100180027A1 (en) * 2009-01-10 2010-07-15 Barracuda Networks, Inc Controlling transmission of unauthorized unobservable content in email using policy
US20130007446A1 (en) * 2006-05-04 2013-01-03 Research In Motion Limited System and method for processing certificates located in a certificate search

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050246766A1 (en) * 2004-04-30 2005-11-03 Kirkup Michael G System and method for handling certificate revocation lists
US7512974B2 (en) * 2004-09-30 2009-03-31 International Business Machines Corporation Computer system and program to update SSL certificates
US7886144B2 (en) * 2004-10-29 2011-02-08 Research In Motion Limited System and method for retrieving certificates associated with senders of digitally signed messages
US7665121B1 (en) * 2005-10-11 2010-02-16 Symantec Corporation Multi-policy security auditing system and method
US8316230B2 (en) * 2005-11-14 2012-11-20 Microsoft Corporation Service for determining whether digital certificate has been revoked
US10624019B2 (en) * 2016-08-30 2020-04-14 Hyungkoo Lee Wireless transceiver system
US11671264B1 (en) * 2020-09-18 2023-06-06 Amazon Technologies, Inc. Validating certificate information before signing

Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5016274A (en) * 1988-11-08 1991-05-14 Silvio Micali On-line/off-line digital signing
US5960083A (en) * 1995-10-24 1999-09-28 Micali; Silvio Certificate revocation system
US6035402A (en) * 1996-12-20 2000-03-07 Gte Cybertrust Solutions Incorporated Virtual certificate authority
US6134658A (en) * 1997-06-09 2000-10-17 Microsoft Corporation Multi-server location-independent authentication certificate management system
US6202157B1 (en) * 1997-12-08 2001-03-13 Entrust Technologies Limited Computer network security system and method having unilateral enforceable security policy provision
US6212640B1 (en) * 1999-03-25 2001-04-03 Sun Microsystems, Inc. Resources sharing on the internet via the HTTP
US6247127B1 (en) * 1997-12-19 2001-06-12 Entrust Technologies Ltd. Method and apparatus for providing off-line secure communications
US6292893B1 (en) * 1995-10-24 2001-09-18 Silvio Micali Certificate revocation system
US6321333B1 (en) * 1998-10-14 2001-11-20 Wave Systems Corporation Efficient digital certificate processing in a data processing system
US6353886B1 (en) * 1998-02-04 2002-03-05 Alcatel Canada Inc. Method and system for secure network policy implementation
US6430688B1 (en) * 1998-12-22 2002-08-06 International Business Machines Corporation Architecture for web-based on-line-off-line digital certificate authority
US6446206B1 (en) * 1998-04-01 2002-09-03 Microsoft Corporation Method and system for access control of a message queue
US6564320B1 (en) * 1998-06-30 2003-05-13 Verisign, Inc. Local hosting of digital certificate services

Patent Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5016274A (en) * 1988-11-08 1991-05-14 Silvio Micali On-line/off-line digital signing
US6292893B1 (en) * 1995-10-24 2001-09-18 Silvio Micali Certificate revocation system
US5960083A (en) * 1995-10-24 1999-09-28 Micali; Silvio Certificate revocation system
US6035402A (en) * 1996-12-20 2000-03-07 Gte Cybertrust Solutions Incorporated Virtual certificate authority
US6308277B1 (en) * 1996-12-20 2001-10-23 Gte Cybertrust Solutions Incorporated Virtual certificate authority
US6134658A (en) * 1997-06-09 2000-10-17 Microsoft Corporation Multi-server location-independent authentication certificate management system
US6202157B1 (en) * 1997-12-08 2001-03-13 Entrust Technologies Limited Computer network security system and method having unilateral enforceable security policy provision
US6247127B1 (en) * 1997-12-19 2001-06-12 Entrust Technologies Ltd. Method and apparatus for providing off-line secure communications
US6353886B1 (en) * 1998-02-04 2002-03-05 Alcatel Canada Inc. Method and system for secure network policy implementation
US6446206B1 (en) * 1998-04-01 2002-09-03 Microsoft Corporation Method and system for access control of a message queue
US6564320B1 (en) * 1998-06-30 2003-05-13 Verisign, Inc. Local hosting of digital certificate services
US6321333B1 (en) * 1998-10-14 2001-11-20 Wave Systems Corporation Efficient digital certificate processing in a data processing system
US6430688B1 (en) * 1998-12-22 2002-08-06 International Business Machines Corporation Architecture for web-based on-line-off-line digital certificate authority
US6212640B1 (en) * 1999-03-25 2001-04-03 Sun Microsystems, Inc. Resources sharing on the internet via the HTTP

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130007446A1 (en) * 2006-05-04 2013-01-03 Research In Motion Limited System and method for processing certificates located in a certificate search
US20130013919A1 (en) * 2006-05-04 2013-01-10 Research In Motion Limited Updating certificate status in a system and method for processing certificates located in a certificate search
US8719565B2 (en) * 2006-05-04 2014-05-06 Blackberry Limited System and method for processing certificates located in a certificate search
US8850188B2 (en) * 2006-05-04 2014-09-30 Blackberry Limited Updating certificate status in a system and method for processing certificates located in a certificate search
US20090208015A1 (en) * 2008-02-15 2009-08-20 Microsoft Corporation Offline consumption of protected information
US20100180027A1 (en) * 2009-01-10 2010-07-15 Barracuda Networks, Inc Controlling transmission of unauthorized unobservable content in email using policy

Also Published As

Publication number Publication date
US6981148B1 (en) 2005-12-27

Similar Documents

Publication Publication Date Title
US20060090075A1 (en) Method for integrating online and offline cryptographic signatures and providing secure revocation
AU2003259136B2 (en) A remote access service enabling trust and interoperability when retrieving certificate status from multiple certification authority reporting components
Adams et al. Understanding public-key infrastructure: concepts, standards, and deployment considerations
US7028180B1 (en) System and method for usage of a role certificate in encryption and as a seal, digital stamp, and signature
JP5190036B2 (en) System and method for electronic transmission, storage and retrieval of authenticated documents
US5748738A (en) System and method for electronic transmission, storage and retrieval of authenticated documents
Brunner et al. Did and vc: Untangling decentralized identifiers and verifiable credentials for the web of trust
CN1503932A (en) Method and system for obtaining digital signatures
US20020143987A1 (en) Message management systems and method
Oppliger et al. Using attribute certificates to implement role-based authorization and access controls
Li et al. Automated trust negotiation using cryptographic credentials
WO2002049311A2 (en) Pseudonym credentialing system
Eldridge Internet commerce and the meltdown of certification authorities: Is the Washington State solution a good model
Xenitellis The open–source pki book
Sun et al. XML and web services security
Chen et al. Secure transaction protocol analysis: models and applications
Baldwin Enhanced accountability for electronic processes
Lim Digital signature, certification authorities and the law
Kefallinos et al. Secure PKI-enabled e-government infrastructures implementation: the SYZEFXIS-PKI case
Lekkas et al. Outsourcing digital signatures: a solution to key management burden
Knox et al. Digital credentials with privacy‐preserving delegation
Lekkas et al. Withdrawing a declaration of will: Towards a framework for Digital Signature Revocation
Jarvis Protecting sensitive credential content during trust negotiation
Jones et al. TRUST MANAGEMENT IN OPEN SYSTEMS(TMOS)
Wood PKI, The What, The Why, and The How

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION