11
$\begingroup$

You put an input and the hash value comes as an output then when someone puts the input the hash function it is applied to see if it is the same hash original value is stored in some database , that is how it works if I remember it correctly.

However I am having some trouble understanding timestamps now, I have just used a timestamp service, univerisign.

I sent the file to timestamp it and I believe the input is the file and the date and by using sha512 it creates a document signature, this is exactly what has done: My document was example.pdf:

Title

testing the document.

and after using the service, it appears example.pdf:

Title

04_02-2012

testing the document.

It also comes a file called example.pdf.ers wich I believe It is the hash value but How can I prove the validity of a document timestamped by Universign?

This is how the web answers it:

Universign uses the timestamp protocol defined by the IETF RFC 3161 standard. You can use any software compliant with this standard to check your timestamp seal.

What does this mean?

  • How different is my example.pdf document from a fake one fake.pdf with the same date written on it?

  • Does my example.pdf have any security characteristic or is it just a normal pdf document and all the verification information it is stored in example.pdf.ers?

I think that if universign was able to gave me a proof of the document, a smart one could easily create a fake proof of the document by giving the fake input including the date, maybe It is got to do with the credentials of the organization in this case universign as not all timestamps are valid and probably example.pdf.ers is saved in universign.eu database and that is why it is valid.

Note that my question although long it is specific I just tried to answer it while formulating it, It is all about understanding the verification of timestamps.

$\endgroup$
1
  • $\begingroup$ It is important that I just noticed that my document was written in lyx(latex) and I checked before timestamping in .lyx format and after it in pdf format, I am almost sure example.pdf does not change and they just give you another file and you keep the original as It was. $\endgroup$ Commented Feb 4, 2012 at 20:00

4 Answers 4

7
$\begingroup$

Actually Universign produces "Evidence Records" as described by RFC 4998. Evidence Records in turn rely on standard time stamps which RFC 3161 is about. Evidence Records can embed several nested time stamps; this is used for long-term archival, when you want time stamps to remain verifiable beyond the end-of-validity of the certificate of the time stamp authority, or even when one of the hash functions which were originally used becomes broken. Evidence Record Syntax (ERS) includes provision for regular maintenance, namely spraying a new layer of paint (a new time stamp) whenever needed.

As a general basis, a time stamping authority (TSA) works like this: it receives a document hash, and applies a digital signature on a structure which contains the hash value and the current date -- the date is measured by the TSA, not provided by the client. The signature, when verified, "proves" that the TSA was involved, and since we trust the TSA for having a well-maintained clock and never signing any structure for which it did not write the current date itself, this proves that the document hash existed since the announced date (at least). Hash functions being nominally impervious to preimages, this in turn demonstrates the existence of the document at that date.

The cornerstone of the trust is the "honesty" of the TSA, which, administratively speaking, goes through certifications. Various institutional bodies verify, through audits and procedures and mountains of paper which required whole forests to be cut down, that the TSA has been developed and is maintained with enough security, in a way which can be audited. In the case of Universign, they can boast such certifications as can be obtained from French government; in effect, France says: "their time stamps are good enough, that they can be used as proofs in legal proceedings, the burden of proof lying on whoever is arguing against the validity of said time stamps". This can be assumed to more or less extend to the rest of Europe, at least in the near future (the legal systems for electronic signatures and time stamps are slow to spread, but Europe is trying to push them in an harmonized way -- as always, things work differently in America, so the legal status of Universign timestamps in a US court is much less guaranteed).

$\endgroup$
4
$\begingroup$

I didn't try the service of universign, and the description on their web site is not really clear on how it works.

So I had a look at RFC 3161, which defines a time stamping protocol.

In essence, the service defined there

  • accepts a hash of the message (or document) to be time-stamped, together with some parameters
  • produces a time stamp token.

This time stamp token is in fact nothing more than a (encoded) data structure consisting of the following data fields, together with a digital signature thereof.

  • some meta data (version, used policy)
  • the stamping time (and optionally an accuracy measure thereof)
  • a serial number
  • the hash of the message/document

The digital signature links these fields together, and is a proof that the time stamping service asserts to have seen this hash at the time specified.

I assume your example.pdf.ers file is just such a time stamp token. You can check its validity (i.e. that it is really produced by this service) using any program which supports the cryptographic message syntax defined in RFC 2630. You then also have to look at the fields and see if they make any sense ... and if the hash really is a hash of the document in question.

Now, the website seems not to accept a TimeStampReq structure as defined in the RFC, but to have an upload form for the data, and in case of a PDF file, it seems to modify this file to include the date (if I understand the question right - I didn't try it). So most likely the website is itself hashing the document, and then internally calling a service like described in the RFC to do the timestamping, and return the TimeStampReq (as well as the modified PDF).

So, to check the time stamp with your document, you (or an application which does this for you) have to hash it again using the same hash algorithm (it is included), compare the hashes, and then check the digital signature. (You should also check any certificates which certify the time stamping service, and check the relevant key revocation lists.)

The modified PDF alone does not prove anything.

$\endgroup$
1
  • 1
    $\begingroup$ There are several ways to timestamp a PDF file. You can handle it as an opaque blob, and produce an external time stamp (or evidence record). You can also embed the time stamp in the file, because the PDF format includes some provisions for it; such a time stamp can be verified from within Adobe Reader itself. Universign supports both; see: universign.eu/en/web-services $\endgroup$ Commented Feb 7, 2012 at 12:56
3
$\begingroup$

You may be interested to check this quite interesting approach to time stamping: http://www.guardtime.com/

It provides KSI (Keyless Signature Infrastructure) for providing proof and non-repudiation of electronic data, using only hash functions for verification. The implementation of KSI is via a globally distributed machine, taking hash values of data as inputs and returning keyless signatures that prove the time, integrity, and origin (machine, organization, individual) of the input data.

Take a look a their extremely well written "technology page": http://www.guardtime.com/technology/

It seems a very smart implementation that goes beyond simple times tamping of documents and with a robust and simple verification process. Hope it helps.

(I'm not affiliated with GuardTime in any way, but I'd love to work fot them though!) :-)

$\endgroup$
1
$\begingroup$

As we find in answer http://answers.onstartups.com/a/41679/19173 , there are many methods of cryptographic Timestamping. Take a look for comparison of popular methods: https://en.wikipedia.org/wiki/Trusted_timestamping

RFC 3661 seems very poor in comparison to other methods, it only utilizes PKI. IMHO PKI is not best fit for timestamping purposes.

ISO/IEC 18014 utilizes PKI+Linked+Dadates schemes.

X9.95 , especially in hybrid variants seems most reliable as utilizes: Linked and signed scheme, which can be still reliable even PKI compromised, thanks to second Linked scheme.

I agree with Marco Barulli about guard time, that is an interesting example of hybrid approach. A kind of mixture of distributed hash-trees, which top-hash is printed in Financial Times, you might like to take a look at technology overview (you need to click each section in order to roll-out).

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.