Date: Tue, 20 May 2008 13:51:59 +0400 From: Eygene Ryabinkin <rea-fbsd@codelabs.ru> To: Abiron Arroyo <abi@e-arroyo.net> Cc: freebsd-security@freebsd.org, pjd@freebsd.org Subject: Re: Vulnerability with compromised geli credentials? Message-ID: <MKHbwZPArUbjQSPjb1bw2uaOvMI@FQFsF5nPX/dulDRBfeuxDryNM/E> In-Reply-To: <39408.75.36.168.192.1211071273.squirrel@209.51.135.2> References: <39408.75.36.168.192.1211071273.squirrel@209.51.135.2>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?MKHbwZPArUbjQSPjb1bw2uaOvMI>