2

I've been looking, but I think its impossible to find a pairing solution that has the benefits of authorization expiration and renewal (like x509 cert expiry and OAuth expires_in), but that works without a reliable clock.

I want it because renewal is a chance to phase out vulnerable crypto algorithms and keep active authorizations up to spec. The catch is the system I'm implementing this in can't reliably get to NTP servers and it has no battery clock to preserve time through reboots (every few days it reboots), so determining if an authorization is still valid is practically impossible.

Is there a solution? Maybe there are alternatives to get clients to renew?

Raveclatter
  • 21
  • 1

1 Answers1

1

Your question first sounds ironic, because you seem to not want to use or trust NTP while I assume your system is connected to the Internet.

But what if we assume that you do not trust you connection to the Internet and fear a MITM attack or other tempering. This would render the NTP indeed useless. But with preshared initial certificates, your primary system could work. And you will have to trust (at least some of) your successfully verified communication partners.

Here, you have still an option for the expiration feature: you can ask your other valid peers periodically for the time (sort of reimplementing NTP in your application). This should yield you a clock with at least a precision of some seconds (or better). If you reboot you can save the last time, and asked for the time as soon as possible. However, if you reboot your system within minutes, you still maintain a clock with a precision of minutes (So your clock on a freshly rebooted system never derivate for the actual time further than the time it takes to reboot). Since certificates are usually issued for about a year, a precision of minutes a perfectly fine.

If you mean your problem is, that you do not have a something to count real time, you still can go with a logical clock. So you can e.g. count how often a certificate is used (signing/verification) and reissue a new one if a threshold has been exceeded or expire the certificate if used further. You can either count this per certificate or for all together.

Cryptjar
  • 221
  • 1
  • 4
  • Thanks for your response! I'm glad you made sense of my question. Asking peers for their time is possible, but the cost to have peers implement that is too high to be practical. The real problem I'm trying to solve is how to defend against authorizations getting leaked / compromised or attackers retroactively cracking recorded communications. OAuth has short lived authorizations for this reason and that's what I'm after, but no time! I guess we could put a "use limit on each" in the hopes that peers come back every so often. – Raveclatter Oct 24 '17 at 12:06