Bill and Andreas, As a TrouSerS maintainer, I'll take a look at the issues and see if it's generated by some bug in TrouSerS or tpm-tools. I'll fix them myself as soon as I find the cause.
Em 26-01-2014 23:44, Bill Martin escreveu: > 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 > ------------------------------------------------------------------------------ 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
