CBE key encryption

[Martin Stein]

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

On 23.11.21 11:21, Stefan Thöni wrote:
> Hello Genodians,
> 
> we are still working to add hardware-based encryption to CBE. To this
> end, we have implemented a custom trust anchor and crypto engine.
> Generating a key, encrypting this key on behalf of cbe_init and
> decrypting it again on behalf of the vfs_cbe plugin works fine.
> 
> But then the vfs_cbe requests to have a all zero key encrypted which due
> to the ICV added by hardware black key handling fails. We cannot seam to
> find out where the request originates or why vfs_cbe would ever encrypt
> any key, let alone a key of all zeros.
> 
> Any pointer or idea would by very welcome.
> 
> Kind regards
> Stefan
> 
> 
> _______________________________________________
> Genode users mailing list
> users at lists.genode.org
> https://lists.genode.org/listinfo/users
> 

-------------- 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/20211130/c68ed432/attachment-0001.sig>