[TrouSerS-users] Can't lock data in specific TPMs

[Todd Griggins]

At our company, we use TPMs to protect some data in an automated fashion.
For us we don't want user entry, just need to maintain chain of trust
through the OS booting. We've used mostly dells, and on all of them
everything has worked without a hitch, however, now we needed to use a
GIGABYTE motherboard with a plug-in TPM.

The general idea is on install, we take ownership, create some data in the
NVRAM and reboot. On reboot, the PCRs are in the state we want them
(mostly) thus we read the data out of the NVRAM, delete the entries, define
new ones, keyed to PCRs and write the data back.

On reboot, the data is safely locked away, should someone boot into another
OS, the TPM shouldn't give them the data. On the Dells, if anything
changes, TPM won't give anyone data, on these IFX parts, no matter how much
I mess with the PCRs, it just gives the data to anyone. In fact, nothing I
do seems to secure the NVRAM at all! What's more is I bought another TPM
module. The TPMs have the same lettering on them (same lot?)

I found elsewhere someone recommending to someone to look at nvLocked, for
them it was false (using the IBM tools). When they set it to true,
everything was fine. No such luck for me. It then says NV Locked: True,
however the data remains readable.

# ./tpminit
# ./tpmbios
# ./getcapability -cap 4 -scap 108
Disabled: FALSE
Ownership: TRUE
Deactivated: FALSE
Read Pubek: TRUE
Disable Owner Clear: FALSE
Allow Maintenance: TRUE
Physical Presence Lifetime Lock: FALSE
Physical Presence HW Enable: FALSE
Physical Presence CMD Enable: TRUE
CEKPUsed: FALSE
TPMpost: FALSE
TPMpost Lock: FALSE
FIPS: FALSE
Operator: FALSE
Enable Revoke EK: TRUE
NV Locked: TRUE (or FALSE before)
Read SRK pub: FALSE
TPM established: FALSE
Maintenance done: FALSE
Disable full DA logic info: FALSE
# ./nv_definespace -in ffffffff -sz 0
(NV Locked reads true, but still gives anyone data)
# tpm_version
TPM 1.2 Version Info:
Chip Version: 1.2.3.19
Spec Level: 2
Errata Revision: 2
TPM Vendor ID: IFX
Vendor Specific data: 0313000b 00
TPM Version: 01010000
Manufacturer Info: 49465800



We use index 4 and 5, the others seem to have come with the chip.

# tpm_nvinfo
NVRAM index : 0x10000001 (268435457)
PCR read selection:
Localities : ALL
PCR write selection:
Localities : ALL
Permissions : 0x00001002 (WRITEALL|OWNERWRITE)
bReadSTClear : FALSE
bWriteSTClear : FALSE
bWriteDefine : FALSE
Size : 20 (0x14)

NVRAM index : 0x00000005 (5)
PCR read selection:
PCRs : 3, 4, 5, 8, 9, 12, 14
Localities : ALL
Hash : .........[redacted]...........
PCR write selection:
Localities : ALL
Permissions : 0x00040002 (AUTHREAD|OWNERWRITE)
bReadSTClear : FALSE
bWriteSTClear : FALSE
bWriteDefine : FALSE
Size : 20 (0x14)

NVRAM index : 0x1000f000 (268496896)
PCR read selection:
Localities : ALL
PCR write selection:
Localities : ALL
Permissions : 0x00020002 (OWNERREAD|OWNERWRITE)
bReadSTClear : FALSE
bWriteSTClear : FALSE
bWriteDefine : FALSE
Size : 1704 (0x6a8)

NVRAM index : 0x00000004 (4)
PCR read selection:
PCRs : 2, 4, 5, 8, 9, 12, 14
Localities : ALL
Hash : .........[redacted]...........
PCR write selection:
Localities : ALL
Permissions : 0x00040002 (AUTHREAD|OWNERWRITE)
bReadSTClear : FALSE
bWriteSTClear : FALSE
bWriteDefine : FALSE
Size : 20 (0x14)

NVRAM index : 0x30000001 (805306369)
PCR read selection:
Localities : ALL
PCR write selection:
Localities : ALL
Permissions : 0x00000002 (OWNERWRITE)
bReadSTClear : FALSE
bWriteSTClear : FALSE
bWriteDefine : FALSE
Size : 576 (0x240)

