US20070220259A1 - Verification of electronic signatures - Google Patents
Verification of electronic signatures Download PDFInfo
- Publication number
- US20070220259A1 US20070220259A1 US11/366,060 US36606006A US2007220259A1 US 20070220259 A1 US20070220259 A1 US 20070220259A1 US 36606006 A US36606006 A US 36606006A US 2007220259 A1 US2007220259 A1 US 2007220259A1
- Authority
- US
- United States
- Prior art keywords
- electronic signature
- certificate
- valid
- certificates
- countersignatures
- 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.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3825—Use of electronic signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic 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/3263—Cryptographic 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
- H04L9/3265—Cryptographic 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 using certificate chains, trees or paths; Hierarchical trust model
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic 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/3297—Cryptographic 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 time stamps, e.g. generation of time stamps
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
Definitions
- Electronic commerce is an emerging method of transacting business between parties across local, wide area, and global networks.
- electronic commerce in order for electronic commerce to be considered a safe and reliable means of doing business, there must be suitable controls in place to protect the transaction and to ensure the trust and confidence of both parties in the transaction.
- a European Directive defines an electronic signature as “data in electronic form which is attached to or logically associated with other electronic data and which serves as a method of authentication”, although other definitions or variations of this definition are also employed.
- an electronic signature can provide evidence that a commitment has been explicitly endorsed under a signature policy, at a given time, by an identified signer, and optionally, a role.
- the signature policy specifies the technical and procedural requirements on signature creation and verification in order to meet a particular business need.
- a given legal framework may recognize a particular signature policy as meeting its statutory, regulatory, and judicial requirements.
- a specific signature policy may be recognized by courts of law as meeting the legal requirements for electronic commerce. Accordingly, within this legal framework, a holder of an electronic contract can provide evidence that a contract was electronically signed by another party and is therefore enforceable against that party.
- Verification of basic electronic signatures generally involved certain cryptographic checks. However, verification becomes more complex a problem when one must account for revocation or expiration of electronic signatures over time. Furthermore, addition of advanced features to electronic signatures, such as qualifying properties, timestamps, and countersignatures, can contribute to long term signature validity and non-repudiation of an original signature but such features can also complicate the signature validity verification process. Existing approaches fail to provide a robust and effective verification of such advanced electronic signatures, particularly in the presence of multiple timestamps and countersignatures.
- Implementations described and claimed herein address the foregoing problems by providing a system for verifying an electronic signature.
- the electronic signature may be associated with timestamps, each timestamp including a time value.
- a timestamp verification module detects invalid certificates in a certificate chain of the electronic signature and records an earliest invalidity time value of the invalid certificates. The verification module also verifies the timestamps associated with the electronic signature and records the time value of the earliest valid timestamp.
- a declaration module declares the electronic signature as valid if the time value of the earliest valid timestamp is earlier than the earliest invalidity time value of the one or more invalid certificates.
- the electronic signature may alternatively or additionally be associated with countersignatures.
- a countersignature verification module verifies the countersignatures associated with the electronic signature, and the declaration module declares the electronic signature as valid if all of the countersignatures are determined to be valid.
- articles of manufacture are provided as computer program products.
- One implementation of a computer program product provides a computer program storage medium readable by a computer system and encoding a computer program.
- Another implementation of a computer program product may be provided in a computer data signal embodied in a carrier wave by a computing system and encoding the computer program.
- Other implementations are also described and recited herein.
- FIG. 1 illustrates an example process for generating and verifying electronically signed data.
- FIG. 2 illustrates input to an example verifier of an electronically signed document.
- FIG. 3 illustrates example operations for verifying electronically signed data.
- FIG. 4 illustrates an example system that may be useful in implementing the described technology.
- FIG. 1 illustrates an example process 100 for generating and verifying electronically signed data.
- a signer 102 associates an electronic signature with an electronic document.
- An electronic signature can be used with any kind of data (e.g., a document, a message, a file, etc.), whether encrypted or not, to authenticate the identity of the signer or sender of the data and to ensure that the original content of the data is unchanged from the time of signing.
- the signer 102 creates an electronic signature by executing a hashing algorithm on the digital data that defines a document.
- Example hashing algorithms may include without limitation variations of Secure Hash Algorithm (SHA), Message Digest Algorithm (MDA), and Race Integrity Primitives Evaluation Message Digest (RIPEMD).
- SHA Secure Hash Algorithm
- MDA Message Digest Algorithm
- RIPEMD Race Integrity Primitives Evaluation Message Digest
- Execution of the hashing algorithm on the digital data yields a hash result, often referred to as a “hash” or digest.
- the signer 102 can then use a private key obtained from a public-private key authority to encrypt the signature digest.
- the encrypted signature digest represents a basic component of an electronic signature (as signature value) associated with the data.
- the signature value can be transmitted or stored in association with the digital data.
- a recipient 116 can then use a verifier 118 to verify the received digital data.
- the verifier 118 can use the signer's public key (available from the signer, a public-private key authority, or some other source) to decrypt the encrypted signature digest associated with the document (ostensibly yielding the original signature digest).
- the verifier 118 can also generate a hash of the received digital data. If the hash of the received digital data and the decrypted signature digest match, validity of the basic electronic signature, and therefore the received digital data, is considered verified, at least at a basic level. That is, absent other security problems, the signature is considered to be that of the signer and the document is unchanged from the time of signing.
- the signer 102 creates a signed document 104 that can be verified at some level by a recipient 116 or a verifier 118 .
- the electronic signature can be associated with the document in several different ways, including: embedding the electronic signature in the document, embedding the document in the electronic signature, referencing the document in the electronic signature, referencing the electronic signature in the document, and storing the document and electronic signature in association with each other (e.g., in the same file system directory or folder).
- the verifier 118 making the assumption that the public key used to decrypt the encrypted signature digest actually belongs to the signer and is still valid. However, the public key may no longer be valid (e.g., the corresponding private key has been stolen, the signer is no longer authorized to use the private key, etc.).
- the electronic signature can be certified by one or more trusted parties (such as certificate authorities 106 or some other certification entities, collectively referred to herein as “certificate signers”) to attest that the public key belongs to a specified signer.
- a certificate uses an electronic signature to bind together a public key with an identity—information such as the name of a person or an organization, the public key owner's address, etc.
- An example certificate may include the public key being signed, a name or identifier of a person, a computer or an organization, a validity period, and an address (e.g., a URL) of a revocation center, although other forms of certificates may be employed.
- PKI public key infrastructure
- data can be certified by a trusted certificate authority (CA).
- CA trusted certificate authority
- a certificate can be signed by the signer (a self-signed certificate) or other users (“endorsements”). In either case, electronic signatures on a certificate are attestations by the certificate signer that the identity information and the public key belong together.
- Certificates can be used for the large-scale use of public key cryptography. Securely exchanging secret keys among a multitude of users becomes impractical and unsafe without additional protections. For example, if a first party wants others to be able to send him or her secret messages, the first party can publish a public key associated with the first party. Sandra possessing the public key can then send the party secure information. Unfortunately, a second party can also publish a public key claiming that the public key belongs to the first party and can therefore receive secret messages intended only for the first party.
- the first party builds his or her public key into a certificate and has it digitally signed by a trusted third party (e.g., a certificate authority)
- a trusted third party e.g., a certificate authority
- anyone who trusts the trusted third party can merely check the certificate to see whether the trusted third party has certified that the embedded public key belongs to the first party.
- a sender of secret information to the first party can have confidence that only the first party can access the secret message.
- certification can allow a verifier to have confidence that an electronic signature actually belongs to the signer.
- chains of certificates may be employed.
- the first party may not be familiar with a second party's certificate authority, so the second party's certificate may also include his or her certificate authorities public key signed by a “higher level” certificate authority (e.g., a commercial certificate authority), which might be recognized by the first party.
- a “higher level” certificate authority e.g., a commercial certificate authority
- This process can lead to a chain of certificates, all of which are certified by an ultimately trusted party, that in combination attest that a public key belongs to a specified individual.
- certification has its own security concerns. Some certificates have a limited validity period, outside of which the certificate is considered expired. In addition, a certificate may be revoked, for example, if it is discovered that its related private key has been compromised (e.g., the certificate authority's systems have been hacked) or if the relationship between a signer and a specific public key embedded in the certificate is discovered to be incorrect or has changed (e.g., if a person changes jobs or names).
- One method for determining whether a certificate has been revoked is compare the certificate against a certificate revocation list (CRL)—a list of revoked or cancelled certificates.
- Another method of determining the validity of a certificate is to query the certificate authority using the Online Certificate Status Protocol (OCSP) to obtain the status of a specific certificate.
- OCSP Online Certificate Status Protocol
- certification provides some confidence that the electronic signature associated with a document is that of a specified signer, it is possible that the certificate itself had expired or was revoked (collectively referred to as “invalidated”) at the time it was associated with the electronic signature.
- the signer 116 electronically signs the document and has the electronic signature certified with a revoked certificate. Because the certificate was revoked at the time the signature was certified, the verifier 118 cannot sufficiently demonstrate for evidentiary purposes that the signer 116 actually signed the document (e.g., the hacker of the certificate authority could have stolen the certificate, signed the document, and certified his own signature as that of the signer 116 ).
- timestamps can be used to enhance the security of advanced electronic signatures.
- a timestamp is a type of electronic signature that can be obtained from a trusted third-party (e.g., a timestamp authority 110 ) to attest that the certificate or certificate chain of the electronic signature existed and was valid at the time specified in the timestamp.
- the timestamp authority 110 verifies the electronic signature and the certificate chain. If these are valid, then the timestamp authority 110 hashes a collection of timestamp data, which includes a time value and the electronic signature digest, and associates the timestamp hash with the electronic signature.
- the timestamp can also be certified by one or more trusted third parties.
- one or more timestamps associated with the electronic signature can be verified to determine whether the electronic signature and certificates were valid at the time of signing. If no certificate of the electronic signature was invalid at the time specified in the timestamp, then validity of the electronic signature is said to be verified as of the time specified in the timestamp. If the certificate or certificate chain of the electronic signature was revoked after the time of the timestamp, the trust in the electronic signature is unimpaired because validity has at least been verified at one point in time.
- certificates associated with timestamps may also expire or be revoked. This situation does not mean that the electronic signature is invalid, just that a timestamp of the electronic signature cannot be trusted.
- a possessor of an electronically signed document may submit the electronic signature to one or more timestamp authorities over time, thereby associating multiple timestamps with the electronic signature. For example, a company may submit its existing contracts to a timestamp authority on an annual basis to reinforce the validity of the electronically signed document. In this manner, the company obtains multiple attestations that at a given time the electronic signature was valid. If one or more timestamps are found to be revoked, then it is likely that another timestamp remains valid, thereby preserving the validity of the electronic signature, at least at one point in time.
- an electronic signature value in an advanced electronic signature may be associated with one or more electronic countersignatures from third parties (e.g., a countersignature authority or some other party, collectively referred to as “countersignature entities”).
- An electronic countersignature represents approval or notarization of the original signer's electronic signature by another party.
- An electronic countersignature may also be certified by one or more certificates. For example, execution of a document may require an electronic signature from two or more parties before it is considered legally binding. Accordingly, a countersignature represents an electronic signature of an identified second party and is associated with the same data electronically signed by the identified first party. A countersignature effectively signs an existing signature associated with the data.
- One or more countersignatures may be associated with a single document.
- An electronic countersignature may also be associated with its own timestamp(s) and/or countersignature(s).
- a signed document 114 associated with an electronic signature certificate (or chain of certificates), zero or more time stamps, and zero or more countersignatures can then be transmitted to a recipient 116 .
- the verifier 118 e.g., a verification module of a document manager, a file manager, an email client, etc.
- the verifier 118 can receive the signed document 114 and test the electronic signature, timestamps, and/or countersignatures to verify the validity of the electronic signature.
- an implementation of the verifier 118 can declare the electronic signature as “valid”, “valid at a specified point in time”, or “invalid” (i.e., not verifiable, which suggests that the electronic signature cannot be trusted).
- the verifier 118 may also generate other declarations about the verification status on the electronic signature.
- the verifier 118 can provide more detailed results: Result Description InvalidCertificateChain One of the certificates on the certificate chain is invalid (revoked or expired) and no timestamps were found to evidence validity at some previous time InvalidCertificateStatusUnknown Full verification of the signing certificate could not be performed (e.g., could not connect online to check the certificate chain for revocation) InvalidCertificateUsage The intended usage of the certificate used for signing does not satisfy the usage requirements InvalidCounterSignature Signature contains at least one invalid countersignature InvalidQualifyingProperties The qualifying properties inside the signature are invalid (e.g., schema does not match or mandatory parts are not present) InvalidSignatureValue The signature value was crypto- graphically invalid (e.g., the data was tampered with) InvalidTimeStamp Signature contains at least one invalid timestamp Valid Signature is fully valid ValidAtSigning There are invalid certificates on the certificate chain but the signature is valid because it contains a valid timestamp providing
- FIG. 2 illustrates input to an example verifier of an electronically signed document 202 .
- An electronic signature 204 is associated with the electronic document 202 . Such association can be achieved through a variety of methods, as discussed above, although for the purposes of the description, it will be assumed that the electronic signature is embedded in the electronic document 202 .
- the electronic signature 204 includes a signature value 206 (with or without a certificate), zero or more timestamps 210 (with or without certificates), and zero or more countersignatures 218 (with or without certificates).
- the signature value 206 is generated by hashing the digital data that defines the electronic document 202 to create a digest of the electronic signature 204 and then encrypting the digest using the signer's private key.
- the signature value 206 may also be certified by a certificate 208 .
- the certificate 208 may be a single certificate or a chain of certificates. As discussed previously, one or more certificates associated with the signature value 206 may be invalid at the time of signing (or at the time of verification).
- the electronic signature 204 may also be associated with one or more timestamps 210 , as shown in FIG. 2 .
- Timestamps can be added by a timestamp authority, which optionally tests the electronic signature value 206 and the certificates 208 associated therewith.
- An example timestamp is shown in an exploded view in timestamp 212 to include the digest 214 of the electronic signature value 206 and a time value 216 (e.g., include time and date information).
- Other parameters can also be combined in the timestamp 212 , including without limitation qualifying properties, the hashing algorithm type, etc.
- the timestamp authority receives the digest 214 of the signature value 206 , combines the digest 214 with a time value 216 (e.g., including time and date information) and potentially other parameters, hashes the combination, encrypts the hashed combination with the timestamp authority's private key (signs it), and sends the signed result back to the original signer for association with the document 202 .
- the timestamp authority receives the electronic signature 204 and verifies the electronic signature value 206 and certificates 208 . If these are valid, the timestamp authority hashes the electronic signature value 206 to obtain a new signature digest 214 .
- the timestamp authority then hashes a combination of the new signature digest 214 , the time value 216 , and potentially other parameters, encrypts the hashed combination with the timestamp authority's private key (signs it), and sends the signed result back to the original signer for association with the document 202 .
- the timestamp 212 may also be certified by one or more certificates 218 and may be associated with its own timestamps and countersignatures.
- Each timestamp 210 attests to a time (e.g., a date and time value) at which the electronic signature existed in its specific form. Later, the one or more timestamps 210 can be verified by a verifier 221 to determine the earliest time at which the electronic signature was valid in association with the document 202 .
- a verifier 221 For example, company A has an agreement electronically signed by company B and wishes to enforce the agreement in a court of law. Company B repudiates the agreement, claiming that the signature is not valid, pointing out that one of the certificates in the certificate chain of the electronic signature had been revoked. If company A can verify a timestamp with a time prior to the revocation date, company A can adduce reliable evidence that the electronic signature was valid at least at one point in time and is therefore enforceable.
- the electronic signature 204 may also be associated with one or more countersignatures 218 , as shown in FIG. 2 .
- Countersignatures can be added by a countersignature authority, which can optionally test the electronic signature value 206 and the certificates 208 associated therewith.
- An example countersignature is shown in an exploded view in countersignature 220 to include the digest 224 of the electronic signature value 206 .
- Other parameters can also be combined in the countersignature 220 , including without limitation qualifying properties, the hashing algorithm type, etc.
- the countersignature authority receives the digest 224 of the signature value 206 , hashes the digest 224 , encrypts the hashed digest with the countersignature authority's private key, and sends the encrypted result (i.e., countersignature 220 ) back to the signer for association with the document 202 .
- the countersignature authority receives the electronic signature 204 and verifies the electronic signature value 206 and certificates 208 . If these are valid, the countersignature authority hashes the electronic signature value 206 to obtain a new signature digest 224 .
- the countersignature authority then hashes the new signature digest 224 , encrypts the hashed result with the countersignature authority's private key (signs it), and sends the signed result (countersignature 220 ) back to the original signer for association with the document 202 .
- the countersignature 220 may also be certified by one or more certificates 222 and may be associated with its own timestamps and countersignatures.
- Each countersignature 220 represents an approval or notarization of the electronic signature 204 associated with the document 202 .
- the parents' signatures can be provided as electronic countersignatures 218 .
- the verifier 221 validates all of the countersignatures 218 .
- the electronic signature 204 may not include a set of one or more timestamps or a set of one or more countersignatures. Nevertheless, verification of the electronic signature 204 can be made more robust by inclusion of one or more of these components.
- FIG. 3 illustrates example operations 300 for verifying electronically signed data.
- a receiving operation 302 receives signed data, such as a signed document or message, in a form similar to that shown in FIG. 2 .
- the signed data may include certificates associated with the electronic signature, timestamps, and/or countersignatures. Examples of signed data may include with limitation audit trails of business transactions, medical guidelines in an electronic medical system, Internet tax return submissions signed using a citizen's electronic ID car or SOAP (Simple Object Access Protocol) messages used for communication between Web services, microfilm images in paper publications, etc.
- SOAP Simple Object Access Protocol
- a verification operation 304 verifies the basic electronic signature value.
- verification of the basic electronic signature includes using the signer's public key to decrypt the electronic signature value associated with the signed data to obtain the electronic signature digest.
- the verification operation 304 also generates a hash of the received data. If the hash matches the electronic signature digest, then the basic electronic signature value is considered verified. If the hash does not match the electronic signature digest, then the verification operation 304 declares the validity of the basic electronic signature value to be “unverifiable”, which means that the electronic signature associated with the data may not be trustworthy because the data or the signature itself may have been tampered with.
- a validation operation 306 examines any qualifying properties that may be present for the electronic signature.
- qualifying properties may include without limitation signing location and time, the signer's role in a company, an indication of the type of commitment expressed by signing (e.g., document author, approver, executor of a contract, etc.), and other information.
- the signature verification policy specifies how particular qualifying properties need to be validated. For example, such a policy may require a certain location at which the signature must have been produced.
- Another validation operation 308 validates the certificate chain (e.g., one or more certificates) associated with the basic electronic signature value.
- the validation operation 308 compares the current time (e.g., date and time) to the validity period of the certificate to determine whether the certificate has expired.
- the validity operation 308 consults a revocation list or the certificate authority to determine whether the certificate has been revoked. If one or more certificates are determined to be expired or revoked, a decision operation 312 will detect the invalidity and direct processing to a validation operation 316 if any timestamps are associated with the electronic signature.
- the expiration time, based on the validity period of the certificate, and the revocation time, based on the revocation information from the revocation list or certificate authority are collectively termed “invalidity times”.
- a certificate represents an electronic signature that binds together a public key with an identity.
- the validation operation 308 works its way up the certificate chain, from least trusted certificate to most trusted certificate. For example, the validation operation 308 can obtain a public key from the certificate authority associated with the least trusted certificate in the chain. The validation operation 308 then decrypts the certificate using this public key and extracts a certified public key from the decrypted certificate. If the public key used to verify the electronic signature value and the certified public key match, and the certificate is not expired and has not been revoked by the certificate authority, then the certificate is deemed valid. If the certificate is determined to be currently invalid, the time (e.g., date and time) that the certificate expired or was revoked is recorded.
- the time e.g., date and time
- the verification operation 308 can obtain a public key from the certificate authority associated with the next least trusted certificate in the chain.
- the validation operation 308 then decrypts the certificate using this public key and extracts a certified public key from the decrypted certificate. If the public key used to verify the lower level certificate and the current certified public key match, and the current certificate is not expired and has not been revoked by the certificate authority, then the certificate is deemed valid. This processing continues up the certificate chain until the certificate of the most trusted certificate authority is verified, at which point the certificate chain is considered valid.
- the certificate usage is evaluated (e.g., some certificates are not intended for data signing) in accordance with an intended usage parameter in the certificate. If any certificate is determined to be corrupted (e.g., the data has been tampered with, corrupted during transmission, etc.), then the validity of the certificate is not verifiable and therefore neither is the validity of the electronic signature.
- the decision operation 312 determines whether any of the certificates in the certificate chain were found to be invalid (e.g., revoked or expired). If not, then the electronic signature is declared valid in declaration operation 314 .
- certain countersignature verification operations such as those described with regard to operation 324 and 326 , may be applied to the countersignatures before declaring validity or invalidity.
- the invalidity in the certificate chain generally indicates that the electronic signature cannot be trusted because there is no way to determine whether the certificate chain was valid at the time of signing.
- a validation operation 316 can be initiated to determine whether the certificate chain may have been valid at any previous point in time, which would provide the evidentiary basis for relying on the electronic signature.
- the validation operation 316 attempts to verify one or more timestamps associated with the electronic signature.
- the validation operation 316 decrypts a timestamp using the public key of the timestamp authority to obtain the digest of the electronic signature value and a time value.
- the validation operation 316 determines whether the electronic signature value's digest from the timestamp matches the electronic signature value's digest decrypted from the electronic signature value.
- the validation operation 316 may also test a certificate chain associated with the timestamp. If the electronic signature digests match (and the certificate chain is verified), the time value represents a point in time at which the electronic signature existed in its specific form.
- the validation operation 316 can operate on all of the timestamps associated with the electronic signature (or at least until a timestamp satisfying the test in testing operation 322 is found).
- a selection operation selects the earliest valid timestamp and records the time value as T 1 .
- a determination operation 320 examines the recorded expiration/revocation dates of the certificates in the certificate chain and records the earliest invalidity time as T 2 .
- a decision operation 322 test whether T 1 ⁇ T 2 . If T 1 ⁇ T 2 , then the certificate chain at least was valid at T 1 and is therefore trustworthy. Processing can proceed to verify any countersignatures associated with the electronic signature.
- declaration operation 328 declares that the electronic signature was at least valid at time T 1 and can therefore be trusted.
- T 1 is not less than T 2 , then a declaration operation 330 declares the electronic signature to be invalid (i.e., not verifiable).
- a validation operation 324 attempts to verify all such countersignatures, using the verification techniques for electronics signatures described herein. If all of the countersignatures are verified, then the declaration operation 328 declares that the electronic signature was at least valid at time T 1 and can therefore be trusted. Alternatively, if one of the countersignatures is not verified, then the declaration operation 330 declares the electronic signature to be invalid (i.e., not verifiable).
- the example hardware and operating environment of FIG. 4 for implementing the invention includes a general purpose computing device in the form of a gaming console or computer 20 , including a processing unit 21 , a system memory 22 , and a system bus 23 that operatively couples various system components including the system memory to the processing unit 21 .
- a processing unit 21 There may be only one or there may be more than one processing unit 21 , such that the processor of computer 20 comprises a single central-processing unit (CPU), or a plurality of processing units, commonly referred to as a parallel processing environment.
- the computer 20 may be a conventional computer, a distributed computer, or any other type of computer; the invention is not so limited.
- the system bus 23 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, a switched fabric, point-to-point connections, and a local bus using any of a variety of bus architectures.
- the system memory may also be referred to as simply the memory, and includes read only memory (ROM) 24 and random access memory (RAM) 25 .
- ROM read only memory
- RAM random access memory
- a basic input/output system (BIOS) 26 containing the basic routines that help to transfer information between elements within the computer 20 , such as during start-up, is stored in ROM 24 .
- the computer 20 further includes a hard disk drive 27 for reading from and writing to a hard disk, not shown, a magnetic disk drive 28 for reading from or writing to a removable magnetic disk 29 , and an optical disk drive 30 for reading from or writing to a removable optical disk 31 such as a CD ROM or other optical media.
- a hard disk drive 27 for reading from and writing to a hard disk, not shown
- a magnetic disk drive 28 for reading from or writing to a removable magnetic disk 29
- an optical disk drive 30 for reading from or writing to a removable optical disk 31 such as a CD ROM or other optical media.
- the hard disk drive 27 , magnetic disk drive 28 , and optical disk drive 30 are connected to the system bus 23 by a hard disk drive interface 32 , a magnetic disk drive interface 33 , and an optical disk drive interface 34 , respectively.
- the drives and their associated computer-readable media provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for the computer 20 . It should be appreciated by those skilled in the art that any type of computer-readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, random access memories (RAMs), read only memories (ROMs), and the like, may be used in the example operating environment.
- a number of program modules may be stored on the hard disk, magnetic disk 29 , optical disk 31 , ROM 24 , or RAM 25 , including an operating system 35 , one or more application programs 36 , other program modules 37 , and program data 38 .
- a user may enter commands and information into the personal computer 20 through input devices such as a keyboard 40 and pointing device 42 .
- Other input devices may include a microphone, joystick, game pad, satellite dish, scanner, or the like.
- These and other input devices are often connected to the processing unit 21 through a serial port interface 46 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port, or a universal serial bus (USB).
- a monitor 47 or other type of display device is also connected to the system bus 23 via an interface, such as a video adapter 48 .
- computers typically include other peripheral output devices (not shown), such as speakers and printers.
- the computer 20 may operate in a networked environment using logical connections to one or more remote computers, such as remote computer 49 . These logical connections are achieved by a communication device coupled to or a part of the computer 20 ; the invention is not limited to a particular type of communications device.
- the remote computer 49 may be another computer, a server, a router, a network PC, a client, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 20 , although only a memory storage device 50 has been illustrated in FIG. 4 .
- the logical connections depicted in FIG. 4 include a local-area network (LAN) 51 and a wide-area network (WAN) 52 .
- LAN local-area network
- WAN wide-area network
- Such networking environments are commonplace in office networks, enterprise-wide computer networks, intranets and the Internet, which are all types of networks.
- the computer 20 When used in a LAN-networking environment, the computer 20 is connected to the local network 51 through a network interface or adapter 53 , which is one type of communications device.
- the computer 20 When used in a WAN-networking environment, the computer 20 typically includes a modem 54 , a network adapter, a type of communications device, or any other type of communications device for establishing communications over the wide area network 52 .
- the modem 54 which may be internal or external, is connected to the system bus 23 via the serial port interface 46 .
- program modules depicted relative to the personal computer 20 may be stored in the remote memory storage device. It is appreciated that the network connections shown are example and other means of and communications devices for establishing a communications link between the computers may be used.
- an electronic signature verification module may be embodied by instructions stored in memory 22 and/or storage devices 29 or 31 and processed by the processing unit 21 .
- An electronic signature, a public key, a private key, a digest, a certificate, a timestamp, a countersignature, and other data may be stored in memory 22 and/or storage devices 29 or 31 as persistent datastores.
- the technology described herein is implemented as logical operations and/or modules in one or more systems.
- the logical operations may be implemented as a sequence of processor-implemented steps executing in one or more computer systems and as interconnected machine or circuit modules within one or more computer systems.
- the descriptions of various component modules may be provided in terms of operations executed or effected by the modules.
- the resulting implementation is a matter of choice, dependent on the performance requirements of the underlying system implementing the described technology.
- the logical operations making up the embodiments of the technology described herein are referred to variously as operations, steps, objects, or modules.
- logical operations may be performed in any order, unless explicitly claimed otherwise or a specific order is inherently necessitated by the claim language.
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Computer Security & Cryptography (AREA)
- Accounting & Taxation (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Finance (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Storage Device Security (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
Description
- Electronic commerce is an emerging method of transacting business between parties across local, wide area, and global networks. However, in order for electronic commerce to be considered a safe and reliable means of doing business, there must be suitable controls in place to protect the transaction and to ensure the trust and confidence of both parties in the transaction. For example, it is important that one party can rely on the acceptance of an offer by another party in an electronically conducted transaction within a regime providing effective legal protections.
- In this respect, electronic signatures have been offered as an effective security component in protecting the information of a transaction and providing trust in electronic commerce. A European Directive defines an electronic signature as “data in electronic form which is attached to or logically associated with other electronic data and which serves as a method of authentication”, although other definitions or variations of this definition are also employed. Generally, an electronic signature can provide evidence that a commitment has been explicitly endorsed under a signature policy, at a given time, by an identified signer, and optionally, a role. The signature policy specifies the technical and procedural requirements on signature creation and verification in order to meet a particular business need.
- A given legal framework may recognize a particular signature policy as meeting its statutory, regulatory, and judicial requirements. For example, a specific signature policy may be recognized by courts of law as meeting the legal requirements for electronic commerce. Accordingly, within this legal framework, a holder of an electronic contract can provide evidence that a contract was electronically signed by another party and is therefore enforceable against that party.
- Verification of basic electronic signatures generally involved certain cryptographic checks. However, verification becomes more complex a problem when one must account for revocation or expiration of electronic signatures over time. Furthermore, addition of advanced features to electronic signatures, such as qualifying properties, timestamps, and countersignatures, can contribute to long term signature validity and non-repudiation of an original signature but such features can also complicate the signature validity verification process. Existing approaches fail to provide a robust and effective verification of such advanced electronic signatures, particularly in the presence of multiple timestamps and countersignatures.
- Implementations described and claimed herein address the foregoing problems by providing a system for verifying an electronic signature. The electronic signature may be associated with timestamps, each timestamp including a time value. A timestamp verification module detects invalid certificates in a certificate chain of the electronic signature and records an earliest invalidity time value of the invalid certificates. The verification module also verifies the timestamps associated with the electronic signature and records the time value of the earliest valid timestamp. A declaration module declares the electronic signature as valid if the time value of the earliest valid timestamp is earlier than the earliest invalidity time value of the one or more invalid certificates. The electronic signature may alternatively or additionally be associated with countersignatures. A countersignature verification module verifies the countersignatures associated with the electronic signature, and the declaration module declares the electronic signature as valid if all of the countersignatures are determined to be valid.
- In some implementations, articles of manufacture are provided as computer program products. One implementation of a computer program product provides a computer program storage medium readable by a computer system and encoding a computer program. Another implementation of a computer program product may be provided in a computer data signal embodied in a carrier wave by a computing system and encoding the computer program. Other implementations are also described and recited herein.
- This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
-
FIG. 1 illustrates an example process for generating and verifying electronically signed data. -
FIG. 2 illustrates input to an example verifier of an electronically signed document. -
FIG. 3 illustrates example operations for verifying electronically signed data. -
FIG. 4 illustrates an example system that may be useful in implementing the described technology. -
FIG. 1 illustrates anexample process 100 for generating and verifying electronically signed data. Asigner 102 associates an electronic signature with an electronic document. An electronic signature can be used with any kind of data (e.g., a document, a message, a file, etc.), whether encrypted or not, to authenticate the identity of the signer or sender of the data and to ensure that the original content of the data is unchanged from the time of signing. - In one implementation, for example, the
signer 102 creates an electronic signature by executing a hashing algorithm on the digital data that defines a document. Example hashing algorithms may include without limitation variations of Secure Hash Algorithm (SHA), Message Digest Algorithm (MDA), and Race Integrity Primitives Evaluation Message Digest (RIPEMD). Execution of the hashing algorithm on the digital data yields a hash result, often referred to as a “hash” or digest. Thesigner 102 can then use a private key obtained from a public-private key authority to encrypt the signature digest. The encrypted signature digest represents a basic component of an electronic signature (as signature value) associated with the data. The signature value can be transmitted or stored in association with the digital data. - Upon receiving the data and the signature value, a
recipient 116 can then use averifier 118 to verify the received digital data. For example, theverifier 118 can use the signer's public key (available from the signer, a public-private key authority, or some other source) to decrypt the encrypted signature digest associated with the document (ostensibly yielding the original signature digest). Theverifier 118 can also generate a hash of the received digital data. If the hash of the received digital data and the decrypted signature digest match, validity of the basic electronic signature, and therefore the received digital data, is considered verified, at least at a basic level. That is, absent other security problems, the signature is considered to be that of the signer and the document is unchanged from the time of signing. - Accordingly, by associating the document with an electronic signature, the
signer 102 creates a signeddocument 104 that can be verified at some level by arecipient 116 or averifier 118. It should be noted that the electronic signature can be associated with the document in several different ways, including: embedding the electronic signature in the document, embedding the document in the electronic signature, referencing the document in the electronic signature, referencing the electronic signature in the document, and storing the document and electronic signature in association with each other (e.g., in the same file system directory or folder). - Nevertheless, this basic level of verification still exhibits considerable trust concerns. For example, the
verifier 118 making the assumption that the public key used to decrypt the encrypted signature digest actually belongs to the signer and is still valid. However, the public key may no longer be valid (e.g., the corresponding private key has been stolen, the signer is no longer authorized to use the private key, etc.). - Accordingly, the electronic signature can be certified by one or more trusted parties (such as
certificate authorities 106 or some other certification entities, collectively referred to herein as “certificate signers”) to attest that the public key belongs to a specified signer. Generally, a certificate uses an electronic signature to bind together a public key with an identity—information such as the name of a person or an organization, the public key owner's address, etc. An example certificate may include the public key being signed, a name or identifier of a person, a computer or an organization, a validity period, and an address (e.g., a URL) of a revocation center, although other forms of certificates may be employed. In a typical public key infrastructure (PKI) scheme, for example, data can be certified by a trusted certificate authority (CA). In a web of trust scheme, a certificate can be signed by the signer (a self-signed certificate) or other users (“endorsements”). In either case, electronic signatures on a certificate are attestations by the certificate signer that the identity information and the public key belong together. - Certificates can be used for the large-scale use of public key cryptography. Securely exchanging secret keys among a multitude of users becomes impractical and unsafe without additional protections. For example, if a first party wants others to be able to send him or her secret messages, the first party can publish a public key associated with the first party. Anyone possessing the public key can then send the party secure information. Unfortunately, a second party can also publish a public key claiming that the public key belongs to the first party and can therefore receive secret messages intended only for the first party. However, if the first party builds his or her public key into a certificate and has it digitally signed by a trusted third party (e.g., a certificate authority), anyone who trusts the trusted third party can merely check the certificate to see whether the trusted third party has certified that the embedded public key belongs to the first party. In this manner, a sender of secret information to the first party can have confidence that only the first party can access the secret message. By analogy, certification can allow a verifier to have confidence that an electronic signature actually belongs to the signer.
- Further, in large-scale deployments, chains of certificates may be employed. For example, the first party may not be familiar with a second party's certificate authority, so the second party's certificate may also include his or her certificate authorities public key signed by a “higher level” certificate authority (e.g., a commercial certificate authority), which might be recognized by the first party. This process can lead to a chain of certificates, all of which are certified by an ultimately trusted party, that in combination attest that a public key belongs to a specified individual.
- However, certification has its own security concerns. Some certificates have a limited validity period, outside of which the certificate is considered expired. In addition, a certificate may be revoked, for example, if it is discovered that its related private key has been compromised (e.g., the certificate authority's systems have been hacked) or if the relationship between a signer and a specific public key embedded in the certificate is discovered to be incorrect or has changed (e.g., if a person changes jobs or names). One method for determining whether a certificate has been revoked is compare the certificate against a certificate revocation list (CRL)—a list of revoked or cancelled certificates. Another method of determining the validity of a certificate is to query the certificate authority using the Online Certificate Status Protocol (OCSP) to obtain the status of a specific certificate.
- Therefore, while certification provides some confidence that the electronic signature associated with a document is that of a specified signer, it is possible that the certificate itself had expired or was revoked (collectively referred to as “invalidated”) at the time it was associated with the electronic signature. For example, assume the
signer 116 electronically signs the document and has the electronic signature certified with a revoked certificate. Because the certificate was revoked at the time the signature was certified, theverifier 118 cannot sufficiently demonstrate for evidentiary purposes that thesigner 116 actually signed the document (e.g., the hacker of the certificate authority could have stolen the certificate, signed the document, and certified his own signature as that of the signer 116). - To provide protection in such circumstances, timestamps can be used to enhance the security of advanced electronic signatures. A timestamp is a type of electronic signature that can be obtained from a trusted third-party (e.g., a timestamp authority 110) to attest that the certificate or certificate chain of the electronic signature existed and was valid at the time specified in the timestamp. In one implementation, the
timestamp authority 110 verifies the electronic signature and the certificate chain. If these are valid, then thetimestamp authority 110 hashes a collection of timestamp data, which includes a time value and the electronic signature digest, and associates the timestamp hash with the electronic signature. The timestamp can also be certified by one or more trusted third parties. - Assuming verification of the basic electronic signature, including associated qualifying properties and certificates, is accomplished, one or more timestamps associated with the electronic signature can be verified to determine whether the electronic signature and certificates were valid at the time of signing. If no certificate of the electronic signature was invalid at the time specified in the timestamp, then validity of the electronic signature is said to be verified as of the time specified in the timestamp. If the certificate or certificate chain of the electronic signature was revoked after the time of the timestamp, the trust in the electronic signature is unimpaired because validity has at least been verified at one point in time.
- However, certificates associated with timestamps may also expire or be revoked. This situation does not mean that the electronic signature is invalid, just that a timestamp of the electronic signature cannot be trusted. Accordingly, a possessor of an electronically signed document may submit the electronic signature to one or more timestamp authorities over time, thereby associating multiple timestamps with the electronic signature. For example, a company may submit its existing contracts to a timestamp authority on an annual basis to reinforce the validity of the electronically signed document. In this manner, the company obtains multiple attestations that at a given time the electronic signature was valid. If one or more timestamps are found to be revoked, then it is likely that another timestamp remains valid, thereby preserving the validity of the electronic signature, at least at one point in time.
- In addition, an electronic signature value in an advanced electronic signature may be associated with one or more electronic countersignatures from third parties (e.g., a countersignature authority or some other party, collectively referred to as “countersignature entities”). An electronic countersignature represents approval or notarization of the original signer's electronic signature by another party. An electronic countersignature may also be certified by one or more certificates. For example, execution of a document may require an electronic signature from two or more parties before it is considered legally binding. Accordingly, a countersignature represents an electronic signature of an identified second party and is associated with the same data electronically signed by the identified first party. A countersignature effectively signs an existing signature associated with the data. One or more countersignatures may be associated with a single document. An electronic countersignature may also be associated with its own timestamp(s) and/or countersignature(s).
- A signed
document 114 associated with an electronic signature certificate (or chain of certificates), zero or more time stamps, and zero or more countersignatures can then be transmitted to arecipient 116. If therecipient 116 wishes to verify the validity of the electronic signature associated with the signeddocument 114, the verifier 118 (e.g., a verification module of a document manager, a file manager, an email client, etc.) can receive the signeddocument 114 and test the electronic signature, timestamps, and/or countersignatures to verify the validity of the electronic signature. In the presence of multiple timestamps and/or multiple countersignatures, an implementation of theverifier 118 can declare the electronic signature as “valid”, “valid at a specified point in time”, or “invalid” (i.e., not verifiable, which suggests that the electronic signature cannot be trusted). Theverifier 118 may also generate other declarations about the verification status on the electronic signature. - In another implementation, the
verifier 118 can provide more detailed results:Result Description InvalidCertificateChain One of the certificates on the certificate chain is invalid (revoked or expired) and no timestamps were found to evidence validity at some previous time InvalidCertificateStatusUnknown Full verification of the signing certificate could not be performed (e.g., could not connect online to check the certificate chain for revocation) InvalidCertificateUsage The intended usage of the certificate used for signing does not satisfy the usage requirements InvalidCounterSignature Signature contains at least one invalid countersignature InvalidQualifyingProperties The qualifying properties inside the signature are invalid (e.g., schema does not match or mandatory parts are not present) InvalidSignatureValue The signature value was crypto- graphically invalid (e.g., the data was tampered with) InvalidTimeStamp Signature contains at least one invalid timestamp Valid Signature is fully valid ValidAtSigning There are invalid certificates on the certificate chain but the signature is valid because it contains a valid timestamp providing its full validity at the time of signing (alterna- tively, at the time of the time- stamping, which could have been well after signing) ValidNonQualifiedSignature The signature is valid crypto- graphically, but additional checks cannot be performed because the signature is not an advanced electronic signature -
FIG. 2 illustrates input to an example verifier of an electronically signeddocument 202. Anelectronic signature 204 is associated with theelectronic document 202. Such association can be achieved through a variety of methods, as discussed above, although for the purposes of the description, it will be assumed that the electronic signature is embedded in theelectronic document 202. Theelectronic signature 204 includes a signature value 206 (with or without a certificate), zero or more timestamps 210 (with or without certificates), and zero or more countersignatures 218 (with or without certificates). In one implementation, thesignature value 206 is generated by hashing the digital data that defines theelectronic document 202 to create a digest of theelectronic signature 204 and then encrypting the digest using the signer's private key. - The
signature value 206 may also be certified by acertificate 208. Thecertificate 208 may be a single certificate or a chain of certificates. As discussed previously, one or more certificates associated with thesignature value 206 may be invalid at the time of signing (or at the time of verification). Theelectronic signature 204 may also be associated with one ormore timestamps 210, as shown inFIG. 2 . - Timestamps can be added by a timestamp authority, which optionally tests the
electronic signature value 206 and thecertificates 208 associated therewith. An example timestamp is shown in an exploded view intimestamp 212 to include the digest 214 of theelectronic signature value 206 and a time value 216 (e.g., include time and date information). Other parameters can also be combined in thetimestamp 212, including without limitation qualifying properties, the hashing algorithm type, etc. - In one implementation, the timestamp authority receives the digest 214 of the
signature value 206, combines the digest 214 with a time value 216 (e.g., including time and date information) and potentially other parameters, hashes the combination, encrypts the hashed combination with the timestamp authority's private key (signs it), and sends the signed result back to the original signer for association with thedocument 202. In an alternative implementation, the timestamp authority receives theelectronic signature 204 and verifies theelectronic signature value 206 andcertificates 208. If these are valid, the timestamp authority hashes theelectronic signature value 206 to obtain a new signature digest 214. The timestamp authority then hashes a combination of the new signature digest 214, thetime value 216, and potentially other parameters, encrypts the hashed combination with the timestamp authority's private key (signs it), and sends the signed result back to the original signer for association with thedocument 202. Thetimestamp 212 may also be certified by one ormore certificates 218 and may be associated with its own timestamps and countersignatures. - Each
timestamp 210 attests to a time (e.g., a date and time value) at which the electronic signature existed in its specific form. Later, the one ormore timestamps 210 can be verified by averifier 221 to determine the earliest time at which the electronic signature was valid in association with thedocument 202. For example, company A has an agreement electronically signed by company B and wishes to enforce the agreement in a court of law. Company B repudiates the agreement, claiming that the signature is not valid, pointing out that one of the certificates in the certificate chain of the electronic signature had been revoked. If company A can verify a timestamp with a time prior to the revocation date, company A can adduce reliable evidence that the electronic signature was valid at least at one point in time and is therefore enforceable. - The
electronic signature 204 may also be associated with one or more countersignatures 218, as shown inFIG. 2 . Countersignatures can be added by a countersignature authority, which can optionally test theelectronic signature value 206 and thecertificates 208 associated therewith. An example countersignature is shown in an exploded view incountersignature 220 to include the digest 224 of theelectronic signature value 206. Other parameters can also be combined in thecountersignature 220, including without limitation qualifying properties, the hashing algorithm type, etc. - In one implementation, the countersignature authority receives the digest 224 of the
signature value 206, hashes the digest 224, encrypts the hashed digest with the countersignature authority's private key, and sends the encrypted result (i.e., countersignature 220) back to the signer for association with thedocument 202. In an alternative implementation, the countersignature authority receives theelectronic signature 204 and verifies theelectronic signature value 206 andcertificates 208. If these are valid, the countersignature authority hashes theelectronic signature value 206 to obtain a new signature digest 224. The countersignature authority then hashes the new signature digest 224, encrypts the hashed result with the countersignature authority's private key (signs it), and sends the signed result (countersignature 220) back to the original signer for association with thedocument 202. Thecountersignature 220 may also be certified by one ormore certificates 222 and may be associated with its own timestamps and countersignatures. - Each
countersignature 220 represents an approval or notarization of theelectronic signature 204 associated with thedocument 202. For example, if signatures of both parents are required in association with a child's signature on an electronic document, the parents' signatures can be provided aselectronic countersignatures 218. In order for theelectronic signature 204 to be verified, theverifier 221 validates all of thecountersignatures 218. - It should be understood that the
electronic signature 204 may not include a set of one or more timestamps or a set of one or more countersignatures. Nevertheless, verification of theelectronic signature 204 can be made more robust by inclusion of one or more of these components. -
FIG. 3 illustratesexample operations 300 for verifying electronically signed data. A receivingoperation 302 receives signed data, such as a signed document or message, in a form similar to that shown inFIG. 2 . The signed data may include certificates associated with the electronic signature, timestamps, and/or countersignatures. Examples of signed data may include with limitation audit trails of business transactions, medical guidelines in an electronic medical system, Internet tax return submissions signed using a citizen's electronic ID car or SOAP (Simple Object Access Protocol) messages used for communication between Web services, microfilm images in paper publications, etc. - A
verification operation 304 verifies the basic electronic signature value. In one implementation, verification of the basic electronic signature includes using the signer's public key to decrypt the electronic signature value associated with the signed data to obtain the electronic signature digest. Theverification operation 304 also generates a hash of the received data. If the hash matches the electronic signature digest, then the basic electronic signature value is considered verified. If the hash does not match the electronic signature digest, then theverification operation 304 declares the validity of the basic electronic signature value to be “unverifiable”, which means that the electronic signature associated with the data may not be trustworthy because the data or the signature itself may have been tampered with. - A validation operation 306 examines any qualifying properties that may be present for the electronic signature. Some examples of qualifying properties may include without limitation signing location and time, the signer's role in a company, an indication of the type of commitment expressed by signing (e.g., document author, approver, executor of a contract, etc.), and other information. For example, the signature verification policy specifies how particular qualifying properties need to be validated. For example, such a policy may require a certain location at which the signature must have been produced.
- Another
validation operation 308 validates the certificate chain (e.g., one or more certificates) associated with the basic electronic signature value. Thevalidation operation 308 compares the current time (e.g., date and time) to the validity period of the certificate to determine whether the certificate has expired. Likewise, thevalidity operation 308 consults a revocation list or the certificate authority to determine whether the certificate has been revoked. If one or more certificates are determined to be expired or revoked, adecision operation 312 will detect the invalidity and direct processing to avalidation operation 316 if any timestamps are associated with the electronic signature. The expiration time, based on the validity period of the certificate, and the revocation time, based on the revocation information from the revocation list or certificate authority, are collectively termed “invalidity times”. - Generally, a certificate represents an electronic signature that binds together a public key with an identity. The
validation operation 308 works its way up the certificate chain, from least trusted certificate to most trusted certificate. For example, thevalidation operation 308 can obtain a public key from the certificate authority associated with the least trusted certificate in the chain. Thevalidation operation 308 then decrypts the certificate using this public key and extracts a certified public key from the decrypted certificate. If the public key used to verify the electronic signature value and the certified public key match, and the certificate is not expired and has not been revoked by the certificate authority, then the certificate is deemed valid. If the certificate is determined to be currently invalid, the time (e.g., date and time) that the certificate expired or was revoked is recorded. - Then, the
verification operation 308 can obtain a public key from the certificate authority associated with the next least trusted certificate in the chain. Thevalidation operation 308 then decrypts the certificate using this public key and extracts a certified public key from the decrypted certificate. If the public key used to verify the lower level certificate and the current certified public key match, and the current certificate is not expired and has not been revoked by the certificate authority, then the certificate is deemed valid. This processing continues up the certificate chain until the certificate of the most trusted certificate authority is verified, at which point the certificate chain is considered valid. - In one implementation, the certificate usage is evaluated (e.g., some certificates are not intended for data signing) in accordance with an intended usage parameter in the certificate. If any certificate is determined to be corrupted (e.g., the data has been tampered with, corrupted during transmission, etc.), then the validity of the certificate is not verifiable and therefore neither is the validity of the electronic signature.
- The
decision operation 312 determines whether any of the certificates in the certificate chain were found to be invalid (e.g., revoked or expired). If not, then the electronic signature is declared valid in declaration operation 314. In an alternative implementation and/or for a configuration of electronic signature that includes one or more countersignatures, certain countersignature verification operations, such as those described with regard tooperation - If at least one certificate in the chain was determined to be invalid and there are no timestamps associated with the electronic signature, then the invalidity in the certificate chain generally indicates that the electronic signature cannot be trusted because there is no way to determine whether the certificate chain was valid at the time of signing. However, if the electronic signature is associated with timestamps, then a
validation operation 316 can be initiated to determine whether the certificate chain may have been valid at any previous point in time, which would provide the evidentiary basis for relying on the electronic signature. - Accordingly, the
validation operation 316 attempts to verify one or more timestamps associated with the electronic signature. In one implementation, thevalidation operation 316 decrypts a timestamp using the public key of the timestamp authority to obtain the digest of the electronic signature value and a time value. Thevalidation operation 316 then determines whether the electronic signature value's digest from the timestamp matches the electronic signature value's digest decrypted from the electronic signature value. Thevalidation operation 316 may also test a certificate chain associated with the timestamp. If the electronic signature digests match (and the certificate chain is verified), the time value represents a point in time at which the electronic signature existed in its specific form. Thevalidation operation 316 can operate on all of the timestamps associated with the electronic signature (or at least until a timestamp satisfying the test intesting operation 322 is found). - A selection operation selects the earliest valid timestamp and records the time value as T1.
A determination operation 320 examines the recorded expiration/revocation dates of the certificates in the certificate chain and records the earliest invalidity time as T2.A decision operation 322 test whether T1<T2. If T1<T2, then the certificate chain at least was valid at T1 and is therefore trustworthy. Processing can proceed to verify any countersignatures associated with the electronic signature. (If no countersignatures are associated with the electronic signature then processing can proceed directly to declaration operation 328, which declares that the electronic signature was at least valid at time T1 and can therefore be trusted.) If T1 is not less than T2, then adeclaration operation 330 declares the electronic signature to be invalid (i.e., not verifiable). - If countersignatures are associated with the electronic signature, then a
validation operation 324 attempts to verify all such countersignatures, using the verification techniques for electronics signatures described herein. If all of the countersignatures are verified, then the declaration operation 328 declares that the electronic signature was at least valid at time T1 and can therefore be trusted. Alternatively, if one of the countersignatures is not verified, then thedeclaration operation 330 declares the electronic signature to be invalid (i.e., not verifiable). - The example hardware and operating environment of
FIG. 4 for implementing the invention includes a general purpose computing device in the form of a gaming console orcomputer 20, including aprocessing unit 21, asystem memory 22, and asystem bus 23 that operatively couples various system components including the system memory to theprocessing unit 21. There may be only one or there may be more than oneprocessing unit 21, such that the processor ofcomputer 20 comprises a single central-processing unit (CPU), or a plurality of processing units, commonly referred to as a parallel processing environment. Thecomputer 20 may be a conventional computer, a distributed computer, or any other type of computer; the invention is not so limited. - The
system bus 23 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, a switched fabric, point-to-point connections, and a local bus using any of a variety of bus architectures. The system memory may also be referred to as simply the memory, and includes read only memory (ROM) 24 and random access memory (RAM) 25. A basic input/output system (BIOS) 26, containing the basic routines that help to transfer information between elements within thecomputer 20, such as during start-up, is stored inROM 24. Thecomputer 20 further includes ahard disk drive 27 for reading from and writing to a hard disk, not shown, amagnetic disk drive 28 for reading from or writing to a removablemagnetic disk 29, and anoptical disk drive 30 for reading from or writing to a removableoptical disk 31 such as a CD ROM or other optical media. - The
hard disk drive 27,magnetic disk drive 28, andoptical disk drive 30 are connected to thesystem bus 23 by a harddisk drive interface 32, a magneticdisk drive interface 33, and an opticaldisk drive interface 34, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for thecomputer 20. It should be appreciated by those skilled in the art that any type of computer-readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, random access memories (RAMs), read only memories (ROMs), and the like, may be used in the example operating environment. - A number of program modules may be stored on the hard disk,
magnetic disk 29,optical disk 31,ROM 24, orRAM 25, including anoperating system 35, one ormore application programs 36,other program modules 37, andprogram data 38. A user may enter commands and information into thepersonal computer 20 through input devices such as akeyboard 40 andpointing device 42. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to theprocessing unit 21 through aserial port interface 46 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port, or a universal serial bus (USB). Amonitor 47 or other type of display device is also connected to thesystem bus 23 via an interface, such as avideo adapter 48. In addition to the monitor, computers typically include other peripheral output devices (not shown), such as speakers and printers. - The
computer 20 may operate in a networked environment using logical connections to one or more remote computers, such asremote computer 49. These logical connections are achieved by a communication device coupled to or a part of thecomputer 20; the invention is not limited to a particular type of communications device. Theremote computer 49 may be another computer, a server, a router, a network PC, a client, a peer device or other common network node, and typically includes many or all of the elements described above relative to thecomputer 20, although only a memory storage device 50 has been illustrated inFIG. 4 . The logical connections depicted inFIG. 4 include a local-area network (LAN) 51 and a wide-area network (WAN) 52. Such networking environments are commonplace in office networks, enterprise-wide computer networks, intranets and the Internet, which are all types of networks. - When used in a LAN-networking environment, the
computer 20 is connected to thelocal network 51 through a network interface oradapter 53, which is one type of communications device. When used in a WAN-networking environment, thecomputer 20 typically includes a modem 54, a network adapter, a type of communications device, or any other type of communications device for establishing communications over thewide area network 52. The modem 54, which may be internal or external, is connected to thesystem bus 23 via theserial port interface 46. In a networked environment, program modules depicted relative to thepersonal computer 20, or portions thereof, may be stored in the remote memory storage device. It is appreciated that the network connections shown are example and other means of and communications devices for establishing a communications link between the computers may be used. - In an example implementation, an electronic signature verification module, a timestamp verification module, a countersignature verification module, a declaration module, a hashing module, an encryption module, a decryption module, and other modules may be embodied by instructions stored in
memory 22 and/orstorage devices processing unit 21. An electronic signature, a public key, a private key, a digest, a certificate, a timestamp, a countersignature, and other data may be stored inmemory 22 and/orstorage devices - The technology described herein is implemented as logical operations and/or modules in one or more systems. The logical operations may be implemented as a sequence of processor-implemented steps executing in one or more computer systems and as interconnected machine or circuit modules within one or more computer systems. Likewise, the descriptions of various component modules may be provided in terms of operations executed or effected by the modules. The resulting implementation is a matter of choice, dependent on the performance requirements of the underlying system implementing the described technology. Accordingly, the logical operations making up the embodiments of the technology described herein are referred to variously as operations, steps, objects, or modules. Furthermore, it should be understood that logical operations may be performed in any order, unless explicitly claimed otherwise or a specific order is inherently necessitated by the claim language.
- The above specification, examples and data provide a complete description of the structure and use of example embodiments of the invention. Although various embodiments of the invention have been described above with a certain degree of particularity, or with reference to one or more individual embodiments, those skilled in the art could make numerous alterations to the disclosed embodiments without departing from the spirit or scope of this invention. In particular, it should be understood that the described technology may be employed independent of a personal computer. Other embodiments are therefore contemplated. It is intended that all matter contained in the above description and shown in the accompanying drawings shall be interpreted as illustrative only of particular embodiments and not limiting. Changes in detail or structure may be made without departing from the basic elements of the invention as defined in the following claims.
- Although the subject matter has been described in language specific to structural features and/or methodological arts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claimed subject matter.
Claims (20)
Priority Applications (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/366,060 US7904725B2 (en) | 2006-03-02 | 2006-03-02 | Verification of electronic signatures |
CN2007800072991A CN101395624B (en) | 2006-03-02 | 2007-02-13 | Verification of electronic signatures |
KR1020087021371A KR20080104137A (en) | 2006-03-02 | 2007-02-13 | Verification of electronic signatures |
EP07750532A EP1999696A2 (en) | 2006-03-02 | 2007-02-13 | Verification of electronic signatures |
PCT/US2007/003701 WO2007106272A1 (en) | 2006-03-02 | 2007-02-13 | Verification of electronic signatures |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/366,060 US7904725B2 (en) | 2006-03-02 | 2006-03-02 | Verification of electronic signatures |
Publications (2)
Publication Number | Publication Date |
---|---|
US20070220259A1 true US20070220259A1 (en) | 2007-09-20 |
US7904725B2 US7904725B2 (en) | 2011-03-08 |
Family
ID=38509812
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/366,060 Expired - Fee Related US7904725B2 (en) | 2006-03-02 | 2006-03-02 | Verification of electronic signatures |
Country Status (5)
Country | Link |
---|---|
US (1) | US7904725B2 (en) |
EP (1) | EP1999696A2 (en) |
KR (1) | KR20080104137A (en) |
CN (1) | CN101395624B (en) |
WO (1) | WO2007106272A1 (en) |
Cited By (45)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080250247A1 (en) * | 2007-02-13 | 2008-10-09 | Airbus France | Authentication method for an electronic document and verification method of a document thus authenticated |
US20090044019A1 (en) * | 2007-08-09 | 2009-02-12 | Hong Fu Jin Precision Industry (Shenzhen) Co., Ltd. | System and method for digitally signing electronic documents |
US20090100079A1 (en) * | 2007-10-12 | 2009-04-16 | Fujitsu Limited | E-mail information management apparatus, and e-mail information management method |
US20090183262A1 (en) * | 2008-01-16 | 2009-07-16 | Sony Corporation | Information processing apparatus, disc, information processing method, and program |
US20100020967A1 (en) * | 2008-07-24 | 2010-01-28 | Safechannel Inc. | Http authentication and authorization management |
US20100024006A1 (en) * | 2008-07-24 | 2010-01-28 | Safechannel Inc. | Http authentication and authorization management |
US20100023762A1 (en) * | 2008-07-24 | 2010-01-28 | Safechannel Inc. | Http authentication and authorization management |
US20100024014A1 (en) * | 2008-07-24 | 2010-01-28 | Safechannel Inc. | Http authentication and authorization management |
US20100106974A1 (en) * | 2008-10-24 | 2010-04-29 | Aguilera Marcos K | System For And Method Of Writing And Reading Redundant Data |
US20100138904A1 (en) * | 2007-04-26 | 2010-06-03 | Logalty Servicios De Tercero De Confianza, S.L. | Method and system for notarising electronic transactions |
US20100296639A1 (en) * | 2000-04-07 | 2010-11-25 | Rubin Aviel D | Broadband Certified Mail |
US7904725B2 (en) * | 2006-03-02 | 2011-03-08 | Microsoft Corporation | Verification of electronic signatures |
US20120093386A1 (en) * | 2010-10-19 | 2012-04-19 | Siemens Medical Solutions Usa, Inc. | System for Verifying Data Integrity in an X-Ray Imaging System |
US20120110343A1 (en) * | 2010-10-29 | 2012-05-03 | Bandic Zvonimir Z | Trustworthy timestamps on data storage devices |
US20130132719A1 (en) * | 2011-11-17 | 2013-05-23 | Sony Corporation | Information processing apparatus, information storage apparatus, information processing system, and information processing method and program |
US20130227139A1 (en) * | 2012-02-29 | 2013-08-29 | Research In Motion Limited | Communicating an identity to a server |
US8572730B1 (en) * | 2011-02-28 | 2013-10-29 | Symantec Corporation | Systems and methods for revoking digital signatures |
US8856640B1 (en) * | 2012-01-20 | 2014-10-07 | Google Inc. | Method and apparatus for applying revision specific electronic signatures to an electronically stored document |
WO2015124726A1 (en) * | 2014-02-20 | 2015-08-27 | Phoenix Contact Gmbh & Co. Kg | Method and system for creating and checking the validity of device certificates |
US9286271B2 (en) | 2010-05-26 | 2016-03-15 | Google Inc. | Providing an electronic document collection |
US9384285B1 (en) | 2012-12-18 | 2016-07-05 | Google Inc. | Methods for identifying related documents |
US9407644B1 (en) * | 2013-11-26 | 2016-08-02 | Symantec Corporation | Systems and methods for detecting malicious use of digital certificates |
US9495341B1 (en) | 2012-12-18 | 2016-11-15 | Google Inc. | Fact correction and completion during document drafting |
US9514113B1 (en) | 2013-07-29 | 2016-12-06 | Google Inc. | Methods for automatic footnote generation |
US9529916B1 (en) | 2012-10-30 | 2016-12-27 | Google Inc. | Managing documents based on access context |
US9529791B1 (en) | 2013-12-12 | 2016-12-27 | Google Inc. | Template and content aware document and template editing |
US9703763B1 (en) | 2014-08-14 | 2017-07-11 | Google Inc. | Automatic document citations by utilizing copied content for candidate sources |
WO2017210198A1 (en) * | 2016-05-31 | 2017-12-07 | Lookout, Inc. | Methods and systems for detecting and preventing network connection compromise |
US9842113B1 (en) | 2013-08-27 | 2017-12-12 | Google Inc. | Context-based file selection |
US9888037B1 (en) | 2015-08-27 | 2018-02-06 | Amazon Technologies, Inc. | Cipher suite negotiation |
WO2018039012A1 (en) * | 2016-08-26 | 2018-03-01 | Microsoft Technology Licensing, Llc | Evolving a signature during trust verification of an object |
US9912486B1 (en) * | 2015-08-27 | 2018-03-06 | Amazon Technologies, Inc. | Countersigned certificates |
US9942051B1 (en) * | 2013-03-15 | 2018-04-10 | Poltorak Technologies Llc | System and method for secure relayed communications from an implantable medical device |
US10218697B2 (en) | 2017-06-09 | 2019-02-26 | Lookout, Inc. | Use of device risk evaluation to manage access to services |
US10454689B1 (en) | 2015-08-27 | 2019-10-22 | Amazon Technologies, Inc. | Digital certificate management |
US20190377889A1 (en) * | 2017-02-10 | 2019-12-12 | Michael Mertens | Verifiable version control on authenticated and/or encrypted electronic documents |
US20190384586A1 (en) * | 2018-06-15 | 2019-12-19 | Sierra Wireless, Inc. | Method and apparatus for secure software update |
CN111581177A (en) * | 2020-05-07 | 2020-08-25 | 贵州省邮电规划设计院有限公司 | Sharing platform for certificate batch recognition and verification |
WO2020197428A1 (en) * | 2019-03-28 | 2020-10-01 | Публичное Акционерное Общество "Сбербанк России" | Method and system for checking a set of electronic documents |
CN111769955A (en) * | 2020-06-30 | 2020-10-13 | 成都卫士通信息产业股份有限公司 | Electronic signature generation method and device, electronic signature verification method and device and related components |
CN112052435A (en) * | 2020-09-30 | 2020-12-08 | 杭州尚尚签网络科技有限公司 | Method for multi-user electronic signature of CAD (computer-aided design) drawing |
CN112434279A (en) * | 2020-12-08 | 2021-03-02 | 北京万协通信息技术有限公司 | Bidirectional authentication method based on embedded inter-account book |
US11308037B2 (en) | 2012-10-30 | 2022-04-19 | Google Llc | Automatic collaboration |
CN116015673A (en) * | 2022-12-15 | 2023-04-25 | 福州大学 | Electronic medical record safe sharing method and system based on limited cleanable signature |
US11722312B2 (en) * | 2020-03-09 | 2023-08-08 | Sony Group Corporation | Privacy-preserving signature |
Families Citing this family (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9363258B2 (en) * | 2007-12-17 | 2016-06-07 | International Business Machines Corporation | Secure digital signature system |
CN101499098B (en) * | 2009-03-04 | 2012-07-11 | 阿里巴巴集团控股有限公司 | Web page assessed value confirming and employing method and system |
US8484723B2 (en) * | 2009-06-05 | 2013-07-09 | Signix, Inc. | Method and system for signing and authenticating electronic documents via a signature authority which may act in concert with software controlled by the signer |
JP5105291B2 (en) * | 2009-11-13 | 2012-12-26 | セイコーインスツル株式会社 | Long-term signature server, long-term signature terminal, long-term signature terminal program |
US8806190B1 (en) | 2010-04-19 | 2014-08-12 | Amaani Munshi | Method of transmission of encrypted documents from an email application |
JP5761683B2 (en) * | 2011-02-23 | 2015-08-12 | セイコーインスツル株式会社 | Information processing apparatus and information processing program |
US9264404B1 (en) * | 2012-08-15 | 2016-02-16 | Marvell International Ltd. | Encrypting data using time stamps |
RU2514138C1 (en) * | 2012-09-28 | 2014-04-27 | Закрытое акционерное общество "Лаборатория Касперского" | System and method for verifying public key certificate to counteract "man-in-middle" attacks |
CN108510276B (en) * | 2013-07-30 | 2021-05-04 | 创新先进技术有限公司 | Data processing method, device and system |
CN107077622B (en) * | 2014-10-30 | 2020-04-14 | 惠普发展公司,有限责任合伙企业 | Digital signature authentication |
GB201605032D0 (en) * | 2016-03-24 | 2016-05-11 | Eitc Holdings Ltd | Recording multiple transactions on a peer-to-peer distributed ledger |
CN107438002B (en) * | 2016-05-27 | 2022-02-11 | 索尼公司 | Block chain based system and electronic device and method in system |
US10333717B2 (en) * | 2017-03-09 | 2019-06-25 | Microsoft Technology Licensing, Llc | Timestamped license data structure |
US10277576B1 (en) | 2017-06-29 | 2019-04-30 | Syniverse Technologies, Llc | Diameter end-to-end security with a multiway handshake |
US11334881B2 (en) | 2019-01-28 | 2022-05-17 | Bank Of America Corporation | Security tool |
US11469903B2 (en) * | 2019-02-28 | 2022-10-11 | Microsoft Technology Licensing, Llc | Autonomous signing management operations for a key distribution service |
US11645372B2 (en) | 2020-01-22 | 2023-05-09 | International Business Machines Corporation | Multifactor handwritten signature verification |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4868877A (en) * | 1988-02-12 | 1989-09-19 | Fischer Addison M | Public key/signature cryptosystem with enhanced digital signature certification |
US5659616A (en) * | 1994-07-19 | 1997-08-19 | Certco, Llc | Method for securely using digital signatures in a commercial cryptographic system |
US6301658B1 (en) * | 1998-09-09 | 2001-10-09 | Secure Computing Corporation | Method and system for authenticating digital certificates issued by an authentication hierarchy |
US20020029337A1 (en) * | 1994-07-19 | 2002-03-07 | Certco, Llc. | Method for securely using digital signatures in a commercial cryptographic system |
US20050210256A1 (en) * | 2004-03-17 | 2005-09-22 | Beat Meier | Methods, systems and software applications for verifying certain requirements on electronic documents |
US20070186111A1 (en) * | 2004-05-03 | 2007-08-09 | Alain Durand | Certificate validity checking |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1153582A (en) * | 1994-07-19 | 1997-07-02 | 银行家信托公司 | Method for securely using digital signatures in commercial cryptographic system |
AU760742C (en) | 1997-09-22 | 2006-11-09 | Proofspace, Inc. | Method and system for transient key digital time stamps |
US7904725B2 (en) * | 2006-03-02 | 2011-03-08 | Microsoft Corporation | Verification of electronic signatures |
-
2006
- 2006-03-02 US US11/366,060 patent/US7904725B2/en not_active Expired - Fee Related
-
2007
- 2007-02-13 WO PCT/US2007/003701 patent/WO2007106272A1/en active Application Filing
- 2007-02-13 KR KR1020087021371A patent/KR20080104137A/en not_active Application Discontinuation
- 2007-02-13 EP EP07750532A patent/EP1999696A2/en not_active Withdrawn
- 2007-02-13 CN CN2007800072991A patent/CN101395624B/en not_active Expired - Fee Related
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4868877A (en) * | 1988-02-12 | 1989-09-19 | Fischer Addison M | Public key/signature cryptosystem with enhanced digital signature certification |
US5659616A (en) * | 1994-07-19 | 1997-08-19 | Certco, Llc | Method for securely using digital signatures in a commercial cryptographic system |
US20020029337A1 (en) * | 1994-07-19 | 2002-03-07 | Certco, Llc. | Method for securely using digital signatures in a commercial cryptographic system |
US6301658B1 (en) * | 1998-09-09 | 2001-10-09 | Secure Computing Corporation | Method and system for authenticating digital certificates issued by an authentication hierarchy |
US20050210256A1 (en) * | 2004-03-17 | 2005-09-22 | Beat Meier | Methods, systems and software applications for verifying certain requirements on electronic documents |
US20070186111A1 (en) * | 2004-05-03 | 2007-08-09 | Alain Durand | Certificate validity checking |
Cited By (84)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8694785B2 (en) * | 2000-04-07 | 2014-04-08 | At&T Intellectual Property Ii, L.P. | Broadband certified mail |
US9876769B2 (en) | 2000-04-07 | 2018-01-23 | At&T Intellectual Property Ii, L.P. | Broadband certified mail |
US9225528B2 (en) | 2000-04-07 | 2015-12-29 | At&T Intellectual Property Ii, L.P. | Broadband certified mail |
US20100296639A1 (en) * | 2000-04-07 | 2010-11-25 | Rubin Aviel D | Broadband Certified Mail |
US7904725B2 (en) * | 2006-03-02 | 2011-03-08 | Microsoft Corporation | Verification of electronic signatures |
US20080250247A1 (en) * | 2007-02-13 | 2008-10-09 | Airbus France | Authentication method for an electronic document and verification method of a document thus authenticated |
US8756428B2 (en) * | 2007-02-13 | 2014-06-17 | Airbus Operations Sas | Authentication method for an electronic document and verification method of a document thus authenticated |
US20100138904A1 (en) * | 2007-04-26 | 2010-06-03 | Logalty Servicios De Tercero De Confianza, S.L. | Method and system for notarising electronic transactions |
US9412139B2 (en) * | 2007-04-26 | 2016-08-09 | Logalty Servicios De Tercero De Confianza, S.L. | Method and system for notarising electronic transactions |
US7958364B2 (en) * | 2007-08-09 | 2011-06-07 | Hong Fu Jin Precision Industry (Shenzhen) Co., Ltd. | System and method for digitally signing electronic documents |
US20090044019A1 (en) * | 2007-08-09 | 2009-02-12 | Hong Fu Jin Precision Industry (Shenzhen) Co., Ltd. | System and method for digitally signing electronic documents |
US8832202B2 (en) * | 2007-10-12 | 2014-09-09 | Fujitsu Limited | E-mail information management apparatus, and E-mail information management method |
US20090100079A1 (en) * | 2007-10-12 | 2009-04-16 | Fujitsu Limited | E-mail information management apparatus, and e-mail information management method |
US8225088B2 (en) * | 2008-01-16 | 2012-07-17 | Sony Corporation | Information processing apparatus, disc, information processing method, and program |
US20090183262A1 (en) * | 2008-01-16 | 2009-07-16 | Sony Corporation | Information processing apparatus, disc, information processing method, and program |
US10609083B2 (en) | 2008-07-24 | 2020-03-31 | Zscaler, Inc. | Distributed cloud-based security systems and methods |
US20100024014A1 (en) * | 2008-07-24 | 2010-01-28 | Safechannel Inc. | Http authentication and authorization management |
US20100020967A1 (en) * | 2008-07-24 | 2010-01-28 | Safechannel Inc. | Http authentication and authorization management |
US9003186B2 (en) * | 2008-07-24 | 2015-04-07 | Zscaler, Inc. | HTTP authentication and authorization management |
US10601870B2 (en) | 2008-07-24 | 2020-03-24 | Zscaler, Inc. | Distributed cloud-based security systems and methods |
US9379895B2 (en) | 2008-07-24 | 2016-06-28 | Zscaler, Inc. | HTTP authentication and authorization management |
US8656462B2 (en) | 2008-07-24 | 2014-02-18 | Zscaler, Inc. | HTTP authentication and authorization management |
US11368490B2 (en) | 2008-07-24 | 2022-06-21 | Zscaler, Inc. | Distributed cloud-based security systems and methods |
US20100023762A1 (en) * | 2008-07-24 | 2010-01-28 | Safechannel Inc. | Http authentication and authorization management |
US8806201B2 (en) | 2008-07-24 | 2014-08-12 | Zscaler, Inc. | HTTP authentication and authorization management |
US20100024006A1 (en) * | 2008-07-24 | 2010-01-28 | Safechannel Inc. | Http authentication and authorization management |
US20100106974A1 (en) * | 2008-10-24 | 2010-04-29 | Aguilera Marcos K | System For And Method Of Writing And Reading Redundant Data |
US8533478B2 (en) * | 2008-10-24 | 2013-09-10 | Hewlett-Packard Development Company, L. P. | System for and method of writing and reading redundant data |
US9292479B2 (en) | 2010-05-26 | 2016-03-22 | Google Inc. | Providing an electronic document collection |
US9286271B2 (en) | 2010-05-26 | 2016-03-15 | Google Inc. | Providing an electronic document collection |
US20120093386A1 (en) * | 2010-10-19 | 2012-04-19 | Siemens Medical Solutions Usa, Inc. | System for Verifying Data Integrity in an X-Ray Imaging System |
US8582847B2 (en) * | 2010-10-19 | 2013-11-12 | Siemens Medical Solutions Usa, Inc. | System for verifying data integrity in an X-ray imaging system |
US20120110343A1 (en) * | 2010-10-29 | 2012-05-03 | Bandic Zvonimir Z | Trustworthy timestamps on data storage devices |
US8572730B1 (en) * | 2011-02-28 | 2013-10-29 | Symantec Corporation | Systems and methods for revoking digital signatures |
US10120984B2 (en) * | 2011-11-17 | 2018-11-06 | Sony Corporation | Information processing apparatus and information processing method for decoding, reproducing and providing encrypted content |
US20130132719A1 (en) * | 2011-11-17 | 2013-05-23 | Sony Corporation | Information processing apparatus, information storage apparatus, information processing system, and information processing method and program |
US8856640B1 (en) * | 2012-01-20 | 2014-10-07 | Google Inc. | Method and apparatus for applying revision specific electronic signatures to an electronically stored document |
US9542374B1 (en) | 2012-01-20 | 2017-01-10 | Google Inc. | Method and apparatus for applying revision specific electronic signatures to an electronically stored document |
US9232024B2 (en) * | 2012-02-29 | 2016-01-05 | Blackberry Limited | Communicating an identity to a server |
US20130227139A1 (en) * | 2012-02-29 | 2013-08-29 | Research In Motion Limited | Communicating an identity to a server |
US11748311B1 (en) | 2012-10-30 | 2023-09-05 | Google Llc | Automatic collaboration |
US11308037B2 (en) | 2012-10-30 | 2022-04-19 | Google Llc | Automatic collaboration |
US9529916B1 (en) | 2012-10-30 | 2016-12-27 | Google Inc. | Managing documents based on access context |
US9495341B1 (en) | 2012-12-18 | 2016-11-15 | Google Inc. | Fact correction and completion during document drafting |
US9384285B1 (en) | 2012-12-18 | 2016-07-05 | Google Inc. | Methods for identifying related documents |
US11930126B2 (en) | 2013-03-15 | 2024-03-12 | Piltorak Technologies LLC | System and method for secure relayed communications from an implantable medical device |
US11588650B2 (en) | 2013-03-15 | 2023-02-21 | Poltorak Technologies Llc | System and method for secure relayed communications from an implantable medical device |
US9942051B1 (en) * | 2013-03-15 | 2018-04-10 | Poltorak Technologies Llc | System and method for secure relayed communications from an implantable medical device |
US10841104B2 (en) | 2013-03-15 | 2020-11-17 | Poltorak Technologies Llc | System and method for secure relayed communications from an implantable medical device |
US10305695B1 (en) | 2013-03-15 | 2019-05-28 | Poltorak Technologies Llc | System and method for secure relayed communications from an implantable medical device |
US9514113B1 (en) | 2013-07-29 | 2016-12-06 | Google Inc. | Methods for automatic footnote generation |
US9842113B1 (en) | 2013-08-27 | 2017-12-12 | Google Inc. | Context-based file selection |
US11681654B2 (en) | 2013-08-27 | 2023-06-20 | Google Llc | Context-based file selection |
US12032518B2 (en) | 2013-08-27 | 2024-07-09 | Google Llc | Context-based file selection |
US9407644B1 (en) * | 2013-11-26 | 2016-08-02 | Symantec Corporation | Systems and methods for detecting malicious use of digital certificates |
US9529791B1 (en) | 2013-12-12 | 2016-12-27 | Google Inc. | Template and content aware document and template editing |
US20170054566A1 (en) * | 2014-02-20 | 2017-02-23 | Phoenix Contact Gmbh & Co. Kg | Method and system for creating and checking the validity of device certificates |
US20210044441A1 (en) * | 2014-02-20 | 2021-02-11 | Phoenix Contact Gmbh & Co. Kg | Method and system for creating and checking the validity of device certificates |
WO2015124726A1 (en) * | 2014-02-20 | 2015-08-27 | Phoenix Contact Gmbh & Co. Kg | Method and system for creating and checking the validity of device certificates |
US11743054B2 (en) * | 2014-02-20 | 2023-08-29 | Phoenix Contact Gmbh & Co. Kg | Method and system for creating and checking the validity of device certificates |
US10841102B2 (en) * | 2014-02-20 | 2020-11-17 | Phoenix Contact Gmbh & Co. Kg | Method and system for creating and checking the validity of device certificates |
US9703763B1 (en) | 2014-08-14 | 2017-07-11 | Google Inc. | Automatic document citations by utilizing copied content for candidate sources |
US9888037B1 (en) | 2015-08-27 | 2018-02-06 | Amazon Technologies, Inc. | Cipher suite negotiation |
US10454689B1 (en) | 2015-08-27 | 2019-10-22 | Amazon Technologies, Inc. | Digital certificate management |
US9912486B1 (en) * | 2015-08-27 | 2018-03-06 | Amazon Technologies, Inc. | Countersigned certificates |
US20190387021A1 (en) * | 2016-05-31 | 2019-12-19 | Lookout, Inc. | Methods and systems for preventing a false report of a compromised network connection |
US10440053B2 (en) | 2016-05-31 | 2019-10-08 | Lookout, Inc. | Methods and systems for detecting and preventing network connection compromise |
WO2017210198A1 (en) * | 2016-05-31 | 2017-12-07 | Lookout, Inc. | Methods and systems for detecting and preventing network connection compromise |
US11683340B2 (en) * | 2016-05-31 | 2023-06-20 | Lookout, Inc. | Methods and systems for preventing a false report of a compromised network connection |
WO2018039012A1 (en) * | 2016-08-26 | 2018-03-01 | Microsoft Technology Licensing, Llc | Evolving a signature during trust verification of an object |
US10218515B2 (en) | 2016-08-26 | 2019-02-26 | Microsoft Technology Licensing, Llc | Evolving a signature during trust verification of an object |
CN109644132A (en) * | 2016-08-26 | 2019-04-16 | 微软技术许可有限责任公司 | Evolution signature during the trust authentication of object |
US20190377889A1 (en) * | 2017-02-10 | 2019-12-12 | Michael Mertens | Verifiable version control on authenticated and/or encrypted electronic documents |
US11038876B2 (en) | 2017-06-09 | 2021-06-15 | Lookout, Inc. | Managing access to services based on fingerprint matching |
US10218697B2 (en) | 2017-06-09 | 2019-02-26 | Lookout, Inc. | Use of device risk evaluation to manage access to services |
US10977024B2 (en) * | 2018-06-15 | 2021-04-13 | Sierra Wireless, Inc. | Method and apparatus for secure software update |
US20190384586A1 (en) * | 2018-06-15 | 2019-12-19 | Sierra Wireless, Inc. | Method and apparatus for secure software update |
WO2020197428A1 (en) * | 2019-03-28 | 2020-10-01 | Публичное Акционерное Общество "Сбербанк России" | Method and system for checking a set of electronic documents |
US11722312B2 (en) * | 2020-03-09 | 2023-08-08 | Sony Group Corporation | Privacy-preserving signature |
CN111581177A (en) * | 2020-05-07 | 2020-08-25 | 贵州省邮电规划设计院有限公司 | Sharing platform for certificate batch recognition and verification |
CN111769955A (en) * | 2020-06-30 | 2020-10-13 | 成都卫士通信息产业股份有限公司 | Electronic signature generation method and device, electronic signature verification method and device and related components |
CN112052435A (en) * | 2020-09-30 | 2020-12-08 | 杭州尚尚签网络科技有限公司 | Method for multi-user electronic signature of CAD (computer-aided design) drawing |
CN112434279A (en) * | 2020-12-08 | 2021-03-02 | 北京万协通信息技术有限公司 | Bidirectional authentication method based on embedded inter-account book |
CN116015673A (en) * | 2022-12-15 | 2023-04-25 | 福州大学 | Electronic medical record safe sharing method and system based on limited cleanable signature |
Also Published As
Publication number | Publication date |
---|---|
CN101395624B (en) | 2012-07-04 |
US7904725B2 (en) | 2011-03-08 |
CN101395624A (en) | 2009-03-25 |
KR20080104137A (en) | 2008-12-01 |
EP1999696A2 (en) | 2008-12-10 |
WO2007106272A1 (en) | 2007-09-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7904725B2 (en) | Verification of electronic signatures | |
US8086859B2 (en) | Generation of electronic signatures | |
US11516016B2 (en) | Method and system for signing and authenticating electronic documents via a signature authority which may act in concert with software controlled by the signer | |
CN109067801B (en) | Identity authentication method, identity authentication device and computer readable medium | |
US11888974B1 (en) | Secret sharing information management and security system | |
AU2002230823B2 (en) | Method and system for obtaining digital signatures | |
US5745574A (en) | Security infrastructure for electronic transactions | |
US8935528B2 (en) | Techniques for ensuring authentication and integrity of communications | |
US20110231645A1 (en) | System and method to validate and authenticate digital data | |
US20120260098A1 (en) | Storage and Authentication of Data Transactions | |
US20050044369A1 (en) | Electronic document management system | |
US11606201B2 (en) | Cryptographic systems and methods using distributed ledgers | |
US20020073310A1 (en) | Method and system for a secure binding of a revoked X.509 certificate to its corresponding certificate revocation list | |
Spies | Public key infrastructure | |
GB2391438A (en) | Electronic sealing for electronic transactions | |
Wrótniak et al. | Provable security for PKI schemes | |
Chokhani et al. | PKI and certificate authorities | |
Wright | Secure digital archiving of high-value data | |
Kurariya et al. | LTV-Backed E-Signatures Using Post-Quantum Cryptography | |
EP1387551A1 (en) | Electronic sealing for electronic transactions | |
Lekkas et al. | Withdrawing a declaration of will: Towards a framework for Digital Signature Revocation | |
Roe | Cambridge University Computer Laboratory Computer Security Group Version 1.1 July 1993 | |
Berbecaru et al. | Digital Certificates and Public-Key Infrastructures | |
CA2326997A1 (en) | Security infrastructure for electronic transactions |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: MICROSOFT CORPORATION, WASHINGTON Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:PAVLICIC, MILADIN;REEL/FRAME:017630/0324 Effective date: 20060501 |
|
REMI | Maintenance fee reminder mailed | ||
AS | Assignment |
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034543/0001 Effective date: 20141014 |
|
LAPS | Lapse for failure to pay maintenance fees | ||
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20150308 |