AES Key Generation Strategy/Algorithm For Offline System

Question

Let say I have several application that aren't connected to any network, and I have one requirement that says each application could produce a token from an input that other application could validate the token provided the same input is given to it.

For example, a person accessing application 1, input a string and get a token, then he/she travels to application 2, input the string and the token to it, then application 2 tells to the person if the token is valid or not. Even thought the token is exposed to users, it should be safe enough that no one could fake it.

In prototype phase, I simply encrypt the input using AES with a hard coded 128 AES Key and then obfuscate the cipher text a little to generate the token. But I still have some worries as I get an impression that using same static key for symmetric are vulnerable and easy to compromise.

Because there's no means for these application to talk to each other and which application will validate the token generated by which application, I'm planning to use some kind of AES Key generation to renew AES key periodically for all applications. I was hoping that the key will be different from time to time, but all the application will be using the same key at anytime.

Is there exist an open standard algorithm or strategy to generate AES Key that meets my need above? Maybe I haven't look enough, but I can't seems to find it.

Thanks in advanced!

Answer 1

The most secure method is to use digital signatures. Generate a public/private keypair. Application 1 gets a copy of the signing key (private key). Application 2 gets a copy of the verification key (public key). A token is now a signed string, signed by Application 1.

When Application 1 wants to generate a token, it can simply sign the string; the token consists of the string and the signature. Application 2 can verify the token by verifying the signature.

Note that this approach does not prevent replay. If a person gets a token from Application 1, he can provide it to Application 2 as many times as he wants, and it will appear to be valid each time.

If you want to prevent replay, one way to defend against replay is to ensure that the string being signed contains all details of the request, and to ensure that the request is idempotent (performing it multiple times has the same effect as performing it once). If you do that, replay becomes irrelevant.

Alternatively, another simple method is to have Application 1 include the current time and a random 64-bit number (a nonce) in the string. Application 2 can check that the time is reasonably recent (say, no more than 24 hours old), and check the nonce is not on its list of recently-accepted nonces; if both checks pass, Application 2 accepts the token and adds the nonce to its list of recently-accepted nonces. (You can garbage-collect this list periodically: there is no point retaining a nonce from a token that is more than 24 hours old, as the time check will ensure that token will not be accepted as valid.)

If you try digital signatures and find that they cause performance problems, another suitable replacement is to use a message authentication code with a symmetric key (instead of a public-key signature algorithm). When using a message authentication code (MAC), there is only one key, and both applications will need a copy of the key. In principle, MAC-based tokens are slightly less secure, because now you have more copies of the secret key floating around. That said, in practice in most situations MAC-based tokens are probably acceptable. The difference between MAC-based tokens and signature-based tokens is unlikely to make a big difference to the security of the overall system, as most likely the weakest link in your system will be something else.