Has anyone else seen where the NV Definitions can seem to be set up
correctly, but the TPM always lets everyone have its secrets?

Todd

[Luigi Semenzato]

What IFX model is this? We use several models in Chromebooks and haven't
run into this problem.

One thing that's slightly suspicious is that the physical presence lifetime
lock is still set to FALSE. Normally it should get set to TRUE in some
factory flow, depending on whether you use the PP pin, or (optionally)
enable PP in the firmware. I wonder if there are other uninitialized
lifetime flags.

Post by Todd Griggins
At our company, we use TPMs to protect some data in an automated fashion.
For us we don't want user entry, just need to maintain chain of trust
through the OS booting. We've used mostly dells, and on all of them
everything has worked without a hitch, however, now we needed to use a
GIGABYTE motherboard with a plug-in TPM.
The general idea is on install, we take ownership, create some data in the
NVRAM and reboot. On reboot, the PCRs are in the state we want them
(mostly) thus we read the data out of the NVRAM, delete the entries, define
new ones, keyed to PCRs and write the data back.
On reboot, the data is safely locked away, should someone boot into
another OS, the TPM shouldn't give them the data. On the Dells, if
anything changes, TPM won't give anyone data, on these IFX parts, no matter
how much I mess with the PCRs, it just gives the data to anyone. In fact,
nothing I do seems to secure the NVRAM at all! What's more is I bought
another TPM module. The TPMs have the same lettering on them (same lot?)
I found elsewhere someone recommending to someone to look at nvLocked, for
them it was false (using the IBM tools). When they set it to true,
everything was fine. No such luck for me. It then says NV Locked: True,
however the data remains readable.
# ./tpminit
# ./tpmbios
# ./getcapability -cap 4 -scap 108
Disabled: FALSE
Ownership: TRUE
Deactivated: FALSE
Read Pubek: TRUE
Disable Owner Clear: FALSE
Allow Maintenance: TRUE
Physical Presence Lifetime Lock: FALSE
Physical Presence HW Enable: FALSE
Physical Presence CMD Enable: TRUE
CEKPUsed: FALSE
TPMpost: FALSE
TPMpost Lock: FALSE
FIPS: FALSE
Operator: FALSE
Enable Revoke EK: TRUE
NV Locked: TRUE (or FALSE before)
Read SRK pub: FALSE
TPM established: FALSE
Maintenance done: FALSE
Disable full DA logic info: FALSE
# ./nv_definespace -in ffffffff -sz 0
(NV Locked reads true, but still gives anyone data)
# tpm_version
Chip Version: 1.2.3.19
Spec Level: 2
Errata Revision: 2
TPM Vendor ID: IFX
Vendor Specific data: 0313000b 00
TPM Version: 01010000
Manufacturer Info: 49465800
We use index 4 and 5, the others seem to have come with the chip.
# tpm_nvinfo
NVRAM index : 0x10000001 (268435457)
Localities : ALL
Localities : ALL
Permissions : 0x00001002 (WRITEALL|OWNERWRITE)
bReadSTClear : FALSE
bWriteSTClear : FALSE
bWriteDefine : FALSE
Size : 20 (0x14)
NVRAM index : 0x00000005 (5)
PCRs : 3, 4, 5, 8, 9, 12, 14
Localities : ALL
Hash : .........[redacted]...........
Localities : ALL
Permissions : 0x00040002 (AUTHREAD|OWNERWRITE)
bReadSTClear : FALSE
bWriteSTClear : FALSE
bWriteDefine : FALSE
Size : 20 (0x14)
NVRAM index : 0x1000f000 (268496896)
Localities : ALL
Localities : ALL
Permissions : 0x00020002 (OWNERREAD|OWNERWRITE)
bReadSTClear : FALSE
bWriteSTClear : FALSE
bWriteDefine : FALSE
Size : 1704 (0x6a8)
NVRAM index : 0x00000004 (4)
PCRs : 2, 4, 5, 8, 9, 12, 14
Localities : ALL
Hash : .........[redacted]...........
Localities : ALL
Permissions : 0x00040002 (AUTHREAD|OWNERWRITE)
bReadSTClear : FALSE
bWriteSTClear : FALSE
bWriteDefine : FALSE
Size : 20 (0x14)
NVRAM index : 0x30000001 (805306369)
Localities : ALL
Localities : ALL
Permissions : 0x00000002 (OWNERWRITE)
bReadSTClear : FALSE
bWriteSTClear : FALSE
bWriteDefine : FALSE
Size : 576 (0x240)
Has anyone else seen where the NV Definitions can seem to be set up
correctly, but the TPM always lets everyone have its secrets?
Todd
------------------------------------------------------------------------------
_______________________________________________
TrouSerS-users mailing list
https://lists.sourceforge.net/lists/listinfo/trousers-users

