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(a)zeronsoftn.com>
Sent: Tuesday, August 3, 2021 9:02 AM
To: tpm2(a)lists.01.org <tpm2(a)lists.01.org>
Subject: [tpm2] How can I prevent MITM attacks for unsealing?
From the previous messages, I learned how salted sessions exchange keys and are
However, I have yet to get an idea to prevent MITM attacks.
I was able to get an salted session in the following way.
tpm2_startauthsession -S session.ctx
tpm2_policypcr -Q -S session.ctx -l sha256:0,2,4 -L pcrs.sha256.policy
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_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
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,
------ Previous Message ------
"Steven Clark" <email@example.com<mailto:firstname.lastname@example.org>>
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
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 -- email@example.com<mailto:firstname.lastname@example.org>
To unsubscribe send an email to