Yes it seems you should not be able to read using index i=3, particularly since you did the nvdefine using the old PCR 12. Your situation does not seem to make this trusted computing any more trusting than my situation.
Hopefully by having another person question the security of NVRAM it will spark some activity in the developers to review the code. I have tpm-tools 1.3.9, which is newer than yours. And TrouSers 0.3.10 which is one off. I will revisit the TrouSers to see if 0.3.11 took care of the issue I am seeing. I thought I looked into the release notes and did not see anything that addressed my issues. I'm running on an atom-based CPU with x86 architecture. It's an infineon chip, but oddly, I cannot seem to pull the EK certificate from the chip, for another TPM application I am working on. I'm trying to bring up TPM on an ARM-based BeagleBoard XM Rev C with a newer TPM chip that supposedly will have the EK cert. But I am using U-boot on it and there is no grub. Maybe my atom CPU could be part of the problem. Thanks for the note about the broken TPM tools. Bill ________________________________________ From: Andreas Thienemann [[email protected]] Sent: Sunday, January 26, 2014 4:57 PM To: Bill Martin Cc: [email protected]; Greg Powell Subject: RE: [TrouSerS-users] nvram storage and sealing to PCRs Hi Bill, Am 27.1.2014 01:09, schrieb Bill Martin: > I have been trying to get the same answers from the tpm-tools and > TrouSers through this users group folks for two months and I guess my > posts have been forgotten. This was two or three months ago. Whoaps. Let's hope I will have more luck. > It is interesting that you imply if you use AUTHREAD|AUTHWRITE when > you use PCRs 12 and 14 (at the least) that you do not have access to > NVRAM if a register changes. Correct. I am using my own trustedgrub-1.1.5 rpm on a centos6 machine. I tried getting tpm-luks to work with fedora20 but the systemd stuff is too annoying for now which made me go back to CO6. (For the record, tgrub works great on F20...) When I remove e.g. the rhgb command from the commandline PCR12 should change and indeed I do not have access to the nvram area anymore. > First, I modified my menu.lst so that PCR 12 will change. I can still > get access to my NVRAM. That is the problem and I even modified my own > copy of tpm_nvdefine to print out some debug info to try to pinpoint > what is going on. > > 1) So I'm wondering first: Did you alter PCR-12? That is very > important for me to know. As described above, yes. > 2) Also what versions of TrouSers and tpm-tools are you running? tpm-tools-1.3.8 trousers-0.3.11.2 Both freshly compiled from source as the CO6 rpms are too old. (For the record, tpm-tools on F20 is broken, https://bugzilla.redhat.com/show_bug.cgi?id=952372) > As for changing permission to AUTHWRITE only and being able to access > NVRAM, that does not make sense either because you say your access is > certainly controlled by AUTHREAD|AUTHWRITE, a weaker condition. Yes, I was very confused... > Also in case you wonder - localities don't seem to have an effect, > according to communication from one of the top TrouSers folks. Hmm. Shame. Would be nice to be able to limit stuff there but meh... One could always set bReadSTClear and do a second read on the area to lock it down... > I do not trust the usage of PCRs to define NVRAM - not yet because I > can still access information out of NVRAM regardless of the contents > of my PCR 12, which I certainly used in the nvdefine. Let's try and see what I get here: PCR-12, the commandline: [root@foo ~]# cat /proc/cmdline; md5sum /proc/cmdline ro root=/dev/mapper/vg_nuc-lv_root LANG=en_US.UTF-8 rd_LVM_LV=vg_nuc/lv_swap KEYBOARDTYPE=pc KEYTABLE=us rd_LVM_LV=vg_nuc/lv_root rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=130M@0M rd_LUKS_UUID=luks-fd1d4dcb-5e11-4fd9-b14a-b34757fe2692 rd_NO_DM rhgb quiet 39af97c75febfb238bb6a5b3547a81cc /proc/cmdline [root@foo ~]# The pcr permission file I'm using to seal the data. [root@foo ~]# tpm-luks-gen-tgrub-pcr-values -o /tmp/pcrs.out; cat /tmp/pcrs.out r 4 46a1d70bdb606a4223f9d2edab6de588fdad5d29 r 5 14deb4f77eed002430c009286f94b27cc1b522f7 r 8 8f3c9308fbc80110349a095b6441d508001f15cf r 9 97fa107b895137ce8b687b136977eb9ee3cceec9 r 12 8d2dbb8325737829a5ab9527f3fc08a0f302b68e r 14 fec0b65fea553b3891c1dc52101c96d9be84f1b7 [root@foo ~]# Let's compare against my current running PCRs: [root@foo ~]# 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: 8D 2D BB 83 25 73 78 29 A5 AB 95 27 F3 FC 08 A0 F3 02 B6 8E PCR-14: FE C0 B6 5F EA 55 3B 38 91 C1 DC 52 10 1C 96 D9 BE 84 F1 B7 [root@foo ~]# Looks to be identical. Let's define two tpm nvram areas, one AUTHWRITE and one AUTHREAD|AUTHWRITE [root@foo ~]# tpm_nvdefine -i 3 -o barbaz -a foobar -s 32 -f /tmp/pcrs.out -p AUTHWRITE Successfully created NVRAM area at index 0x3 (3). [root@foo ~]# tpm_nvinfo -i 3 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) [root@foo ~]# tpm_nvdefine -i 4 -o barbaz -a foobar -s 32 -f /tmp/pcrs.out -p 'AUTHREAD|AUTHWRITE' Successfully created NVRAM area at index 0x4 (4). [root@foo ~]# tpm_nvinfo -i 4 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@foo ~]# Let's fill the nvram and see if we can read the data back: [root@foo ~]# tpm_nvwrite -i 3 -p -d 12345678901234567890123456789012 Enter NVRAM access password: Successfully wrote 32 bytes at offset 0 to NVRAM index 0x3 (3). [root@foo ~]# tpm_nvwrite -i 4 -p -d 12345678901234567890123456789012 Enter NVRAM access password: Successfully wrote 32 bytes at offset 0 to NVRAM index 0x4 (4). [root@foo ~]# tpm_nvread -i 3 00000000 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 1234567890123456 00000010 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 7890123456789012 [root@foo ~]# tpm_nvread -i 4 Tspi_NV_ReadValue failed: 0x0000003b - layer=tpm, code=003b (59), NV_LoadKey blob requires both owner and blob authorization [root@foo ~]# tpm_nvread -i 4 -p Enter NVRAM access password: 00000000 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 1234567890123456 00000010 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 7890123456789012 [root@nuc ~]# Looks good. Works exactly as it should be. Index 3 can be read without a password, index 4 needs a password to read. Now reboot and make sure the cmdline is different which also changes my PCRs. [root@nuc ~]# cat /proc/cmdline; md5sum /proc/cmdline ro root=/dev/mapper/vg_nuc-lv_root LANG=en_US.UTF-8 rd_LVM_LV=vg_nuc/lv_swap KEYBOARDTYPE=pc KEYTABLE=us rd_LVM_LV=vg_nuc/lv_root rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=130M@0M rd_LUKS_UUID=luks-fd1d4dcb-5e11-4fd9-b14a-b34757fe2692 rd_NO_DM 620e1b5a6537d7f09adc594f0b5d08e8 /proc/cmdline [root@nuc ~]# Yeah, the md5 has changed. Let's verify against PCRs: [root@nuc ~]# 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 ~]# Indeed. PCR-12 has changed. [root@nuc ~]# tpm_nvread -i 3 00000000 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 1234567890123456 00000010 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 7890123456789012 [root@nuc ~]# tpm_nvread -i 4 -p Enter NVRAM access password: Tspi_NV_ReadValue failed: 0x00000018 - layer=tpm, code=0018 (24), Wrong PCR value [root@nuc ~]# Ohh look at that. Index 3 is readable but shouldn't and Index 4 is correctly marked as not readable with the wrong PCR value. So I cannot reproduce your issue. But I hope I have nicely demonstrated mine. 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
