Vulnerability with compromised geli credentials?

[Eygene Ryabinkin]

Abiron, good day.

Sat, May 17, 2008 at 05:41:13PM -0700, Abiron Arroyo wrote:
> I'm not really a developer, but was considering if there is a key
> vulnerability in geli given that when you change a key there isn't a disk
> update.
> 
> Consider the scenario where a new file system is created and populated
> with some files. At a later time the original key is changed because
> someone has gained access to the key and passphrase. A new key is
> generated and attached, but none of the files are modified.

There were a simular thread at SecurityFocus, related to the
PGP disk encryption products:
  http://www.securityfocus.com/archive/1/435007/30/0/threaded

> Furthermore, let's say the thief has access to the system and is able to
> update the disk to use the previous key and then reattach/mount. Is it
> then possible for the person that has the stolen credentials to mount the
> drive and view the files?

If you possess the Master Key that actually used for the encryption,
then yes.  The passphrase you're entering to attach geli volume is
just used to encrypt that master key on the disk.

> The man page does not detail how the metadata is written.

Probably the manual should be updated to say something about
the process of encryption and some neats about it.

> With that said, if this is possible, what's the best way to update the
> system? I suspect that moving the file is not enough, using vi in a script
> is not very practical, and using cat may cause problems with some special
> characters.

The best way is to get the second, virgin geli volume with uncompromised
master key and copy data to that volume.  In theory, one can reencrypt
the data on the geli volume with the new master key, but this can be
error-prone: if process is interrupted, some part of the disk will be
encrypted with the old key and one -- with the new one.  This can be
overriden if geli will be extended to be able to handle two keys
at once: try the first one and then the second one.  So the scenario
for the reencryption with new master key is the following:
a. new master key is created, encrypted and saved in some location
   within the metadata;
b. geli starts to reencrypt the disk contents;
c. if the process is interrupted, then geli will see two keys on the
   next attachment and will be able to operate and continue the
   reencryption.
d. when reencryption completes, new master key is dropped to the regular
   place and it is wiped from the secondary location.

I thought about adding such functionality to geli some time ago, but
I had no time to implement it, so I was stuck to the second, virgin
geli volume.

I vaguely recall that pjd@ was mentioning some script or program
that was able to really reencrypt the disk, changing the master
key.  But I may be wrong.

Pawel, what do you think, will there be a place for a secondary
master key?  As I understand, the encryption is done with a non-chained
mode (counter?), so the disk that is partially encrypted with the
new and partially with the old key should not pose any problems
with the case of authenticated geli volume (we can check if decryption
was working, so we can run two passes on the block with different
passwords).  With unauthenticated geli one can put the counter of
already reencrypted block somewhere to the metadata.  Potentially,
this is not worse than the authenticated case: if power fails during
reencryption and the counter will not be updated for the recent
block(s), then it will be the same badness as for authenticated
case: blocks can be reencrypted, but the authentication data can
not be written to the disk.

Though, the complete reencryption will be very error-prone process
and can lead to data loss, so I would stick to two different disks
and/or volumes to prevent any old data overwrites before the new
data will be written and validated.
-- 
Eygene