Notary systems requirements

[Alfonso De Gregorio <agregorio@xxxxxxx>]

Hi Everyone,

what about to start to working on a document that collects requirements
for notary systems based also on TSAs?

In my opinion, the current TSP don't allows always the use of a
time-stamp token as a proof-of-authorship, because the security
analysis of the protocol don't address the possibility of a 
deliberate replay attack by a middleman replaying legitimate TS
_requests_; the point 6 of section 4 of rfc3161 puts replayed requests 
to TSAs down to problems in the intervening network elements.


An additional middleman attack scenario:

- Alice writes a poem and wants publish it on her own public homepage;
- however, Alice is afraid that, upon the publication, Eve read the poem
  and re-publish it with her (Eve) name.
- Eve, knowing Alice's interest and talent, start to eavesdrop Alice's
  network;

Note: the attack scenario is possible either because the channel between 
      Alice and the TSA does not give necessarily confidentiality, or
      because the are no requirement yet on how Alice must construct the
      message imprint being time-stamped while she wants
      proof-of-authorship on corresponding documents (eg. public available
      documents).

The (simple) attack
- Alice computes the hash of her poem with the preferred hash algorithm
  and sends a TimeStampReq to TSA1 (TSA1Req) where TSA1Req.messageImprint
  is the computed hash value;
- Eve intercept Alice's request an makes a copy of it, TSA1ReqCopy;
  Eve rip the associated messageImprint and computes another 
  TimeStampReq with the same hash for TSA2 (TSA2Req);
  Eve send TSA1ReqCopy to TSA1 and TSA2Req to TSA2; 
  these are request of certification of claimed possession of data;
- Alice is still waiting the time-stamp token; but as we know TSP gives
  no warrants about response time (eg. the tsa can use also smtp...)
- Eve collects the two responses associated with TSA1ReqCopy and TSA2Req
  (TSA1Resp1, TSA2Resp) and keep them secret;
- than Eve sends TSA1Req to TSA1;
- TSA1 receive TSA1Req and process it; this is a replayed request, however
  the time-stamping authority perform only basic checks on the imprint
  being time-stamped, as REQUESTED in points 7 and 8 of section 2.1:

   7.    to examine the OID of the one-way collision resistant hash-
         function and to verify that the hash value length is consistent
         with the hash algorithm.

   8.    not to examine the imprint being time-stamped in any way (other
         than to check its length, as specified in the previous bullet).

- Eve receive the time-stamp token produced by TSA1 (TSA1Resp2) and check 
  if the absolute value of the difference between the genTime of the first 
  time-stamp token (TSA1Resp1) and the genTime of the second time-stamp 
  token (TSA1Resp2) is greater than the sum of the accuracies of the
  genTime for each time-stamp token;
- if the condition is true Eve routes TSA1Resp2 to Alice;
  this is a well-formed and consistent response, but the genTime associated
  with reports a time successive with the one indicated in TSA1Resp1;

- now Eve can make a brute-force attack on the imprint or try to break
  on the Alice's computer, but she prefer to wait the publication of
  the poem on the Alice's personal public homepage :-)
- Eve claim to be the real author of the Alice's poem;
- Eve and Alice show their own time-stamp token in a trial;
- Eve wins.

To avoid this attack, Alice must be required to hash the sign the
document she wants to  time-stamp; compute the hash over the signature
of the signed data and set the messageImprint field of time-stamp
request to the computed value (similarly to what is required in 
Appendix A, for the proof sign creation before corresponding certificate
revocation).

Regards,
alfonso