Timestamping FAQs - Industry standards and technology

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.

Hash chaining

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.

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.

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.

Will my DigiStamp timestamp expire?

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.

Alternate timestamp technique used by DigiStamp is hash chaining as implemented in the DigiStamp Archive.

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.

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.