Timestamping FAQs - Industry standards and technology
Expand All FAQ items : 
A directory of FAQ's on other subjects is here.
Industry-focused questions
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.
DigiStamp returns the timestamp to the requester without maintaining a local copy. 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 advantage is that you have an independent copy of your proof. The timestamp returned is less than 700 bytes. 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 hash created by the service provider. At given intervals, the current value of the super hash is published in a public medium to avoid later tampering. DigiStamp's technique uses public-private key encryption. DigiStamp does not keep a record of all hash values timestamped. To verify a DigiStamp e-TimeStamp, all that is needed is the public key used to sign the timestamp, which is self-contained in the timestamp and can be verified without contacting DigiStamp. |
|||
| 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. |
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.
Technology-focused questions
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 and well beyond the 512 and 1024 commonly used today.
DigiStamp’s service can also authenticate a data file by comparing its fingerprint with the fingerprint in the original timestamp. The SecureTime API Toolkit generates the file’s current fingerprint as described in how it works. The toolkit compares the new fingerprint to the contents of the original timestamp. The software uses the public key to prove the timestamp is authentic. Any change to the original file or tampering with the timestamp will invalidate the file's authenticity.
You can send your file and the timestamp to anyone as proof of the content at a point-in-time.
There are three essential items required to verify a timestamp:
1) The original document 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.
3) The public key to verify the authenticity of the timestamp.
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.
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 message-format supports are as follows:
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.
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
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.