Encryption key storage after reinstallation and importing pools

[szeber]

Hi, I have a freenas box with 4 pools. All of the pools are encrypted. They were originally created with an installation on crappy USB stick, which I've replaced since and reinstalled the OS. The original installation was with version 11.2 R2, which got upgraded to R3 before getting replaced. I have all the encryption keys backed up, and reinstalled the same version on another set of sticks in a mirror, and imported the pools using the backed up keys, and it worked just fine.
However since then, whenever I reboot the box, the pools don't come up, they stay locked and I have to manually import the correct keys for all pools, which is a hassle and a bit error prone. I've checked what's in `/data/geli` and it was empty. I've since recreated one of the pools, and the key for that one is sitting in `/data/geli`.

My main issues with this situation:

1. It's inconvenient having to hunt down the backed up keys on every reboot and match up the correct key to the pool - though at lest i know that the backup is good...
2. When clicking the download key for one of these pools in the UI, it downloads a 0 byte geli.key file, which is horrible UX in my opinion. I've actually thought those keys were going to be the correct ones, didn't check the file size and scratched my head for a while when after the next reboot i tried to unlock the pool with those keys. This can literally cause someone who's not careful enough to overwrite their backup keys and loose all their data on the next reboot.
3. I had another issue where I tried to expand once of the pools with 2 more disks to have a stripe consisting of 3 disks (I am aware of the risks with this setup, the data stored on this volume is data that I can recover from other sources if one of the disks die). This created a new encryption key, which I backed up also, let's call this key B, while the original key A. This basically resulted in a setup, where I had a volume consisting of 2 disks, that used encryption key B, and another device that used encryption key A. After the next reboot it was a huge PITA to decrypt this pool and was completely unintuitive. I'm guessing this was made worse by key A not being stored on the box because of the above issue.

So to fix my particular issue, I think all I'd have to do is copy my backed up keys to /data/geli. However the file name for the pool that's actually auto decrypting on reboots is like `<uuid>.key`. I don't know where that uuid comes from, so I'd need some guidance on figuring out what the correct file name should be for the files. Also the UX is really bad in that instead of giving an error when downloading the key, it just downloads an empty file. I think when I import an encrypted pool, it should either save the key when i provide it, OR at least ask if it should be saved. And if the key is not available then please give an error instead of saving an empty file.

 

[ktk]

I just had a similar issue, my backup key had a certain UUID, when I did a new backup it was simply called geli.key and the md5 sums were the same for both keys. On a new install I could *not* upload the existing key via the webinterface, it always complained that it could not decrypt the disks.

So I checked on my old install how the UUID was called, uploaded the key myself into /data/geli and gave it the same UUID as the old version (I did install the new version from my old config backup). After a reboot I could unlock the key with the password I had.

But I fully agree with szeber, this is really dangerous. Why did it not work for my by uploading the key in the webinterface? I tried both the new one and the legacy one.

 

[kingc]

Hi, I have a freenas box with 4 pools. All of the pools are encrypted. They were originally created with an installation on crappy USB stick, which I've replaced since and reinstalled the OS. The original installation was with version 11.2 R2, which got upgraded to R3 before getting replaced. I have all the encryption keys backed up, and reinstalled the same version on another set of sticks in a mirror, and imported the pools using the backed up keys, and it worked just fine.
However since then, whenever I reboot the box, the pools don't come up, they stay locked and I have to manually import the correct keys for all pools, which is a hassle and a bit error prone. I've checked what's in `/data/geli` and it was empty. I've since recreated one of the pools, and the key for that one is sitting in `/data/geli`.

My main issues with this situation:

1. It's inconvenient having to hunt down the backed up keys on every reboot and match up the correct key to the pool - though at lest i know that the backup is good...
2. When clicking the download key for one of these pools in the UI, it downloads a 0 byte geli.key file, which is horrible UX in my opinion. I've actually thought those keys were going to be the correct ones, didn't check the file size and scratched my head for a while when after the next reboot i tried to unlock the pool with those keys. This can literally cause someone who's not careful enough to overwrite their backup keys and loose all their data on the next reboot.
3. I had another issue where I tried to expand once of the pools with 2 more disks to have a stripe consisting of 3 disks (I am aware of the risks with this setup, the data stored on this volume is data that I can recover from other sources if one of the disks die). This created a new encryption key, which I backed up also, let's call this key B, while the original key A. This basically resulted in a setup, where I had a volume consisting of 2 disks, that used encryption key B, and another device that used encryption key A. After the next reboot it was a huge PITA to decrypt this pool and was completely unintuitive. I'm guessing this was made worse by key A not being stored on the box because of the above issue.

So to fix my particular issue, I think all I'd have to do is copy my backed up keys to /data/geli. However the file name for the pool that's actually auto decrypting on reboots is like `<uuid>.key`. I don't know where that uuid comes from, so I'd need some guidance on figuring out what the correct file name should be for the files. Also the UX is really bad in that instead of giving an error when downloading the key, it just downloads an empty file. I think when I import an encrypted pool, it should either save the key when i provide it, OR at least ask if it should be saved. And if the key is not available then please give an error instead of saving an empty file.

I understand your frustration. The way to deal with this in FreeNAS is to unlock your pool and rekey. Then FreeNAS will know about the new key and manage it again.

I’d suggest logging a bug report about the 0 byte key download. That’s clearly wrong.

 

[szeber]

Thanks kingc, I was considering the rekey option as well, but to be honest I was afraid to do after the above key handling issues. My non striped volumes contain actually important data :).

I'll try it this evening. In my opinion though the import key dialog should warn about this behaviour and the documentation should be clear about it as well if this is not a bug.

I'll post a bug report about the 0 byte files.

 

[szeber]

I can confirm that rekey works and it solves the issues.