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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Genode users mailing list [email protected] https://lists.genode.org/listinfo/users
