5

We're designing a database system to store encrypted strings of information, with encryption and decryption performed client side using public-key cryptography. If the key was ever changed though, this would necessitate reencrypting all the records client side, which is very impractical. Is there any way this could be performed server side without exposing either the original (old) decryption key, or the message text?

I guess what I'm after is an associative cipher, something like this:

T( Eo(m) ) = En( Do(Eo(m) ))

where Eo(m) is the cipher text, Eo/Do the old pub/priv key pair, En the new pub key, m the message text and T the magical reencryption function. Edit: T is calculated clientside and then sent to the server to be used.

jade
  • 744
  • 5
  • 16
Mikey Top
  • 63
  • 2
  • 8

2 Answers2

2

You can't retroactively disable the old key anyway. Anyone who has access to the old data and the old key can decrypt the data no matter what you do.

I would suggest simply keeping a ring of keys. Add the new key to the ring and mark it active. Mark the old key expired. Code the client so that if it finds any data that's encrypted with an expired key, it re-encrypts it with the active key. (Or don't. What's needed depends on details of your implementation requirements.)

If desired, after a period of time, you can sweep for any data still encrypted with the old key and re-encrypt it.

You can't eliminate the exposure of the old key anyway, ever -- anyone who can find a backup or copy of data encrypted with the old key can decrypt it if they have the old key. Encryption keys must be protected forever or you get the fiasco that released the Wikileaks diplomatic cables to the public with the names of informants intact.

David Schwartz
  • 179,497
  • 17
  • 214
  • 278
  • Thanks David. No client has full database access, so if the private key was compromised the damage would be limited, and all records could be immediately reencrypted. – Mikey Top Dec 18 '11 at 06:21
  • The problem is that the person who compromised the key probably already has the encrypted data. [You have to protect the key forever or any data that was ever protected by that key is compromised.](http://www.google.com/hostednews/afp/article/ALeqM5iCMb6pr6EYGK3d57io_C8yfpIG2g?docId=CNG.faa7076ee940283688916c2ee187655c.01) – David Schwartz Dec 18 '11 at 06:24
  • I'm looking at this as a risk management issue - the chance of compromising a private key and either completely breaching the database or getting hold of a backup is lower than each individually. (The backups are encrypted with a separate key anyway, giving a second layer of encryption) – Mikey Top Dec 18 '11 at 06:33
  • 1
    I agree. Therefore, you don't need to re-encrypt the data. If an attacker can't get both the key and the encrypted data, your safe whether or not you re-encrypt. If an attacker can get both the key and the encrypted data, you're screwed whether or not you re-encrypt. – David Schwartz Dec 18 '11 at 06:40
  • If a private key was compromised and there was no response, they would have unlimited time to work out how to breach the database. With my setup, both would have to be breached simultaneously. – Mikey Top Dec 18 '11 at 06:54
  • They wouldn't have to be breached simultaneously at all. They could breach the database and then get the key weeks, months, or years later. Unless you can rely on the encrypted data never leaking out (in which case, why re-encrypt?) you have to protect the keys for as long as any data they ever encrypted needs to be protected. Re-encrypting just increases your exposure, as there are now *two* keys that you have to protect to protect that same data whereas before there was one. (In other words, unless you have reason to believe a key was compromised, re-encrypting is a bad idea.) – David Schwartz Dec 18 '11 at 07:17
  • For that matter, if you could rely on the encrypted data never leaking out, why encrypt at all? If someone doesn't have the data, it doesn't matter that they have the key. @DavidSchwartz is right, if there's suspicion of EITHER the key or the data leaking, both have to be changed, along with determining how they leaked and plugging the hole so it doesn't happen again. – wadesworld Dec 18 '11 at 07:35
  • "They could breach the database and then get the key weeks, months, or years later" If we detect a breach, we delete all live copies of the private key immediately. If a key gets compromised, we reencrypt the whole database immediately. It's about relative risk. – Mikey Top Dec 18 '11 at 10:58
  • @MikeyTop Right, *if* a key gets compromised. But we weren't talking about emergency response, we were talking about changing a key. When a key merely expires or is replaced, re-encrypting is a bad idea. Now there are *two* keys that could compromise the data, before there was only one. – David Schwartz Dec 19 '11 at 07:18
  • Just stumbled across my old post again and thought I'd add a bit more for the search engine. Apparently this is known as "homomorphic re-encryption" and is an active area of research. From my limited reading, there are no viable implementations at this point in time. – Mikey Top May 05 '12 at 02:23
0

Think about your security perimeters. If you're worried about the server being compromised, consider building a harder-to-break subsystem which carried out the transcryption. You could do this with a non-network-attached server which was contacted only over a very tightly verified link protocol (over, say, a serial line), or a dedicated hardware security module. However, if you do something like this, you must think about how your keys are protected; if an attacker could steal the transient plaintext from your server, could they also steal the keys protecting it?

crazyscot
  • 11,819
  • 2
  • 39
  • 40