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/th
readed

> 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
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"