Timestamping FAQs - Industry standards and technology
A directory of FAQ's on other subjects is here.
DigiStamp provides the application programmer a toolkit of software services to create and manage the application interface including hash generation, server message formatting & reply parsing, timestamp server site selection & failure rollover, and Internet communications. Alternatively, the application programmer may write his own library calls formatted to the IETF protocol used by DigiStamp. HTTP or SSL transport protocols may be used to communicate with DigiStamp’s servers.
Client services include creating and verifying timestamps, with the local data files remaining in their original format. However, only the data file’s fingerprint is transmitted to DigiStamp; sensitive data is never transmitted outside the client.
The IETF timestamp standard is used since it is well defined and the industry standard. To learn more about the IETF standard, go to industry standards.
DigiStamp's pay-as-you-go transactional pricing off-loads from you, the end-user, the management of a trusted server and trusted site. We allow you to outsource the difficult stuff, without putting undue burden on your internal IT resources as well as without encumbering your staff with the need to manage and maintain a complex server site.
DigiStamp puts its energy into ensuring reliable performance in its trusted sites, updating the technology and systems as required. DigiStamp keeps pace with the ever-increasing computing advances that threaten cryptographic solutions. DigiStamp's services put the burden on DigiStamp to maintain the technological edge in the complex field of cryptography. Why should you? Our volume pricing makes the DigiStamp service the better value.
An e-TimeStamp is independently verifiable proof which conforms to numerous international standards.
DigiStamp recommends you store the timestamp next to the original file (or an archive copy) since both must be maintained to protect your transaction. The timestamp returned is less than 3000 bytes and includes all the data needed to verify it using standard methods. If your application requires DigiStamp retain your timestamps, please contact DigiStamp with your requirements.
We compare our timestamp standard with several other techniques. All techniques assume the data is in a digital format and the end-user wants to automate the timestamping process in lieu of a manual notarization technique.
This technique combines the hash of one user's file with the hash of other user's files. The succession of hashes is kept as a sequential record of all hashes created by the service provider. At given intervals, the current value of the super hash is further protected to avoid later tampering, publication is a strong technique. In order to verify a timestamp created with hash chaining, the service provider must be contacted by the customer after the additional protection is applied.
As of 2014 DigiStamp uses hash chaining to further protect our customers, but DigiStamp's primary technique uses public-private key encryption. To verify a DigiStamp e-TimeStamp, all that is needed is the root key of DigiStamp, which is available to anyone at any time and widely distributed.
Third-party retrieval timestamp
With this technique the user's data file is sent to a third party, most probably over the Internet. Commonly this technique includes retrieval of the document by a third party to achieve a level of delivery confirmation. The timestamp is by virtue of the third party receiving a copy of the document, receipt and transmittal.
DigiStamp's technique keeps your document in your computer, thus your data remains confidential with no chance of intercept. DigiStamp software calculates a hash for the data file. Only that hash is sent over the Internet.
Another immediate concern with the third-party retrieval method should be the solvency of the company acting as the trusted third party; if it goes out of business, the record of the transaction may never be recoverable when needed. In contrast, DigiStamp's timestamp self-contains the information necessary to verify the timestamp by embedding the public key inside the timestamp. This can be used to verify the timestamp without needing to contact DigiStamp.
Third-party retrieval receipts
The third-party retrieval technique can be combined with the retrieval of the document by an addressee defined by the document creator. The users can then be supplied with a receipt of when the addressee retrieves their copy. The veracity of the receipt depends on the service provider's ability to avoid a technical issue: an addressee can use the communication protocol to receive the document and then at the transmission of the last byte respond with connection lost -- document not received. A resolution to this connection lost issue in the protocol handshaking is still being engineered.
DigiStamp's technique supports a digital receipt which is not assured until the addressee signs and timestamps the received document. That is, the recipient must send back to the sender a timestamp from an independent third-party to complete the transaction; if not received, the sender investigates. This creates unequivocal proof that the recipient had the document in their possession at a time witnessed by the trusted third party, DigiStamp.
Local timestamp server
This technique puts a trusted server local to the end-user's LAN. This requires administration and service to ensure the proper working order of the local equipment as well as a security containment area to maintain an externally trusted server. Several issues immediately arise with this technique. First issue is the single point of failure of the local equipment. Second is the administration burden of maintaining the secure site, ensuring the trust model, and system monitoring.
DigiStamp's technique off-loads from you, the end-user, the management of a trusted server and trusted site. We allow you to outsource the difficult stuff, without putting undue burden on your internal IT resources as well as without encumbering your staff with the need to manage and maintain a trusted server site. DigiStamp puts its energy into ensuring reliable performance in its trusted sites, updating the technology and systems as required. DigiStamp keeps pace with the ever-increasing computing advances that threaten cryptographic solutions. DigiStamp's services put the burden on DigiStamp to maintain the technological edge in the complex field of cryptography. Why should you? Our volume pricing makes the DigiStamp service the better value.
The model of e-commerce is two (or more) trading partners conducting business transactions over an electronic link, most probably the Internet but with secure services overlaid to ensure the integrity of the transaction. We have had this ability for a decade or more, but not over the Internet and not without the costly expense of middle-men to build out this electronic link, then known as a value-added network (VAN). To achieve ubiquity, we must transition away from the middle-man to direct communication between trading partners using the Internet.
To effectively (and legally) do this without a middle-man (VAN), the integrity of the transaction must be irrefutable from sender to receipt endpoints. There are several means to do this, with the most popular being public-key infrastructure (PKI) services. PKI primarily addresses privacy and sender's identity. An equally important element of the transaction is to irrefutably prove that a specific transaction occurred at a point-in-time.
An example application is provided below in which timestamps are used in conjunction with PKI services to create receipts for transactions that can be stored alongside the data. In this instance, the client is a brokerage house transacting an on-line e-trade with its customer. The customer transmits to the brokerage house a trade request. This trade request becomes a time-sensitive, monetarily significant transaction. The brokerage house wants to provide a timely response to the trade request and a value-added service for its customers. Therefore, they have established a process to timestamp on-line electronic trades and provide the customer with a binding receipt.
The implementation of this timestamping of on-line electronic trades is conducted as follows: The brokerage house sends a receipt to the customer that it has received the trade request. This receipt is generated by timestamping the content of the trade request. Then, the brokerage house digitally signs the timestamp. The timestamp and its signature are packaged in an industry-standard CMS message and returned to the customer. The customer has proof that the broker had the trade request at that specific time. The customer or another third-party can verify the digital signature and timestamp authenticity.
Timestamping receipts between trading partners creates binding proof of the specific point-in-time that a transaction was received.
Any digital file can be timestamped, though it is most relevant to monetarily-significant or time-sensitive transactions, typically for e-commerce, intellectual property protection, and records integrity.
To list a few: digital office documents (spreadsheets, presentations, e-mail, contracts and legal files, patent disclosure information, copyrighted work), artwork (copyrighted work, webpages), audio (wav files, music clips, voice mail), images (photographs, faxes, videos, blueprints), patient/client records (written report, MRI images), financial transactions (banking, on-line auctions, brokerage trades), special files (software source and executable files in any language or format, product liability defense material, FDA filings, etc.
|You can timestamp a single page document, one of a 1000 pages or even more in a single document. In technical terms from the FIPS SHS standard:|
For practical purposes you can timestamp files with a size of many gigabytes (264 bits is more than 2 million terabytes). For the timestamping tools that DigiStamp provides, our developer toolkit uses a hash functions up to SHA-512 and we use SHA-256 in our Desktop software.
Core service of PKI standard digital timestamps
DigiStamp uses specialized encryption hardware that is certified by the National Institute of Science and Technology (NIST) and provide tamper detection against physical and electronic attacks, ensuring the integrity of the private keys used to sign the timestamps. The hardware and the external audit process are described here.
The associated public key used to verify the timestamp is freely published on this web site and through digital certificate authorities. However, there are no copies of the private key and DigiStamp employees never have access to this key. With this design, any attempt to access the private key by tampering with the system results in the private key within DigiStamp’s server being destroyed. The lost private key is not a problem because timestamps are verified with the public key. A new secure server with private and public key will then be created for new timestamps.
The secure hardware also contains the timestamp clock, which cannot be adjusted to create invalid timestamps and which is securely synchronized with an external atomic clock. Redundant, geographically-separated servers are used to ensure continual access to DigiStamp’s service.
Integrity over longer periods of time
When you get a PKI timestamp: you keep your data and your e-Timestamp; you have third-party proof of "when and what". Anyone can verify the timestamp’s authenticity using standard PKI software tools and no need to contact DigiStamp (or does DigiStamp even need to be in business). This is the normal use of digital timestamps as legal proof.
Now we add the Archive to the above process for the purpose of "long term archiving". For this, DigiStamp also keeps a copy your e-TimeStamp in an Archive. The Archive will perform technology renewals so we add time to the longevity of the proof. You probably won’t need the Archive, but some documents have a very long life spans. Consider your own Document Retention Periods or Library Archive Policy. More details described here.
The timestamps cannot be forged by anyone, including the people at DigiStamp. DigiStamp uses both one-way hashing and very strong encryption to ensure the integrity of its timestamps. A "one-way hash function" yields a hash value or fingerprint of the file from which it is impossible to reproduce the original file. It is "one way" because one can go from the file to the hash value, but one cannot reproduce the file from the hash value. If even one bit is changed or moved in the original document, then the hash value would also change. But, if the same hash function is applied to the same original file, the same hash value is always generated. Thus applying the same hash function to the original file and comparing that with the timestamp content will reveal whether the file has been altered.
An originator transmits a representation of a digital file, its hash value, to DigiStamp for timestamping. DigiStamp creates a timestamp containing the hash value of the file and the current time and then applies its verifiable digital cryptographic signature. The strength of a cryptographic signature depends on the key size of the algorithm used. RSA 2048-bit key asymmetric encryption is used, one of the strongest on the market.
If you are protecting data for 10 years or less then the risk of technology obsolescence is low and your RFC 3161 timestamp will be your proof during that period. For greater longevity, you may need services of our Archive: for timestamp renewal or hash-chaining timestamps. The DigiStamp Archive keeps a copy of your timestamp and automatically goes about renewing your timestamps so your e-TimeStamp stays valid over time, until you need it as proof.
Our RFC 3161 e-TimeStamp has no specified timetable for expiration; however, it will cease to be evidence if the cryptographic algorithms used to create it fail. The failure of these algorithms is inevitable on the long term but very unlikely in the near future. We use the same RSA and SHA algorithms used by governments and financial institutions (remember they use our service too).
Renewal techniques are being used in the DigiStamp Archive.
1) If failure of the Digital Signing algorithm RSA is feared, a timestamp can be renewed by creating a record of its authenticity (a timestamp of the timestamp) using improved signing technologies. Timestamping will demonstrate that the signature in the original timestamp was valid before the signing algorithm failed, and thus it will continue to be valid.
2) If the failure of a Hashing algorithm is feared, the still unaltered data must be hashed with a more secure Hashing algorithm and combined with the prior timestamp to create a new time stamp.
In accordance with DigiStamp policy, we keep all customers apprised of security concerns that threaten their evidence chain. No such notifications have been necessary.
How does this conform to your x.509 public key certificates having expiration dates?
A RFC 3161 time stamp is valid beyond the expiration date of its public key certificate.
Signing certificates, including ours, have expiration dates to indicate when they should cease to be used. A digital signature created with a now expired certificate is not valid unless it can be proven it was created before the certificate expired. This was one of the original needs which prompted the creation of timestamp authorities (more details here). A timestamp is unique because it contains a “trusted time of creation” in the signed content. So, because we meet the requirements laid out in RFC 3628, signatures created by our TSAs as timestamps do not expire at the end of the signing certificate's life because the time they include is trustworthy. The long term validity of our timestamps is also supported by the fact that we reliably destroy the private key. In practice this is done every 1,000,000 timestamps or 1 year within our FIPS 140 certified hardware. You can read more about SecureTime here. In addition, starting in 2012, DigiStamp maintains a hash-chain-linked archive of the timestamps created (more details here).
For more information refer to Annex C of RFC 3628.
To verify timestamps you will need software. Our timestamps conform to RFC 3161 and so can be understood by software that supports that standard. Of course, our IP Protector and Verify tool can be used.
Other Tools that Understand RFC 3161 Timestamps
- OpenSSL, the standard command line tool for cryptographic operations. We provide examples of verifying timestamps.
- Adobe Acrobat verifies timestamps created as part of a PDF document. It is a powerful data-integrity tool to put a third-party timestamp on the content of any document that you can convert or print to PDF. The free Adobe Reader has a "add timestamp to this PDF content" built-in. Adobe's software accepts and verifies the DigiStamp timestamps - proof of the PDF file's content at that point in time.
- Java and C# software developers can use open-source Bouncy Castle Crypto to verify and request timestamps.
A step-by-step description of using the DigiStamp IP Protector software to verify a timestamp is here.
The certificates can be retrieved manually from the DigiStamp web site here.
If you are simply ensuring you've saved all the data needed to verify your timestamp later, go here.
If you are looking for a description of how a timestamp is verified, go here.
Other Tools that Understand RFC 6283 XML Evidence Records
There are no public domain solutions that we know of. The digital, long-term Archive, and this defined standard for evidence records are relatively new. Usage of these methods, or this specific XML protocol, has not previously been used for this type of a cloud service. If you know of techniques or tools from other parties please send us an email.
There are three essential items required to verify a timestamp:
1) The original file that was timestamped. This document must not have been modified since the timestamp was created.
2) The actual timestamp that was returned from the DigiStamp server: the digital signature created by the TSA
3) The public key to verify the authenticity of the signature in the timestamp. All DigiStamp timestamps include their public keys.
DigiStamp implements the IETF's RFC 3161, a standard for PKI-based trusted digital timestamps.
A data file is authenticated by comparing its fingerprint to the signed fingerprint in the original timestamp. An implementation of the SHA algorithm generates the file’s current fingerprint as described in how it works. The digital signature in the timestamp is now decrypted, using the public key, and it is confirmed that the hash signed by the TSA is an exact match to the hash of the file being authenticated. A change to the protected file will prevent it from resolving to the same hash and, consequently, from verifying against the signed information. Any change to the timestamp signature will render it invalid and so the timestamp will not assert anything.
Public key hierarchy
You can download a copy of x.509 standard certificates that contain our timestamp public keys here.
DigiStamp performs as an Intermediate Certificate Authority (CA). DigiStamp signs the public keys used in timestamping with an intermediate root certificate. A single intermediate root certificate is used to issue multiple timestamping public key certificates. The certification path of the intermediate root key is from CAs whose certificates are already in common software applications. There is additional detail on this subject and how your organization can integrate the DigiStamp certificates with your PKI environment described here.
Timestamped public keys are in a certificate signed by DigiStamp performing as an Intermediate Certificate Authority. The x.509 certificate has extended attributes designating this key be used for timestamping only.
If you are simply ensuring you will be able to verify your timestamp, go here.
If you are looking for non-DigiStamp tools to verify your timestamp, go here.
The primary source for standards we use to manage and create the timestamp service are defined by the Internet Engineering Task Force (IETF). The timestamp is an extension to the Public Key Infrastructure (PKI) used for digital signatures. This industry-standards body meets regularly to advance the Internet and its ubiquitous uses. Its proceedings and standards can be found at the IETF web site. A few of the core message-format supports are as follows. A more extensive list in on Page 5 of DigiStamp's TSA Policy and Disclosure.
Signed Content - The signed message contains the time from DigiStamp's secure clock and the message digest of your document as defined in the timestamp x.509 PKI Timestamp Protocol IETF RFC 3161. This standard was later described in standards ISO/IEC 18014-2, ETSI TS 101 861, and ANSI X9.95
Evidence Records - Processing rules and an XML format for maintaining and communicating long-term records of the existence and integrity of data, IETF RFC 6283. This is an XML Syntax (XMLERS) version of the prior ASN.1 version described in RFC 4998.
Timestamp Token - The timestamp service returns a signed message in the standard form of Cryptographic Message Syntax, based on PKCS #7 version 1.5, IETF RFC 2630.
Company operations and policy - These policy requirements are aimed at timestamping services used in support of qualified electronic signatures. This standard may be used by independent bodies as the basis for confirming that a TSA may be trusted for providing timestamping services. Users can consult the DigiStamp's practice statement to obtain further details of precisely how this timestamp policy is implemented. The standard is published as: Policy Requirements for Timestamping Authorities IETF RFC 3628 and is technically equivalent to ETSI TS 102 023.
Public Keys - The public portion of the signing key is available as an x.509 certificate IETF RFC 2459
Message Digest - A unique value is calculated from the data to be timestamped using the SHA-2 message digest as defined in the Federal Information Processing Standard Publication 180-1 "Secure Hash Standard". Software update April 2005 details: Our Desktop software uses SHA-256 to create the timestamp of your file. Our Internet TSA servers and API tookit support SHA1 through SHA-512 and RIPEMD-160.
Long-term, legally-binding digital signatures - With our most recent software release, you can create your digital signature, commitment types, and countersignature based on updated digital signature standards in IETF RFC 3126 "Long-term electronic signatures" and the European digital signature standard ETSI TS 101 733.
Contained within each timestamp is a numerical value in seconds stating the accuracy of the DigiStamp secure clock as defined by the IETF TSA specification. This value is currently set to one second as a statement of accuracy of our clocks and synchronization methods. This is the maximum difference of DigiStamp's clock from the U.S. official time standard.
The clocks used to create timestamps are regularly synchronized with DigiStamp's master time source, which is itself synchronized with the U.S. Naval Observatory, the official standard of time in the U.S. The clocks we use are very accurate but the synchronization is required to adjust for drift, which is a specification in any design using a time source.
When the secure environment is first created, the clock is set before creation of the private key. At the end of initialization, all external access to clock settings is disabled, including DigiStamp's access. The secure clocks will accept only small adjustments of a few seconds for drift to avoid a malicious attack on the secure server's time reference. For example, it would not be possible to adjust the secure clock back by a day or even a few minute. This rule is enforced by the NIST- certified hardware. This prevents creating a timestamp with the secure private key that is back-dated.
Each adjustment made to the secure clock is recorded in an Audit log contained with the NIST- certified hardware. This audit log is maintained and then signed by the hardware as proof of when drift adjustments were made. See details here.
Attempts to tamper with the clock by any other means is detected by the secure hardware and the private key is destroyed.