On Wed, May 24, 2023 at 04:37:00PM +0000, Francesco Toscan wrote:
> Hi misc@,
>
> I'm going to migrate a FreeBSD ZFS-based fileserver to a OpenBSD 7.3 
> UFS-based one.
> In order to comply with regulations, part of data must be encrypted; 
> regulations also dictate that I have to be able to destroy the encryption 
> keys.
>
> So, I want to split data into multiple partitions, mounted read-only (it's 
> "cold" data, there's no point in mounting rw); one of them, of about 50GB, 
> will be a chunk dedicated to softraid. The volume will be assembled by hand 
> and the on-disk encryption key will be encrypted with a user supplied 
> password (right, regulations).
> If I understand correctly the 2010 paper by Marco Peereboom, he designed the 
> crypto softraid discipline so the encrypted keys would be saved in a variable 
> part of softraid medatata, stored at the beginning of the chosen chunk, after 
> an offset of 512 bytes.
> To "destroy" the keys I think it could be sufficient to use dd and overwrite 
> the first megabyte of the softraid chunk with random data.
> Am I missing something?
>
> Thanks,
> f
>
>

Yes, indeed. There is only one section of meta-data at the beginning of the
chunk and if this meta-data is lost then the decryption key is gone as well.

The password ("mask key") read from user input by 'bioctl -cC' will not be
written to disk. It will be used to encrypt the volume key which is stored
on disk.  As such, bioctl should comply with your regulations out of the box.

There is also an option to use a key disk which stores a randomly generated
mask key in unencrypted form on an arbitrary RAID disklabel partition, which
would usually sit on an external USB drive or SD card. This replaces the
passphrase with a physical object but otherwise behaves the same way.
Destroying the first 1MB of the softraid chunk would likewise render the
key disk useless.

It is not yet possible to encrypt a key disk with a passphrase, which would
provide two-factor authentication. There is no technical reason which would
prevent this from being implemented, it just hasn't been done.

Reply via email to