>> I can't tell from the instructions how the FDE encryption key is stored --
>> do we manually seal it to the TPM and then manually unseal and copy/paste it
>> every time we boot? Or is it assumed the user will write a script to handle
>> this -- a script which itself will have to be measured by the TPM?
>
> This is not possible with the current version. The Masterthesis was
> about answering this Question: Did unencrypted software change since
> the last time the user operated this system.
>
> What exactly is your use case? Do you want a system with FDE that does
> not prompt you for the encryption key or do you want to improve the
> security by storing a part of the key material inside the TPM while the
> other half is provided by a user password?
>
> There are a lot of possibilities with a available TPM on boot, so if
> you have a specific use case we can tailor that right in.
>
> Before we do that i think it is important to make this feature a lot
> easier to install. Following this manual, patching and compiling source
> code and updating the MBR and biosboot is not something the user should
> have to worry about.
>
> The problem is, in order to make space for this feature in the MBR as
> well as in biosboot i had to remove the code responsible for loading a
> block from disk via CHS. This is obviously not acceptable if this should
> be integrated back into OpenBSD.
>
> One possible solution would be to let the MBR and biosboot grow bigger
> than 512 byte and let installboot(8) figure out what the user needs and
> remove code paths that are not used to get the binary back to 512 byte.
>
> Everything else i thought of involves recompiling.
