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
On Fri, Sep 11, 2015 at 6:14 PM, Ken Goldman <[email protected]> wrote:
> On 9/11/2015 11:11 AM, Todd Griggins wrote:
> >
> > 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/trousers-users
>
------------------------------------------------------------------------------
_______________________________________________
TrouSerS-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/trousers-users
