CBE key encryption

[Martin Stein]

Hi Stefan,

I opened an issue that already contains a fix:

https://github.com/genodelabs/genode/issues/4355

However, the fix is tested yet against 'run/cbe_tester' only. The
problems with the other tests seem to be not related to this fix.
Therefore, I'd say you could give it a try. I would be interested in
your findings ;)

Cheers,
Martin

On 30.11.21 22:59, Martin Stein wrote:
> Hi Stefan,
> 
> Sorry for the delayed response.
> 
> First of all I hope you don't mind me asking whether you use the newest
> state of the CBE (Genode version 21.11 is safe)? It might be important
> because during the recent development of the File Vault, there were
> several major improvements regarding the key management with CBE/TA.
> 
> Also, I'd like to be sure that we're not talking about different keys.
> There are normally two keys in use with the CBE, the "master" or
> "private" key that is stored (encrypted via a user passphrase) in the
> Trust Anchor and the block encryption key that is stored (encrypted via
> the master key) in the CBE superblock and that the CBE driver (vfs_cbe)
> decrypts in order to use it for accessing the block device. The master
> key is currently set only during initialization of the Trust Anchor
> while the block encryption key is set during the initialization of the
> CBE but can be changed later.
> 
> Let me provide some further background although you might already be
> aware of all this. On CBE driver startup, the driver reads out the
> encrypted block encryption key from the most recent superblock on the
> block device. It then asks the Trust Anchor to decrypt it using the
> master key. The Trust Anchor returns the plaintext block encryption key
> to the driver which is then able to decrypt the data blocks of the CBE.
> 
> In the course of certain user requests, the driver writes back updated
> Superblocks to the block device. When doing so it asks the Trust Anchor
> to encrypt the block encryption key again (the key might have changed in
> the meantime). At this point may reside a flaw in the driver
> implementation that we didn't notice so far because our software TA
> surely is not as strict as your hardware: A superblock has slots for
> storing not only one but two block encryption keys. The second slot is
> used as "buffer" for an old key while transitioning from one block
> encryption key to another. Therefore the second slot is only valid while
> changing the block encryption key.
> 
> Now, when writing back the superblock, the driver seems not to care and
> always encrypts both slots even if the second one is not in use. I'll
> prepare a fix but I don't have much time currently and so I don't know
> when it'll be ready. If you want to do it yourself, lookout for
> 
> ! Job.State := Encrypt_Previous_Key_Pending;
> 
> in genode/contrib/cbe-*/cbe/src/lib/cbe/cbe-superblock_control.adb .
> This state is entered unconditionally but it should be entered only if
> 'SB.State /= Rekeying'. Otherwise it should be skipped in favor of the
> state that is set in the next
> 
> ! when Encrypt_Previous_Key_Completed =>
> 
> block.
> 
> I hope this helped?
> Please don't hesitate to ask me further questions but be aware that it
> may take me some time to answer.
> 
> Cheers
> Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.genode.org/pipermail/users/attachments/20211219/432b5641/attachment.sig>