I need a way of authenticating that a file was generated by a particular machine that has a unique ID and a unique random secret also known to the authenticator, as an added difficulty the file producer cannot directly communicate with the authentication machine. My current methodology is as follows:

File gen:

  1. File Producer passes time and secret to a non-reversible hashing algorithm and exports that

{ id: 1337, time: 1435102405, oneTimekey: 99754106633f94d350db34d548d6091a, ... }

File Authenticity Check:

  1. If the time specified in the file is within arbitrary bounds and a secret associated with the ID is found continue otherwise fail
  2. Passes time and secret to a non-reversible hashing algorithm if it matches the oneTimeKey then it is assume to be valid.

In this methodology I have to store the secret in a database, I would prefer not to do this but I can't think of an effective way to achieve this goal any other way. Have I looked over something? Can I achieve this without storing the secret on the authentication side?

  • 1
    Would a TOTP - RFC6238 implementation satisfy your need well enough? – Anti-weakpasswords Jun 24 '15 at 3:01
  • @Anti-weakpasswords the more I think about this RSA signing of the file is a far better method than ether my crude idea or TOTP - RFC6238. Not sure why I didn't think of that first. – xanth Jun 24 '15 at 4:53
  • 1
    If all you're doing is validating that in a local-tamper-resistant manner, then yes, a public-private signature where the signing devices have unique private keys would seem reasonable. You can sign a timestamp, if you like to know about timing :). – Anti-weakpasswords Jun 24 '15 at 13:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.