9

I’m looking for a source of on-line cryptographically signed date/time. I do not need a full timestamp service, as I am happy with the information « date/time was that », without a link to a challenge/hash that I provide. I do not care if an active adversary feeds my trusted device an old (even very old) date/time ; I’m only concerned with attempts to feed it a date in the future. My trusted device could be a Smart Card that I can program, connected to an untrusted PC.

I would like something with no fee or need to authenticate in order to obtain a new certificate. I'm OK for a yearly fee to the authority providing me that service. I anticipate a mere ten thousands requests over a year. I could live with service interruptions or date/time lag not exceeding an hour.

I’m thinking of purchasing a regular SSL (or similar) certificate from a commercial CA, and using the revocation services they provide for that certificate, which I’m told respond to queries « is this certificate still valid? » with a signed message « by (explicit current time) this certificate is valid », that I’m then able to check using the long-term CA public key.

Does that seem sound? Which suitable protocol is widely supported by commercial CAs? Is my usage allowed by normal commercial CA practices/term of uses?

Any alternative?

Late additions:

I'd very much prefer something such that the trusted device can verify a moderate amount of data (e.g. signed message, certificate), statically submitted to it by the untrusted PC host.

The job of the trusted device should be simple (due both to limited resources, and the need to ascertain that the implementation is secure).

I would prefer that the cryptographically signed date/time could be obtained in a single TCP/IP session, and I'm not ready to setup an email address per point where I need this service.

My requirement for free requests is not so much about the fee, but about the practical need to authenticate in order to request anything obtained for a fee. A password is out of question. Even a weak authentication by IP does not fit (switch to a backup internet access in an emergency and poof goes the availability).

I have nothing against a free service, but I'm willing to pay to lower the odds that the service is terminated, and make someone embarrassed if the clock jumps in the future.

D.W.
  • 98,420
  • 30
  • 267
  • 572
fgrieu
  • 1,072
  • 7
  • 19
  • 1
    Is there anything preventing *you* from operating a service that meets your exact specifications? You're willing to pay, and it seems likely that you could assemble it from freely available components and host it yourself. Linode (for example) runs about $200 a year; depending on your requirements you may be able to use a cheaper host. – bstpierre Dec 06 '11 at 22:13
  • @bstpierre: My overall application is that the trusted device produce certs of some sort, with a limited period of validity from current date/time. Certs in the future would be a serious issue. If the time service is run in-house, the people able to tamper with it are the same (or close) to the ones with an incentive to do so, in order to subvert the trusted device to generate certs in the future. Thus I prefer an independent date/time source. – fgrieu Dec 07 '11 at 08:12

3 Answers3

6

I think you could use any web site operated by a reputable company that supports access over SSL. The one quirk is that the list of certificate authorities that might sign their certificate could change.

For example if you retrieve https://www.google.com/ you'll get something like:

HTTP/1.0 200 OK
Date: Tue, 06 Dec 2011 17:02:40 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
...

Notice the Date header right in there?

If you're paranoid, you might want to maintain a list of possible web sites to access, just in case something happens to one of them.

David Schwartz
  • 4,203
  • 24
  • 21
  • Did not think of this one; it is free, and I could easily check several sources and survive a few rogue ones. However, short of a full https stack in my trusted device, I fail to see how to implement that. I'd prefer a static certificate, or data structure that can be statically and simply checked, which is a much better fit for my environment. I'll add that requirement. – fgrieu Dec 06 '11 at 17:19
  • Yes, you'd need at least SSL and TCP. You could fake the HTTP part pretty easily since all you need are the headers. – David Schwartz Dec 06 '11 at 17:36
4

If you are ready to make an explicit request every time you want a signed time token, then you may as well request a regular time stamp. There are a number of free time stamping services around here, operated by CA for use with Authenticode. For instance, at that URL:

http://timestamp.globalsign.com/scripts/timstamp.dll

there appears to be a TSA which runs the standard time stamping protocol.

Although it is provided without any guarantee of quality (you get what you pay for, and it's free...), one may suppose that, under normal conditions, the TSA operator will strive to keep the TSA clock reasonably accurate; whereas an OCSP server only needs to be as accurate as the natural latency of any revocation service, i.e. it could be off by several minutes without anybody noticing.

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • Seems quite close. Even though the standard timestamping protocol seems a bit complex for my trusted environment, it is safe and reasonably easy to implement most of it in the untrusted PC, and have only the crypto verification of a pre-formatted blob in the trusted device. – fgrieu Dec 06 '11 at 17:42
  • However, the lack of insurance of continued availability worries me. I'd prefer a paid-for service, as long as it does not come with a requirement to authenticate; even a weak authentication by IP address is a pain (switch to a backup line and you are toast). – fgrieu Dec 06 '11 at 17:45
3

Google Search

Free one that has been around forever: http://www.itconsult.co.uk/stamper.htm

Aside from that, your first paragraph is hard for me to understand. Your 3rd paragraph seems brilliant for preventing future-time signature. A hash of your data + a timestamped and signed revocation response from a CA does provide great confidence that the message cannot be future-stamped -- the hash cannot be generated before the matching CA response.

Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171
  • Thanks for the recommendation of this free timestamping service. However, with these, there is no standard protocol, and long term availability worries me. – fgrieu Dec 06 '11 at 17:08
  • Further, email is not the most convenient way for me to get the result. A single TCP/IP connection for request/certificate would be best. I'll add that requirement. – fgrieu Dec 06 '11 at 17:21