Hi Ken, it looks like I get the intended behaviour when using the software tpm.
Am 27.1.2014 18:41, schrieb Ken Goldman: > I don't see anything wrong with what you're trying to do. > > Can you switch from the hardware TPM to the SW TPM? > > You can then get a trace of the TPM internals. This would tell you > whether the problem is in the tools, in the TSS, or perhaps even in the > TPM. > > I can't imagine debugging any application with the HW TPM, but of > course > I wrote the SW TPM. :-) What I'm doing: # Start the software tpm [root@nuc tpm]# export TPM_PORT=1000 [root@nuc tpm]# export TPM_PATH=/tmp/tpm [root@nuc tpm]# ./tpm_server main: Initializing TPM at Mon Jan 27 20:36:31 2014 main: Compiled for latest revision specLevel 0002 errataRev 03 main: Compiled svn version 4662 revMajor 12 revMinor 36 main: Compiled as standard TPM main: Compiled for single instance main: Compiled for PC Client Main: Compiled for 3 auth 3 transport 1 DAA session slots Main: Compiled for 3 key slots, 1 owner evict slots Main: Compiled for 4 counters, 16 saved sessions Main: Compiled for 8 family, 2 delegate table entries Main: Compiled for 100000 total NV, 100000 savestate, 524288 volatile space Main: Compiled for 2100 NV defined space TPM_MainInit: Initialize the TPM to host interface TPM_IO_Init: TPM_IO_ServerSocket_Open: Port 1000 [...] On another terminal I'll then continue: # Initialize the swtpm [root@nuc libtpm]# tpmbios [root@nuc libtpm]# createek [root@nuc libtpm]# nv_definespace -in ffffffff -sz 0 [root@nuc libtpm]# export TCSD_TCP_DEVICE_PORT=1000 [root@nuc libtpm]# tcsd -e # Lets have a look and take ownership [root@nuc libtpm]# tpm_version TPM 1.2 Version Info: Chip Version: 1.2.18.54 Spec Level: 2 Errata Revision: 3 TPM Vendor ID: IBM TPM Version: 01010000 Manufacturer Info: 49424d00 [root@nuc libtpm]# tpm_nvinfo [root@nuc libtpm]# tpm_takeownership Enter owner password: Confirm password: Enter SRK password: Confirm password: # Lets reuse yesterdays PCR values to seal the data [root@nuc libtpm]# cat /tmp/pcrs.out r 4 46a1d70bdb606a4223f9d2edab6de588fdad5d29 r 5 14deb4f77eed002430c009286f94b27cc1b522f7 r 8 8f3c9308fbc80110349a095b6441d508001f15cf r 9 97fa107b895137ce8b687b136977eb9ee3cceec9 r 12 8d2dbb8325737829a5ab9527f3fc08a0f302b68e r 14 fec0b65fea553b3891c1dc52101c96d9be84f1b7 # My current PCRs are different (check PCR-12) which means I should be having issues retrieving data [root@nuc libtpm]# cat /sys/class/misc/tpm0/device/pcrs | grep -E 'PCR-(0[4589]|1[24])' PCR-04: 46 A1 D7 0B DB 60 6A 42 23 F9 D2 ED AB 6D E5 88 FD AD 5D 29 PCR-05: 14 DE B4 F7 7E ED 00 24 30 C0 09 28 6F 94 B2 7C C1 B5 22 F7 PCR-08: 8F 3C 93 08 FB C8 01 10 34 9A 09 5B 64 41 D5 08 00 1F 15 CF PCR-09: 97 FA 10 7B 89 51 37 CE 8B 68 7B 13 69 77 EB 9E E3 CC EE C9 PCR-12: 87 A9 9E 28 84 6C 43 61 0A 2F 79 4C 29 B9 DE B3 66 FD 3C 17 PCR-14: FE C0 B6 5F EA 55 3B 38 91 C1 DC 52 10 1C 96 D9 BE 84 F1 B7 [root@nuc libtpm]# # Let's have a look at appropriately defining and filling the nvram area. We're using the same commands as yesterday [root@nuc libtpm]# tpm_nvdefine -i 3 -o foo -a foobar -s 32 -f /tmp/pcrs.out -p AUTHWRITE Successfully created NVRAM area at index 0x3 (3). [root@nuc libtpm]# tpm_nvdefine -i 4 -o foo -a foobar -s 32 -f /tmp/pcrs.out -p 'AUTHREAD|AUTHWRITE' Successfully created NVRAM area at index 0x4 (4). [root@nuc libtpm]# tpm_nvinfo NVRAM index : 0x00000003 (3) PCR read selection: PCRs : 4, 5, 8, 9, 12, 14 Localities : ALL Hash : 51522172b46ed13a34ca45f445472291c9675ef5 PCR write selection: Localities : ALL Permissions : 0x00000004 (AUTHWRITE) bReadSTClear : FALSE bWriteSTClear : FALSE bWriteDefine : FALSE Size : 32 (0x20) NVRAM index : 0x00000004 (4) PCR read selection: PCRs : 4, 5, 8, 9, 12, 14 Localities : ALL Hash : 51522172b46ed13a34ca45f445472291c9675ef5 PCR write selection: Localities : ALL Permissions : 0x00040004 (AUTHREAD|AUTHWRITE) bReadSTClear : FALSE bWriteSTClear : FALSE bWriteDefine : FALSE Size : 32 (0x20) [root@nuc libtpm]# tpm_nvwrite -i 3 -p -d 12345678901234567890123456789012 Enter NVRAM access password: Successfully wrote 32 bytes at offset 0 to NVRAM index 0x3 (3). [root@nuc libtpm]# tpm_nvwrite -i 4 -p -d 12345678901234567890123456789012 Enter NVRAM access password: Successfully wrote 32 bytes at offset 0 to NVRAM index 0x4 (4). # Let's read the data [root@nuc libtpm]# tpm_nvread -i 3 Tspi_NV_ReadValue failed: 0x00000018 - layer=tpm, code=0018 (24), Wrong PCR value [root@nuc libtpm]# tpm_nvread -i 4 Tspi_NV_ReadValue failed: 0x0000003b - layer=tpm, code=003b (59), NV_LoadKey blob requires both owner and blob authorization [root@nuc libtpm]# Ohh. Look at that. This seems to be the expected behaviour. Now why do we get that with the swtpm but not with the hwtpm? Full tpm_server output is visible at <http://fpaste.org/72105/52578139/>. cheers, andreas ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ TrouSerS-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/trousers-users