[Ken Goldman]

This post might be inappropriate. Click to display it.

[Todd Griggins]

Sadly, only one of the motherboards we need to use has the pads on-board
for the TPM, if they all did, we would have just populated them.

Instead we opted to use pluggable modules, specifically, bought two of
these: http://www.amazon.com/dp/B00U07T0UE Would certainly hope they
finished it and had it ready for public use! Should I contact the vendor?
What would I tell them? My guess is "SPICY BOMB" may not have any idea
what I'm talking about. This seems like a rather serious security issue
considering it didn't report any errors when taking ownership, and setting
up the NV areas.

Does anyone know if there is there a better source for the gigabyte variant
of these modules?

I've been doing the TPM Clear in BIOS upon receiving these, should I /not/
be doing that?

Todd

Post by Ken Goldman

Post by Luigi Semenzato
What IFX model is this? We use several models in Chromebooks and
haven't run into this problem.
One thing that's slightly suspicious is that the physical presence
lifetime lock is still set to FALSE. Normally it should get set to TRUE
in some factory flow, depending on whether you use the PP pin, or
(optionally) enable PP in the firmware. I wonder if there are other
uninitialized lifetime flags.

It sounds like he's buying raw TPMs, so I would expect them to come
uninitialized. He is the "factory flow".
And yes, the lifetime lock should be set at some point so the TPM isn't
accidentally bricked.
------------------------------------------------------------------------------
_______________________________________________
TrouSerS-users mailing list
https://lists.sourceforge.net/lists/listinfo/trousers-users

[Luigi Semenzato]

As Ken said, there is some initialization you need to do with a brand
new TPM. It's not a security issue---it's all documented, and if they
didn't do it that way, you would lose a lot of flexibility. I looked
at this a few years back, I don't remember the details right now, but
that's where you should look, in the TPM 1.2 specification.

Doing a ClearOwner in the BIOS is not a problem, but depending on what
you need to do, you may have to take ownership again.

Sadly, only one of the motherboards we need to use has the pads on-board for
the TPM, if they all did, we would have just populated them.
Instead we opted to use pluggable modules, specifically, bought two of
these: http://www.amazon.com/dp/B00U07T0UE Would certainly hope they
finished it and had it ready for public use! Should I contact the vendor?
What would I tell them? My guess is "SPICY BOMB" may not have any idea what
I'm talking about. This seems like a rather serious security issue
considering it didn't report any errors when taking ownership, and setting
up the NV areas.
Does anyone know if there is there a better source for the gigabyte variant
of these modules?
I've been doing the TPM Clear in BIOS upon receiving these, should I /not/
be doing that?
Todd

Post by Ken Goldman

Post by Luigi Semenzato
What IFX model is this? We use several models in Chromebooks and
haven't run into this problem.
One thing that's slightly suspicious is that the physical presence
lifetime lock is still set to FALSE. Normally it should get set to TRUE
in some factory flow, depending on whether you use the PP pin, or
(optionally) enable PP in the firmware. I wonder if there are other
uninitialized lifetime flags.

It sounds like he's buying raw TPMs, so I would expect them to come
uninitialized. He is the "factory flow".
And yes, the lifetime lock should be set at some point so the TPM isn't
accidentally bricked.
------------------------------------------------------------------------------
_______________________________________________
TrouSerS-users mailing list
https://lists.sourceforge.net/lists/listinfo/trousers-users

------------------------------------------------------------------------------

[Ken Goldman]

Post by Todd Griggins
Instead we opted to use pluggable modules, specifically, bought two of
these: http://www.amazon.com/dp/B00U07T0UE Would certainly hope they
finished it and had it ready for public use! Should I contact the
vendor? What would I tell them? My guess is "SPICY BOMB" may not have
any idea what I'm talking about. This seems like a rather serious
security issue considering it didn't report any errors when taking
ownership, and setting up the NV areas.

