Expiring AES Key

Question

Is there any way to make an "expiring" AES key?

Here's scenario to give a better picture:

Say Bob has some data which he would like to share with Alice. Alice has a public and private key, let's say RSA 2048. Say Bob dos not know Alice very well, she might not take care of her public and private keys (or may simply be "computer illiterate"), and given enough time, her public and private keys could get compromised.

Bob encrypts some data with a magical AES 256 key that expires after a week.

Bob uploads the data to a file sharing service. Assume that there is no way to delete that data from the file sharing service, i.e. files reside on the server indefinitely.

Bob sends Alice an E-Mail encrypted using Alice's public key, in which Bob gives her the magical AES key to decrypt the data that he has uploaded to the file sharing service.

Assume Alice never decrypted that file. (This is important in this scenario, explained later.)

A year has passed since Bob shared that file with Alice. Alice has got her computer compromised and Mallory now has access to her computer. Mallory snoops through her computer finding her encrypted E-Mails, which he decrypts using Alice's private key, as she did not set a passphrase for her private key.

Mallory downloads the file and tries to decrypt it using the magical AES key. Since more than a week has passed (a year to be exact), and the magical AES key has expired, Mallory is unable to decrypt the file that Bob shared with Alice.

As Alice never decrypted the file, Mallory can not find any traces of the contents on Alice's hard drive. (We could simply assume she decrypted it onto a ramdisk, but Alice may or may not be "computer illiterate" so I went with not decrypting the file at all.)

I know the above is a very specific scenario, but is creating a expiring AES key in any way possible?

Answer 1

You cannot create a key that expires in the manner that you described.

You could, however, change your protocol somewhat to make it resilient to the specific scenario you're describing.

Instead of sending Alice the data decryption key, you send her an access token for that data decryption key. You then setup a server that will first ask Alice to authenticate herself (presumably, using her private key) and then provide that access token. In response, the server will send the data decryption key but it will only do so if the token hasn't expired.

In your scenario, that will prevent Mallory from obtaining the data decryption key a year later even if she has access to Alice's private key because,, although she can authenticate with the key server and the access token, the later will be expired and will not grant access to the data decryption key.

This, however, introduces several constraints to the system: first, in no case should Alice retain the decryption key after having used it. Second, decryption can only be performed when Alice has access to the key server. Third, the key server itself needs to be properly secured.

Answer 2

You would still have this problem even if your decryption key expired. Say Alice is a real dimwit like you've described and she decrypts your file and leaves it decrypted on her hard disk. Alice's computer dies and Mallory sees the decrypted file without ever having to search for a decryption key! Your problem is not a technology limitation, it's a problem with trusting who you share data with. If Alice really needs to see the data, but she is too dull to handle sensitive data securely, then you need to host the data so Alice can only view it and not copy it. If you host it, then you can also restrict Alice (or Mallory) from viewing it whenever you want.