| Method for integrating online and offline cryptographic signatures and providing secure revocation -> Monitor Keywords |
|
|
 
Method for integrating online and offline cryptographic signatures and providing secure revocationRelated Patent Categories: Electrical Computers And Digital Processing Systems: Support, Multiple Computer Communication Using Cryptography, Particular Communication Authentication Technique, Authentication By Digital Signature Representation Or Digital WatermarkMethod for integrating online and offline cryptographic signatures and providing secure revocation description/claimsThe Patent Description & Claims data below is from USPTO Patent Application 20060090075, Method for integrating online and offline cryptographic signatures and providing secure revocation. Brief Patent Description - Full Patent Description - Patent Application Claims
[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. Continue reading about Method for integrating online and offline cryptographic signatures and providing secure revocation... Full patent description for Method for integrating online and offline cryptographic signatures and providing secure revocation Brief Patent Description - Full Patent Description - Patent Application Claims Click on the above for other options relating to this Method for integrating online and offline cryptographic signatures and providing secure revocation patent application. ###  How KEYWORD MONITOR works... a FREE service from FreshPatents1. Sign up (takes 30 seconds). 2. Fill in the keywords to be monitored. 3. Each week you receive an email with patent applications related to your keywords. Start now! - Receive info on patent apps like Method for integrating online and offline cryptographic signatures and providing secure revocation or other areas of interest. ### Previous Patent Application: Encryption communication system Next Patent Application: Method for accounting a user accessing a prepaid service via an access control unit Industry Class: Electrical computers and digital processing systems: support ### FreshPatents.com Support Thank you for viewing the Method for integrating online and offline cryptographic signatures and providing secure revocation patent info. IP-related news and info Results in 0.67701 seconds Other interesting Feshpatents.com categories: Accenture , Agouron Pharmaceuticals , Amgen , AT&T , Bausch & Lomb , Callaway Golf 174 |
 * Protect your Inventions * US Patent Office filing 
PATENT INFO |
|