It's not a security issue. Here's the rationale.

In the usual case, the vendor, in this case Infineon, ships the TPM with
NV and physical presence unlocked. This permits the OEM to provision
the TPM without needing authorization for better manufacturing line
performance. it also permits provisioning special "D bit" NV space that
cannot be done on a locked TPM. Certificates might go there.

Once the OEM is done provisioning, it locks NV. It also sets the PP
attributes based on its firmware needs and locks them.

In your case, you bypassed the OEM. You're doing the provisioning. So,
you want the TPM in it's default, unlocked state.

If you, the OEM, shipped to the end user in this state, then you (not
Infineon) would have a security issue.




------------------------------------------------------------------------------

[Todd Griggins]

This is mildly confusing to me - as the TPM module on sale is for end-users
(for the most part, what we are), not of OEMs. This is also confusing
because this is not the state other TPMs come in, such as from Dell or HP.

The following TLDR: Used trousers to define NV ix 0xffffffff. Data locks
away (splendid!). Chips now needs owner passwords to do anything (bad).
How do I make the TPM act like other TPMs in not always needing owner
password for /everything/? Why does tpm_setpresence -a not work?




I am open to doing this "initializing" myself - provided I can be helped
along a little. After extensive google searching, I can only find
references to "TPM initialization" as meaning:

1) Clear TPM (we do with BIOS)
2) Allow taking of ownership (in BIOS)
3) Take Ownership (using trousers, works, no issues)
4) Define nvram section (using trousers, some issues)

From what you guys are saying it sounds like that's not it.

I realized I seriously misunderstood how the IBM tools work and it turns
out I was only operating on the virtual TPM, when I was running them.
Instead, I did the following:

# tpm_nvdefine -i 0xffffffff -s 0

Which worked. I could clear my TPM, allow ownership, take ownership,
define my NVRAM sections. Though as soon as I attempt to do anything else
to them, such as writing to the NVRAM, re-defining them (which we need to
do as part of our process), reading or... anything, I get the following
problems:

Configuring the NVRAM:

# tpm_nvdefine -i 4 -s 20 -p "OWNERWRITE|AUTHREAD" -o [tpm password] -a
[section password]
A-Okay (the first time)

Writing to the NVRAM:

# tpm_nvwrite -i 5 -s 20 -d [data]

Unless I provide -p and the password, it fails with "Tspi_NV_WriteValue
failed: 0x0000003b - layer=tpm, code=003b (59), NV_LoadKey blob requires
both owner and blob authorization" - this is undesired behavior.


Re-defining the NVRAM:

# tpm_nvrelease -i 5

Unless, I pass the -o flag, it fails with: "Tspi_NV_ReleaseSpace failed:
0x0000002d - layer=tpm, code=002d (45), Bad physical presence value"

Also, can't read from the nvram unless (1) the PCRs match (good) and (2) it
needs the owner password (bad)

# tpm_setpresence
Physical Presence Status:
Command Enable: true
Hardware Enable: false
Lifetime Lock: false
Physical Presence: false
Lock: true

Just our of curocity, I tried playing with some enable flags...

# tpm_setpresence --enable-cmd
Tspi_TPM_SetStatus failed: 0x00002006 - layer=tcs, code=0006 (6), Not
implemented

# tpm_setpresence --enable-hw
Tspi_TPM_SetStatus failed: 0x00002006 - layer=tcs, code=0006 (6), Not
implemented

# tpm_setpresence -a
Tspi_TPM_SetStatus failed: 0x00002006 - layer=tcs, code=0006 (6), Not
implemented

In BIOS, I get a few options: Clear TPM, Set Enable Ownership, Set Disable
Ownership, Deactivate TPM. TPM's active. If I "Set Enable Ownership"
sometimes, I can't communicate to the TPM (TCSD communications error)
sometimes it communicates but still can't do anything interesting.


tpm_getpubek works... No problems there...

Just curious, I tried tpm_assertpp.c. A-okay without errors, but no change
to tpm_setpresence.

I tried a few other commands just in case you guys notice anything:

# tpm_setactive
Persistent Deactivated Status: false
Volatile Deactivated Status: false

