[tpm2] Re: How can I prevent MITM attacks for unsealing?

[tpm2] Re: How can I prevent MITM attacks for unsealing?

[Roberts, William C]

[-- Attachment #1: Type: text/plain, Size: 4137 bytes --]

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?

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(a)gmail.com<mailto:davolfman(a)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(a)lists.01.org<mailto:tpm2(a)lists.01.org>
To unsubscribe send an email to tpm2-leave(a)lists.01.org<mailto:tpm2-leave(a)lists.01.org>
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s



[https://mail.zeronsoftn.com/mthumbnail/4e645b05-f948-4090-8a7d-a1196f1fafbe.png]



[https://mail.zeronsoftn.com/mthumbnail/12cf28f0-6d3a-4e52-913d-c53ed8a8dcd7.png]

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 10591 bytes --]

[tpm2] Re: How can I prevent MITM attacks for unsealing?

[joseph]

[-- Attachment #1: Type: text/plain, Size: 756 bytes --]


Hello,
Does anyone know about this issue?
https://github.com/jc-lab/securekit/blob/466abe16bfe4f28ef86db6bc72649214ab2e4b51/pkg/securekit-disk/opt/securekit/sbin/disk-init#L82-L86
Here's one example of sealing and unsealing.
This method seems (probably?) to prevent the sniffing attack, which was a vulnerability of Bitlocker in the past.
But isn't a MITM attack possible in the process of creating an encrypted session?
I am not familiar with the process of establishing a session,
However, it seems that MITM can be prevented only by using a session key encrypted with the EK of the TPM, or by signing the asymmetric key with the EK to derive the key, when creating a session.
Is MITM not considered in TPM? Or is there another way?
Regards,

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 1096 bytes --]

[tpm2] Re: How can I prevent MITM attacks for unsealing?

[Roberts, William C]

[-- Attachment #1: Type: text/plain, Size: 2682 bytes --]

On Mon, 2022-10-03 at 18:01 +0300, joseph(a)zeronsoftn.com wrote:
> Hello,
> 
> Does anyone know about this issue?
> 
> https://github.com/jc-lab/securekit/blob/466abe16bfe4f28ef86db6bc72649214ab2e4b51/pkg/securekit-disk/opt/securekit/sbin/disk-init#L82-L86
> 
> Here's one example of sealing and unsealing.
> This method seems (probably?) to prevent the sniffing attack, which
> was a vulnerability of Bitlocker in the past.
> 
> But isn't a MITM attack possible in the process of creating an
> encrypted session?

So just to unpack the commands here for discussion I copied that code
block:

tpm2_createprimary -Q -C o -c tpm-primary.ctx
tpm2_load -Q -C tpm-primary.ctx -u ${p1_dir}/seal.pub -r
${p1_dir}/seal.priv -c tpm-seal.ctx
tpm2_startauthsession -Q --hmac-session -c tpm-primary.ctx -S
session.ctx
tpm2_unseal -Q -p pcr:${tpm_seal_pcr_policy} -c tpm-seal.ctx -o
${output}
cleanupSession

The issue here is that the key created by the tpm2_createprimary
command doesn't have provenance, so it's just be trusted implicitly
even through it could be attacker controlled. If the attacker was
controlling the primary object, they could just forward the commands
unencrypted to the TPM and get the unseal to release them the key in
the clear.

> 
> I am not familiar with the process of establishing a session,
> However, it seems that MITM can be prevented only by using a session
> key encrypted with the EK of the TPM, or by signing the asymmetric
> key with the EK to derive the key, when creating a session.

You just need a way to ensure provenance. Another way is to load an
established key to the TPM and start the authsession with that. If
you're using a persistent key you need to verify the name after
establishing the session or use something like a serialized ESYS_TR
which will do the name checking automatically. If you load a key blob
to the TPM that you control, ESAPI will have the checks in place to
make sure you don't get duped.

> 
> Is MITM not considered in TPM? Or is there another way?

It is considered in the TPM and is discussed in the architecture
document. Theirs a few ways you can securely set up an encrypted
session, either with EK and associated Certificate or through other
keys like the SRK. The big thing is, you have to do it in a way where
the attacker can not MiTM the session establishment, which boils down
to using a known key.

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

[tpm2] Re: How can I prevent MITM attacks for unsealing?

[Roberts, William C]

[-- Attachment #1: Type: text/plain, Size: 3192 bytes --]

On Mon, 2022-10-03 at 15:54 +0000, Roberts, William C wrote:
> On Mon, 2022-10-03 at 18:01 +0300, joseph(a)zeronsoftn.com wrote:
> > Hello,
> > 
> > Does anyone know about this issue?
> > 
> > https://github.com/jc-lab/securekit/blob/466abe16bfe4f28ef86db6bc72649214ab2e4b51/pkg/securekit-disk/opt/securekit/sbin/disk-init#L82-L86
> > 
> > Here's one example of sealing and unsealing.
> > This method seems (probably?) to prevent the sniffing attack, which
> > was a vulnerability of Bitlocker in the past.
> > 
> > But isn't a MITM attack possible in the process of creating an
> > encrypted session?
> 
> So just to unpack the commands here for discussion I copied that code
> block:
> 
> tpm2_createprimary -Q -C o -c tpm-primary.ctx
> tpm2_load -Q -C tpm-primary.ctx -u ${p1_dir}/seal.pub -r
> ${p1_dir}/seal.priv -c tpm-seal.ctx
> tpm2_startauthsession -Q --hmac-session -c tpm-primary.ctx -S
> session.ctx
> tpm2_unseal -Q -p pcr:${tpm_seal_pcr_policy} -c tpm-seal.ctx -o
> ${output}
> cleanupSession
> 
> The issue here is that the key created by the tpm2_createprimary
> command doesn't have provenance, so it's just be trusted implicitly
> even through it could be attacker controlled. If the attacker was
> controlling the primary object, they could just forward the commands
> unencrypted to the TPM and get the unseal to release them the key in
> the clear.
> 
> > I am not familiar with the process of establishing a session,
> > However, it seems that MITM can be prevented only by using a
> > session
> > key encrypted with the EK of the TPM, or by signing the asymmetric
> > key with the EK to derive the key, when creating a session.
> 
> You just need a way to ensure provenance. Another way is to load an
> established key to the TPM and start the authsession with that. If
> you're using a persistent key you need to verify the name after
> establishing the session or use something like a serialized ESYS_TR
> which will do the name checking automatically. If you load a key blob
> to the TPM that you control, ESAPI will have the checks in place to
> make sure you don't get duped.
> 
> > Is MITM not considered in TPM? Or is there another way?
> 
> It is considered in the TPM and is discussed in the architecture
> document. Theirs a few ways you can securely set up an encrypted
> session, either with EK and associated Certificate or through other
> keys like the SRK. The big thing is, you have to do it in a way where
> the attacker can not MiTM the session establishment, which boils down
> to using a known key.

Actually the seem to be aware of this in their README:
https://github.com/jc-lab/securekit#do-not-use-yet

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

[tpm2] Re: How can I prevent MITM attacks for unsealing?

[joseph]

[-- Attachment #1: Type: text/plain, Size: 368 bytes --]

Here is the command I tested:
https://gist.github.com/jclab-joseph/d1d6d9bbbd32c0fe200cc7725bcf0d86
A session was established via a serialized persistent handle.
This seems to be able to prevent MITM by default.

But wouldn't it still be vulnerable if an attacker could replace primary.handle?
Is there a way to validate between session and seal.ctx or seal.pub?

[tpm2] Re: How can I prevent MITM attacks for unsealing?

[joseph]

[-- Attachment #1: Type: text/plain, Size: 3393 bytes --]



Here is the commands I tried:
https://gist.github.­com/jclab-joseph/d1d­6d9bbbd32c0fe200cc77­25bcf0d86
A session was estab­lished via a seriali­zed persistent handl­e.
This seems to be ab­le to prevent MITM in the session connection process.
But, assume that an attacker can modify the filesystem.
If the primary.handle can be replaced with the attacker's key, the session will be successfully established.
And I suspect that plaintext can be exposed if unsealed through the session.
Wouldn't validation be needed between the connected session and seal.ctx? 화요일, 04 10월 2022, 00:54오전 +09:00 발신 "Roberts, William C"  william.c.roberts(a)intel.com :

>On Mon, 2022-10-03 at 18:01 +0300,  joseph(a)zeronsoftn.com wrote:
> Hello,
>
> Does anyone know about this issue?
>
> https://github.com/jc-lab/securekit/blob/466abe16bfe4f28ef86db6bc72649214ab2e4b51/pkg/securekit-disk/opt/securekit/sbin/disk-init#L82-L86
>
> Here's one example of sealing and unsealing.
> This method seems (probably?) to prevent the sniffing attack, which
> was a vulnerability of Bitlocker in the past.
>
> But isn't a MITM attack possible in the process of creating an
> encrypted session?
>So just to unpack the commands here for discussion I copied that code
>block:
>
>tpm2_createprimary -Q -C o -c tpm-primary.ctx
>tpm2_load -Q -C tpm-primary.ctx -u ${p1_dir}/seal.pub -r
>${p1_dir}/seal.priv -c tpm-seal.ctx
>tpm2_startauthsession -Q --hmac-session -c tpm-primary.ctx -S
>session.ctx
>tpm2_unseal -Q -p pcr:${tpm_seal_pcr_policy} -c tpm-seal.ctx -o
>${output}
>cleanupSession
>
>The issue here is that the key created by the tpm2_createprimary
>command doesn't have provenance, so it's just be trusted implicitly
>even through it could be attacker controlled. If the attacker was
>controlling the primary object, they could just forward the commands
>unencrypted to the TPM and get the unseal to release them the key in
>the clear.
>
>
> I am not familiar with the process of establishing a session,
> However, it seems that MITM can be prevented only by using a session
> key encrypted with the EK of the TPM, or by signing the asymmetric
> key with the EK to derive the key, when creating a session.
>
>You just need a way to ensure provenance. Another way is to load an
>established key to the TPM and start the authsession with that. If
>you're using a persistent key you need to verify the name after
>establishing the session or use something like a serialized ESYS_TR
>which will do the name checking automatically. If you load a key blob
>to the TPM that you control, ESAPI will have the checks in place to
>make sure you don't get duped.
>
>
> Is MITM not considered in TPM? Or is there another way?
>
>It is considered in the TPM and is discussed in the architecture
>document. Theirs a few ways you can securely set up an encrypted
>session, either with EK and associated Certificate or through other
>keys like the SRK. The big thing is, you have to do it in a way where
>the attacker can not MiTM the session establishment, which boils down
>to using a known key.
>
>
> Regards,
>
>
>
>
>
> _______________________________________________
> tpm2 mailing list --  tpm2(a)lists.01.org
> To unsubscribe send an email to  tpm2-leave(a)lists.01.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 4751 bytes --]

[tpm2] Re: How can I prevent MITM attacks for unsealing?

[Roberts, William C]

[-- Attachment #1: Type: text/plain, Size: 1504 bytes --]

On Thu, 2022-10-06 at 13:07 +0000, joseph(a)zeronsoftn.com wrote:
> Here is the command I tested:
> https://gist.github.com/jclab-joseph/d1d6d9bbbd32c0fe200cc7725bcf0d86
> A session was established via a serialized persistent handle.
> This seems to be able to prevent MITM by default.
> 
> But wouldn't it still be vulnerable if an attacker could replace
> primary.handle?

You can think of this as the same attack as replacing your root CA
certs for your browser. If an attacker can modify or add a Root CA they
can get you to trust them (the attacker). Same here, if the metadata
your validating against changes, ie the public key, then you lost.

> Is there a way to validate between session and seal.ctx or seal.pub?

The key blobs themselves are tamper resistant using an HMAC for
integrity and AES128CFB for confidentiality. 

Assuming you seal and unseal with a session started with a trusted key,
then you're good. An attacker can only observer the traffic but cannot
modify or extract the data on the bus if encrypted sessions are used.

You could also use or add a bind key to the session where the objects
password is used in the generation of the session key. This bind key
could be the password used on the seal key if the seal key has a
password.

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

[tpm2] Re: How can I prevent MITM attacks for unsealing?

[Roberts, William C]

[-- Attachment #1: Type: text/plain, Size: 4087 bytes --]

On Mon, 2022-10-10 at 18:07 +0300, joseph(a)zeronsoftn.com wrote:
> 
> Here is the commands I tried:
> https://gist.github.­com/jclab-joseph/d1d­6d9bbbd32c0fe200cc77­25bcf0d86
> A session was estab­lished via a seriali­zed persistent handl­e.
> This seems to be ab­le to prevent MITM in the session connection
> process.
> 
> But, assume that an attacker can modify the filesystem.
> If the primary.handle can be replaced with the attacker's key, the
> session will be successfully established.
> And I suspect that plaintext can be exposed if unsealed through the
> session.
> 
> Wouldn't validation be needed between the connected session and
> seal.ctx?

If the attacker can modify the primary.handle, which is verifying the
encrypted session, then yes you need something else. You could add a
bind key with a password and have the user enter the password and thus
nothing for the attacker to attack that is stored on disk.

> 
> 화요일, 04 10월 2022, 00:54오전 +09:00 발신 "Roberts, William C" 
> william.c.roberts(a)intel.com:
> 
> > On Mon, 2022-10-03 at 18:01 +0300, joseph(a)zeronsoftn.com wrote:
> > > Hello,
> > > 
> > > Does anyone know about this issue?
> > > 
> > > 
> > https://github.com/jc-lab/securekit/blob/466abe16bfe4f28ef86db6bc72649214ab2e4b51/pkg/securekit-disk/opt/securekit/sbin/disk-init#L82-L86
> > > 
> > > Here's one example of sealing and unsealing.
> > > This method seems (probably?) to prevent the sniffing attack,
> > which
> > > was a vulnerability of Bitlocker in the past.
> > > 
> > > But isn't a MITM attack possible in the process of creating an
> > > encrypted session?
> > So just to unpack the commands here for discussion I copied that
> > code
> > block:
> > 
> > tpm2_createprimary -Q -C o -c tpm-primary.ctx
> > tpm2_load -Q -C tpm-primary.ctx -u ${p1_dir}/seal.pub -r
> > ${p1_dir}/seal.priv -c tpm-seal.ctx
> > tpm2_startauthsession -Q --hmac-session -c tpm-primary.ctx -S
> > session.ctx
> > tpm2_unseal -Q -p pcr:${tpm_seal_pcr_policy} -c tpm-seal.ctx -o
> > ${output}
> > cleanupSession
> > 
> > The issue here is that the key created by the tpm2_createprimary
> > command doesn't have provenance, so it's just be trusted implicitly
> > even through it could be attacker controlled. If the attacker was
> > controlling the primary object, they could just forward the
> > commands
> > unencrypted to the TPM and get the unseal to release them the key
> > in
> > the clear.
> > 
> > > 
> > > I am not familiar with the process of establishing a session,
> > > However, it seems that MITM can be prevented only by using a
> > session
> > > key encrypted with the EK of the TPM, or by signing the
> > asymmetric
> > > key with the EK to derive the key, when creating a session.
> > 
> > You just need a way to ensure provenance. Another way is to load an
> > established key to the TPM and start the authsession with that. If
> > you're using a persistent key you need to verify the name after
> > establishing the session or use something like a serialized ESYS_TR
> > which will do the name checking automatically. If you load a key
> > blob
> > to the TPM that you control, ESAPI will have the checks in place to
> > make sure you don't get duped.
> > 
> > > 
> > > Is MITM not considered in TPM? Or is there another way?
> > 
> > It is considered in the TPM and is discussed in the architecture
> > document. Theirs a few ways you can securely set up an encrypted
> > session, either with EK and associated Certificate or through other
> > keys like the SRK. The big thing is, you have to do it in a way
> > where
> > the attacker can not MiTM the session establishment, which boils
> > down
> > to using a known key.
> > 
> > > 
> > > Regards,
> > > 
> > > 
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > tpm2 mailing list -- tpm2(a)lists.01.org
> > > To unsubscribe send an email to tpm2-leave(a)lists.01.org
> > > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> 
> 
> 

[tpm2] Re: How can I prevent MITM attacks for unsealing?

[joseph]

[-- Attachment #1: Type: text/plain, Size: 4394 bytes --]


Serialized primary.handle has a Public Key.
Is there a way to verify whether this public key is a key created by the TPM through the TPM's EK?
If this is possible, it will not be possible to protect against MITM in general, but if you have the CA of specific TPM manufacturers safely or remotely verify it, can be defend against MITM. 토요일, 22 10월 2022, 02:43오전 +09:00 발신 "Roberts, William C"  william.c.roberts(a)intel.com :

>On Mon, 2022-10-10 at 18:07 +0300,  joseph(a)zeronsoftn.com wrote:
>
> Here is the commands I tried:
> https://gist.github.com/jclab-joseph/d1d6d9bbbd32c0fe200cc7725bcf0d86
> A session was established via a serialized persistent handle.
> This seems to be able to prevent MITM in the session connection
> process.
>
> But, assume that an attacker can modify the filesystem.
> If the primary.handle can be replaced with the attacker's key, the
> session will be successfully established.
> And I suspect that plaintext can be exposed if unsealed through the
> session.
>
> Wouldn't validation be needed between the connected session and
> seal.ctx?
>If the attacker can modify the primary.handle, which is verifying the
>encrypted session, then yes you need something else. You could add a
>bind key with a password and have the user enter the password and thus
>nothing for the attacker to attack that is stored on disk.
>
>
> 화요일, 04 10월 2022, 00:54오전 +09:00 발신 "Roberts, William C" 
> william.c.roberts(a)intel.com:
>
>> On Mon, 2022-10-03 at 18:01 +0300,  joseph(a)zeronsoftn.com wrote:
>>> Hello,
>>>
>>> Does anyone know about this issue?
>>>
>>>
>> https://github.com/jc-lab/securekit/blob/466abe16bfe4f28ef86db6bc72649214ab2e4b51/pkg/securekit-disk/opt/securekit/sbin/disk-init#L82-L86
>>>
>>> Here's one example of sealing and unsealing.
>>> This method seems (probably?) to prevent the sniffing attack,
>> which
>>> was a vulnerability of Bitlocker in the past.
>>>
>>> But isn't a MITM attack possible in the process of creating an
>>> encrypted session?
>> So just to unpack the commands here for discussion I copied that
>> code
>> block:
>>
>> tpm2_createprimary -Q -C o -c tpm-primary.ctx
>> tpm2_load -Q -C tpm-primary.ctx -u ${p1_dir}/seal.pub -r
>> ${p1_dir}/seal.priv -c tpm-seal.ctx
>> tpm2_startauthsession -Q --hmac-session -c tpm-primary.ctx -S
>> session.ctx
>> tpm2_unseal -Q -p pcr:${tpm_seal_pcr_policy} -c tpm-seal.ctx -o
>> ${output}
>> cleanupSession
>>
>> The issue here is that the key created by the tpm2_createprimary
>> command doesn't have provenance, so it's just be trusted implicitly
>> even through it could be attacker controlled. If the attacker was
>> controlling the primary object, they could just forward the
>> commands
>> unencrypted to the TPM and get the unseal to release them the key
>> in
>> the clear.
>>
>>>
>>> I am not familiar with the process of establishing a session,
>>> However, it seems that MITM can be prevented only by using a
>> session
>>> key encrypted with the EK of the TPM, or by signing the
>> asymmetric
>>> key with the EK to derive the key, when creating a session.
>>
>> You just need a way to ensure provenance. Another way is to load an
>> established key to the TPM and start the authsession with that. If
>> you're using a persistent key you need to verify the name after
>> establishing the session or use something like a serialized ESYS_TR
>> which will do the name checking automatically. If you load a key
>> blob
>> to the TPM that you control, ESAPI will have the checks in place to
>> make sure you don't get duped.
>>
>>>
>>> Is MITM not considered in TPM? Or is there another way?
>>
>> It is considered in the TPM and is discussed in the architecture
>> document. Theirs a few ways you can securely set up an encrypted
>> session, either with EK and associated Certificate or through other
>> keys like the SRK. The big thing is, you have to do it in a way
>> where
>> the attacker can not MiTM the session establishment, which boils
>> down
>> to using a known key.
>>
>>>
>>> Regards,
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> tpm2 mailing list --  tpm2(a)lists.01.org
>>> To unsubscribe send an email to  tpm2-leave(a)lists.01.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
>

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 6655 bytes --]

[tpm2] Re: How can I prevent MITM attacks for unsealing?

[Roberts, William C]

[-- Attachment #1: Type: text/plain, Size: 5165 bytes --]

The TPM2_Cerify command can certify that another key is the TPM based on a key you trust, like the EK.

Bill
________________________________
From: joseph(a)zeronsoftn.com <joseph(a)zeronsoftn.com>
Sent: Friday, October 21, 2022 11:23 PM
To: Roberts, William C <william.c.roberts(a)intel.com>
Cc: tpm2(a)lists.01.org <tpm2(a)lists.01.org>
Subject: Re[5]: [tpm2] How can I prevent MITM attacks for unsealing?


Serialized primary.handle has a Public Key.
Is there a way to verify whether this public key is a key created by the TPM through the TPM's EK?

If this is possible, it will not be possible to protect against MITM in general, but if you have the CA of specific TPM manufacturers safely or remotely verify it, can be defend against MITM.

토요일, 22 10월 2022, 02:43오전 +09:00 발신 "Roberts, William C" william.c.roberts(a)intel.com<mailto:william.c.roberts(a)intel.com>:

On Mon, 2022-10-10 at 18:07 +0300, joseph(a)zeronsoftn.com<mailto:joseph(a)zeronsoftn.com> wrote:
>
> Here is the commands I tried:
> https://gist.github.com/jclab-joseph/d1d6d9bbbd32c0fe200cc7725bcf0d86
> A session was established via a serialized persistent handle.
> This seems to be able to prevent MITM in the session connection
> process.
>
> But, assume that an attacker can modify the filesystem.
> If the primary.handle can be replaced with the attacker's key, the
> session will be successfully established.
> And I suspect that plaintext can be exposed if unsealed through the
> session.
>
> Wouldn't validation be needed between the connected session and
> seal.ctx?
If the attacker can modify the primary.handle, which is verifying the
encrypted session, then yes you need something else. You could add a
bind key with a password and have the user enter the password and thus
nothing for the attacker to attack that is stored on disk.

>
> 화요일, 04 10월 2022, 00:54오전 +09:00 발신 "Roberts, William C"
> william.c.roberts(a)intel.com:
>
> > On Mon, 2022-10-03 at 18:01 +0300, joseph(a)zeronsoftn.com<mailto:joseph(a)zeronsoftn.com> wrote:
> > > Hello,
> > >
> > > Does anyone know about this issue?
> > >
> > >
> > https://github.com/jc-lab/securekit/blob/466abe16bfe4f28ef86db6bc72649214ab2e4b51/pkg/securekit-disk/opt/securekit/sbin/disk-init#L82-L86
> > >
> > > Here's one example of sealing and unsealing.
> > > This method seems (probably?) to prevent the sniffing attack,
> > which
> > > was a vulnerability of Bitlocker in the past.
> > >
> > > But isn't a MITM attack possible in the process of creating an
> > > encrypted session?
> > So just to unpack the commands here for discussion I copied that
> > code
> > block:
> >
> > tpm2_createprimary -Q -C o -c tpm-primary.ctx
> > tpm2_load -Q -C tpm-primary.ctx -u ${p1_dir}/seal.pub -r
> > ${p1_dir}/seal.priv -c tpm-seal.ctx
> > tpm2_startauthsession -Q --hmac-session -c tpm-primary.ctx -S
> > session.ctx
> > tpm2_unseal -Q -p pcr:${tpm_seal_pcr_policy} -c tpm-seal.ctx -o
> > ${output}
> > cleanupSession
> >
> > The issue here is that the key created by the tpm2_createprimary
> > command doesn't have provenance, so it's just be trusted implicitly
> > even through it could be attacker controlled. If the attacker was
> > controlling the primary object, they could just forward the
> > commands
> > unencrypted to the TPM and get the unseal to release them the key
> > in
> > the clear.
> >
> > >
> > > I am not familiar with the process of establishing a session,
> > > However, it seems that MITM can be prevented only by using a
> > session
> > > key encrypted with the EK of the TPM, or by signing the
> > asymmetric
> > > key with the EK to derive the key, when creating a session.
> >
> > You just need a way to ensure provenance. Another way is to load an
> > established key to the TPM and start the authsession with that. If
> > you're using a persistent key you need to verify the name after
> > establishing the session or use something like a serialized ESYS_TR
> > which will do the name checking automatically. If you load a key
> > blob
> > to the TPM that you control, ESAPI will have the checks in place to
> > make sure you don't get duped.
> >
> > >
> > > Is MITM not considered in TPM? Or is there another way?
> >
> > It is considered in the TPM and is discussed in the architecture
> > document. Theirs a few ways you can securely set up an encrypted
> > session, either with EK and associated Certificate or through other
> > keys like the SRK. The big thing is, you have to do it in a way
> > where
> > the attacker can not MiTM the session establishment, which boils
> > down
> > to using a known key.
> >
> > >
> > > Regards,
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > tpm2 mailing list -- tpm2(a)lists.01.org<mailto:tpm2(a)lists.01.org>
> > > To unsubscribe send an email to tpm2-leave(a)lists.01.org<mailto:tpm2-leave(a)lists.01.org>
> > > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
>



[https://mail.zeronsoftn.com/mthumbnail/7b26b6d8-279b-4527-bfcd-9c3fb591e46c.png]

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 7916 bytes --]

[tpm2] Re: How can I prevent MITM attacks for unsealing?

[Roberts, William C]

[-- Attachment #1: Type: text/plain, Size: 6098 bytes --]

On Mon, 2022-10-24 at 17:32 +0000, Roberts, William C wrote:
> The TPM2_Cerify command can certify that another key is the TPM based
> on a key you trust, like the EK.

But bear in mind that again your verifying to something so the threat
is always the attacker changes to what your verifying to. If your
verification data is as tamper-able as your store you didn't gain
anything. If your verification data is on some RO partition that is
checked for tampering, then that would be better.

> 
> Bill
> From: joseph(a)zeronsoftn.com <joseph(a)zeronsoftn.com>
> Sent: Friday, October 21, 2022 11:23 PM
> To: Roberts, William C <william.c.roberts(a)intel.com>
> Cc: tpm2(a)lists.01.org <tpm2(a)lists.01.org>
> Subject: Re[5]: [tpm2] How can I prevent MITM attacks for unsealing?
>  
> Serialized primary.handle has a Public Key.
> Is there a way to verify whether this public key is a key created by
> the TPM through the TPM's EK?
> If this is possible, it will not be possible to protect against MITM
> in general, but if you have the CA of specific TPM manufacturers
> safely or remotely verify it, can be defend against MITM.
> 토요일, 22 10월 2022, 02:43오전 +09:00 발신 "Roberts, William C" 
> william.c.roberts(a)intel.com:
> 
> > On Mon, 2022-10-10 at 18:07 +0300, joseph(a)zeronsoftn.com wrote:
> > > 
> > > Here is the commands I tried:
> > > 
> > https://gist.github.com/jclab-joseph/d1d6d9bbbd32c0fe200cc7725bcf0d86
> > > A session was established via a serialized persistent handle.
> > > This seems to be able to prevent MITM in the session connection
> > > process.
> > > 
> > > But, assume that an attacker can modify the filesystem.
> > > If the primary.handle can be replaced with the attacker's key,
> > the
> > > session will be successfully established.
> > > And I suspect that plaintext can be exposed if unsealed through
> > the
> > > session.
> > > 
> > > Wouldn't validation be needed between the connected session and
> > > seal.ctx?
> > If the attacker can modify the primary.handle, which is verifying
> > the
> > encrypted session, then yes you need something else. You could add
> > a
> > bind key with a password and have the user enter the password and
> > thus
> > nothing for the attacker to attack that is stored on disk.
> > 
> > > 
> > > 화요일, 04 10월 2022, 00:54오전 +09:00 발신 "Roberts, William C" 
> > > william.c.roberts(a)intel.com:
> > > 
> > > > On Mon, 2022-10-03 at 18:01 +0300, joseph(a)zeronsoftn.com wrote:
> > > > > Hello,
> > > > > 
> > > > > Does anyone know about this issue?
> > > > > 
> > > > > 
> > > > 
> > https://github.com/jc-lab/securekit/blob/466abe16bfe4f28ef86db6bc72649214ab2e4b51/pkg/securekit-disk/opt/securekit/sbin/disk-init#L82-L86
> > > > > 
> > > > > Here's one example of sealing and unsealing.
> > > > > This method seems (probably?) to prevent the sniffing attack,
> > > > which
> > > > > was a vulnerability of Bitlocker in the past.
> > > > > 
> > > > > But isn't a MITM attack possible in the process of creating
> > an
> > > > > encrypted session?
> > > > So just to unpack the commands here for discussion I copied
> > that
> > > > code
> > > > block:
> > > > 
> > > > tpm2_createprimary -Q -C o -c tpm-primary.ctx
> > > > tpm2_load -Q -C tpm-primary.ctx -u ${p1_dir}/seal.pub -r
> > > > ${p1_dir}/seal.priv -c tpm-seal.ctx
> > > > tpm2_startauthsession -Q --hmac-session -c tpm-primary.ctx -S
> > > > session.ctx
> > > > tpm2_unseal -Q -p pcr:${tpm_seal_pcr_policy} -c tpm-seal.ctx -o
> > > > ${output}
> > > > cleanupSession
> > > > 
> > > > The issue here is that the key created by the
> > tpm2_createprimary
> > > > command doesn't have provenance, so it's just be trusted
> > implicitly
> > > > even through it could be attacker controlled. If the attacker
> > was
> > > > controlling the primary object, they could just forward the
> > > > commands
> > > > unencrypted to the TPM and get the unseal to release them the
> > key
> > > > in
> > > > the clear.
> > > > 
> > > > > 
> > > > > I am not familiar with the process of establishing a session,
> > > > > However, it seems that MITM can be prevented only by using a
> > > > session
> > > > > key encrypted with the EK of the TPM, or by signing the
> > > > asymmetric
> > > > > key with the EK to derive the key, when creating a session.
> > > > 
> > > > You just need a way to ensure provenance. Another way is to
> > load an
> > > > established key to the TPM and start the authsession with that.
> > If
> > > > you're using a persistent key you need to verify the name after
> > > > establishing the session or use something like a serialized
> > ESYS_TR
> > > > which will do the name checking automatically. If you load a
> > key
> > > > blob
> > > > to the TPM that you control, ESAPI will have the checks in
> > place to
> > > > make sure you don't get duped.
> > > > 
> > > > > 
> > > > > Is MITM not considered in TPM? Or is there another way?
> > > > 
> > > > It is considered in the TPM and is discussed in the
> > architecture
> > > > document. Theirs a few ways you can securely set up an
> > encrypted
> > > > session, either with EK and associated Certificate or through
> > other
> > > > keys like the SRK. The big thing is, you have to do it in a way
> > > > where
> > > > the attacker can not MiTM the session establishment, which
> > boils
> > > > down
> > > > to using a known key.
> > > > 
> > > > > 
> > > > > Regards,
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > tpm2 mailing list -- tpm2(a)lists.01.org
> > > > > To unsubscribe send an email to tpm2-leave(a)lists.01.org
> > > > > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> > > 
> > > 
> > > 
> 
> 
> 
> 
> _______________________________________________
> tpm2 mailing list -- tpm2(a)lists.01.org
> To unsubscribe send an email to tpm2-leave(a)lists.01.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s