Imran can you comment on the state this is in?

If you want a session that encrypts and decrypts, when starting the session you need to supply the option `--key-context`.
you'll need to verify independently that the context points to a key you know and trust, you can just do a sign/verify. We need
to add a name/public parameter to the input so we can perform this verification for users in the tool. I think theirs an open bug
somewhere for this. If you use persistent keys, you can get the "serialized handle", which under the hood is the ESYS_TR blob and
use that for "--key-context" and it will verify the name. You can obtain the ESYS_TR with read public command. You'll still want to
do something to ensure that no-one has swapped out your key until you get through the startauthsession. At that point it's not swappable
without detection (crypto would fail).

From there, you need to add that session to the -S parameter for all commands that you want encryption for. I am not 100% sure of where
that feature state is now, I haven't looked in a while, but Imran might know more.


From: Joseph Lee (ZeronsoftN) <joseph@zeronsoftn.com>
Sent: Tuesday, August 3, 2021 9:02 AM
To: tpm2@lists.01.org <tpm2@lists.01.org>
Subject: [tpm2] How can I prevent MITM attacks for unsealing?
 
Hi,

From the previous messages, I learned how salted sessions exchange keys and are encrypted.

However, I have yet to get an idea to prevent MITM attacks.

I was able to get an salted session in the following way.

Sealing:
> tpm2_startauthsession -S session.ctx
> tpm2_policypcr -Q -S session.ctx -l sha256:0,2,4 -L pcrs.sha256.policy
> tpm2_flushcontext session.ctx
> tpm2_createprimary -C o -c tpm-primary.ctx
> tpm2_startauthsession --hmac-session -c tpm-primary.ctx -S session.ctx
> tpm2_create -g sha256 -u seal.pub -r seal.priv -i INPUT_KEY -C tpm-primary.ctx -S session.ctx -L pcrs.sha256.policy
> tpm2_load -C tpm-primary.ctx -u seal.pub -r seal.priv -n seal.name -c tpm-seal.ctx
> tpm2_evictcontrol -C o -c tpm-seal.ctx 0x81000002
> tpm2_flushcontext session.ctx

Unsealing:
> tpm2_startauthsession --policy-session -S session.ctx
> tpm2_policypcr -S session.ctx -l sha256:0,2,4
> tpm2_unseal -p session:session.ctx -c 0x81000002 -o OUTPUT_KEY
> tpm2_flushcontext session.ctx

However, in my opinion, from the tpm2_startauthsession part of the unsealing process, an MITM attack is performed to establish a session between the attacker-PC and the TPM-attacker session is established so that the attacker will be able to obtain plaintext data for subsequent unsealing.


Thanks & Regards,
Joseph.

------ Previous Message ------

"Steven Clark" <davolfman@gmail.com> wrote on 08/02/2021 01:26:56 PM:

> I think it may be an optional standard but my TPM has some certs
> permanently stored in nv-indices in the 0x1c0000x range that can be
> checked against the manufacturer cert.  I haven't learned how to
> leverage those into trusted parameter encryption keys yet but they
> should be able to verify there's a real TPM at the other end at the
> very least (and more if you learn to use them correctly).


The EK certificates in NV are in theory optional, but every TPM

I have encountered has them.

Checking the certificate against the manufacturer's CA is
a standard crypto library function.

Once you have an authentic EK, create a salted session using
the EK.

Once you have the salted session, set the encrypt and/or decrypt bit
when running the command.

Underneath, there's some complicated crypto, but it's all
hidden from the application.

_______________________________________________
tpm2 mailing list -- tpm2@lists.01.org
To unsubscribe send an email to tpm2-leave@lists.01.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s