# tpm_nvinfo
NVRAM index : 0x10000001 (268435457)
PCR read selection:
Localities : ALL
PCR write selection:
Localities : ALL
Permissions : 0x00001002 (WRITEALL|OWNERWRITE)
bReadSTClear : FALSE
bWriteSTClear : FALSE
bWriteDefine : FALSE
Size : 20 (0x14)

NVRAM index : 0x00000004 (4)
PCR read selection:
Localities : ALL
PCR write selection:
Localities : ALL
Permissions : 0x00040002 (AUTHREAD|OWNERWRITE)
bReadSTClear : FALSE
bWriteSTClear : FALSE
bWriteDefine : FALSE
Size : 20 (0x14)

NVRAM index : 0x1000f000 (268496896)
PCR read selection:
Localities : ALL
PCR write selection:
Localities : ALL
Permissions : 0x00020002 (OWNERREAD|OWNERWRITE)
bReadSTClear : FALSE
bWriteSTClear : FALSE
bWriteDefine : FALSE
Size : 1704 (0x6a8)

NVRAM index : 0x00000005 (5)
PCR read selection:
Localities : ALL
PCR write selection:
Localities : ALL
Permissions : 0x00040002 (AUTHREAD|OWNERWRITE)
bReadSTClear : FALSE
bWriteSTClear : FALSE
bWriteDefine : FALSE
Size : 20 (0x14)

NVRAM index : 0x30000001 (805306369)
PCR read selection:
Localities : ALL
PCR write selection:
Localities : ALL
Permissions : 0x00000002 (OWNERWRITE)
bReadSTClear : FALSE
bWriteSTClear : FALSE
bWriteDefine : FALSE
Size : 576 (0x240)


All in all - I am much further, however, now, after re-defining the areas,
I cannot read the data within them without entering an owner password which
is not an acceptable solution.

What steps can I take to make this TPM act like the other TPMs as far as
not needing owner passwords to do... everything? Does this have anything
to do with "lock" on the tpm_setpresence? What are the security
implications of just saying "forget the tpm password, I'll make it well
known"?

Todd

Post by Todd Griggins
Instead we opted to use pluggable modules, specifically, bought two of
these: http://www.amazon.com/dp/B00U07T0UE Would certainly hope they
finished it and had it ready for public use! Should I contact the
vendor? What would I tell them? My guess is "SPICY BOMB" may not have
any idea what I'm talking about. This seems like a rather serious
security issue considering it didn't report any errors when taking
ownership, and setting up the NV areas.

It's not a security issue. Here's the rationale.
In the usual case, the vendor, in this case Infineon, ships the TPM with
NV and physical presence unlocked. This permits the OEM to provision
the TPM without needing authorization for better manufacturing line
performance. it also permits provisioning special "D bit" NV space that
cannot be done on a locked TPM. Certificates might go there.
Once the OEM is done provisioning, it locks NV. It also sets the PP
attributes based on its firmware needs and locks them.
In your case, you bypassed the OEM. You're doing the provisioning. So,
you want the TPM in it's default, unlocked state.
If you, the OEM, shipped to the end user in this state, then you (not
Infineon) would have a security issue.
------------------------------------------------------------------------------
_______________________________________________
TrouSerS-users mailing list
https://lists.sourceforge.net/lists/listinfo/trousers-users

[Todd Griggins]

Just to finish up this chain I figured I should report in.

We set the NV flag (tpm_nvdefine -i 0xffffffff -s 0), and just type in the
owner password for everything. The PCRs still seem to lock the data. The
presence flag doesn't get set, but it seems to work. Once all the flags
are set up properly, the nvread (without trousers) works properly and the
TPM seems to abide by the proper rules.

David, if you are still up for posting the command to initialize the TPM,
that would be really good, if for nothing other than reference. The
internet seems to have forgotten the command to do that. I do appreciate
everyone's help on the issue.

Post by Todd Griggins
This is mildly confusing to me - as the TPM module on sale is for
end-users (for the most part, what we are), not of OEMs. This is also
confusing because this is not the state other TPMs come in, such as from
Dell or HP.

If you are buying uninitialized TPM chips, you are not an end user. You
are in the same position as an OEM, and you must initialize it.
AS for the rest of the email, remember that we are volunteers. It's
unlikely that anyone will give priority to analyzing your 5 page blog over
their day job. I suggest that you create a much shorter version of your
post, with one precise question and a meaningful subject.