Saturday, October 10, 2015

Expiring AES Encrypted Message

As told in previous post I implemented some kind of PGP for encrypting sensitive information like login username and password. So first use openssl friendly AES to encode login information, then encrypt AES random key and salt with RSA public key, in page side, then reverse it on server. So they can ensure the information cannot be decrypted easily by man in middle (I know using https may help a lot for such things, but I liked to add my security layer there to have full control on what happened).

But another challenge appeared that was what happen if a man in middle get the ciphered information including the encrypted message and encrypted key and use them to submit, server validate and it works, while user hasn't changed its password. Another thing that got on my nerve was the hard-coded string of openssl on AES message (Salted__). So combination of these two led me to replace the fixed string by the timestamp.

Now I have the the time AES key is generated and I can compare it with the server time and if it pass a threshold, assume message as expired and leave it. It is still not a certain way to prevent man in middle completely, but with a good threshold can mitigate the risk. I chose 3610 second, 1 hour because of day light saving and 10 seconds for network and computing latency.

So the timestamp is added as part of the salt and 'Salted__' prefix is replaced by that time in encoded format. The format of message will be as:

8 bytes encoded timestamp + 8 bytes random salt + encrypted message

In this case even if the message prefix time is changed to show not expiry, the decryptor can detect it and not decrypt it, since that timestamp is used as part of encryption salt and make key faulty. That's my PGP implementation that I called OPGP or Omid PGP.

Cons:
As mention it depends on client system time, so if it is wrong, it never can get through, or I put 1 hour in my threshold to support daylight saving mismatch between client and server that increase the risk of hijacking information. For this one I'm going to test existence of a time variable that supposed to be set by server on page and compare with local time, then use up to dater one.

No comments: