Ok I had some more time to work on this. The rundown is that I have not seen how the TPM NVRAM is lockable to PCRs at all, at least through tpm-tools 1.3.9. I might have to go down a level to TrouSers (but don't want to).
I have tpm-tools 1.3.9 TrouSers 0.3.10 cryptsetup 1.6.2 TrustedGRUB 1.1.5 tpm_infineon is the tpm module / driver I suspect the TPM tools or TrouSers is not locking my NVRAM even though I can make PCR 12 change between boots. I suspect the -f option of tpm_nvdefine is not locking. Today I tried to just spell out the PCRs with a series of -r and -w, also used -R and -W for locality 0 by specifying 0x1. My command tpm_nvdefine looks like this. It's actually the result of my modified tpm-luks script. tpm_nvdefine -i 2 -s 32 -r 4 -r 5 -r 12 -w 12 -w 14 -r 14 -R 0x1 -W 0x1 -p "AUTHREAD|AUTHWRITE" Now I know from the tpm_nvdefine.c code that tpmPcrRead is called to get the PCRs when the -r or -w options are used. Also the pcrcompositeSetPcrLocality command is called. I specified locality 0 for both read and write. I then called tpm_nvwrite to write my key to index -i 2 tpm_nvinfo showed root@crownbay-noemgd:~# tpm_nvinfo NVRAM index : 0x00000002 (2) PCR read selection: PCRs : 4, 5, 12, 14 Localities : 0x1 Hash : fb9b920bd4bad261b007e37321b9e77ec859ba16 PCR write selection: PCRs : 12, 14 Localities : 0x1 Hash : 42dab47c250e7e3ecc2bce2d57bfc8bd9ce63300 Permissions : 0x00040004 (AUTHREAD|AUTHWRITE) bReadSTClear : FALSE bWriteSTClear : FALSE bWriteDefine : FALSE Size : 32 (0x20) The above looks reasonable. I changed menu.lst and tried with and without checkfile so that I would modify per-12. I was still able to read the data out of NVRAM no matter what. I am also sure I wipe the old key file after the tpm_nvwrite and after I'm done opening my LUKS device with the key I read in from tpm_nvread I don't believe the NVRAM is lockable at all. What am I doing wrong? I see for myself that no matter what value of PCR 12 I can read the information I wrote in the tpm_nvwrite. I would expect that as someone new to TPM, I would not be able to unlock the NVRAM without getting help from an expert because of me doing something wrong. But as someone new to TPM I should not be able to always unlock the NVRAM! Below shows I'm using tpm_infineon and you see my tpm version number info. lsmod Module Size Used by tpm_infineon 7730 0 tpm_version TPM 1.2 Version Info: Chip Version: 1.2.3.17 Spec Level: 2 Errata Revision: 2 TPM Vendor ID: IFX Vendor Specific data: 03110008 00 TPM Version: 01010000 Manufacturer Info: 49465800 My only explanation is that the low level tcg software is reading menu.lst and does not include checkfile. I found there is a tspi function that gets the per information out of some data structure. How the data structure gets populated is a mystery to me. I know PCRs at power up are zero. So reading menu.lst and measuring fewer commands than I assume would explain things a lot. I looked on google and have not found anyone in the field using the commands related to tpm_nvdefine, tpm_nvwrite, tpm_nvread, or some of their underlying commands in tspi. I found articles from various sites that seem to just repeat what other sites say, that the NVRAM is lockable to PCRs. I need proof! thanks Bill ________________________________________ From: Bill Martin Sent: Tuesday, November 26, 2013 8:55 AM To: [email protected] Subject: FW: [TrouSerS-users] tpm-tool 1.3.9's tpm_nvdefine's parseNVPermsFile: Where are existing PCR readings verified prior to making the PCR composite? FYI ________________________________________ From: Bill Martin Sent: Tuesday, November 26, 2013 8:41 AM To: David Challener Subject: RE: [TrouSerS-users] tpm-tool 1.3.9's tpm_nvdefine's parseNVPermsFile: Where are existing PCR readings verified prior to making the PCR composite? Also I must add that I can even run the tpm-luks-init script and leave out PCR 13 in the list and provide the same NV PCR list by excluding the checkfile command. The -f parameter into tpm_nvdefine would be the same, a file of r 4 3d80d7fe658e835d58e12f97f72a713ac7660817 r 5 e51eb6a9f41824f63ec60a44237c5c2116b4f991 r 12 baa02214e76f7edd250994405ad9563dfb483443 r 14 fe9aba7c51bae06a65a99e0cbb862d49be06d4f0 And I can get the same "secret" data out via tpm_nvread as I did with tpm_nvwrite even though the real PCR value for 12 PCR-12: 44 AF 1D 83 74 2D F5 97 05 E6 6D 1D 2C 63 76 D5 6C CE 2E 8D. I expected tpm_nvread to return some value that was different because PCR-12 changed. I can unencrypted my LUKs partition with the value tpm_nvread returned regardless of whether I add a checkfile statement in menu.lst. ________________________________________ From: Bill Martin Sent: Tuesday, November 26, 2013 8:27 AM To: David Challener Subject: RE: [TrouSerS-users] tpm-tool 1.3.9's tpm_nvdefine's parseNVPermsFile: Where are existing PCR readings verified prior to making the PCR composite? Hi David yes I did check the PCR values. "You code unfortunately doesn't use TSS commands, so it is hard to tell. Did you actually check the values that are in the PCRs to make sure they differ as they should?" The code I referred to was from tpm_nvdefine in the function parseNVPerms. Here is the dump of the file for the -f parameter for the call into tpm_nvdefine when I run tpm-luks-init (Kent Yoder's script) r 4 3d80d7fe658e835d58e12f97f72a713ac7660817 r 5 e51eb6a9f41824f63ec60a44237c5c2116b4f991 r 12 baa02214e76f7edd250994405ad9563dfb483443 r 14 fe9aba7c51bae06a65a99e0cbb862d49be06d4f0 So from my understanding, an NVRAM area is defined somehow based on these four read-only values. The tpm-luks-init script generated a random 32-byte key and then calls tpm_nvwrite, with an index i into NVRAM I chose arbitrarily. Now the tpm-luks-init script used this same key that was supposedly stored in NVRAM based on the above four PCRs and hash values and calls cryptsetup with luksAddKey to encrypt my LUKs partition. So I'm done with the script. Now I changed my menu.lst so that I add a checkfile call. So I reboot. After rebooting I must reopen my LUKS partition and type in my password since I do not choose to use the well known password. I now use tpm-luks to open the LUKS partition. I should not be able to because PCR 12 has changed! This tpm-luks open operation user tpm_nvread, with the same NVRAM index I chose as with the tpm_nvwrite before my reboot. So I expect the nvread to reference somehow the same defined NVRAM memory space based on the PCR hash values as I sent in with the tpm_nvdefine. Something is very odd. Here is a copy of the PCR values after I added a checkfile statement in menu.lst (I use TrustedGrub) root@crownbay-noemgd:~# cat /sys/class/misc/tpm0/device/pcrs PCR-00: 87 6A 18 78 C5 43 62 C8 95 06 61 48 8E 60 23 49 F2 A0 89 11 PCR-01: 30 66 6A 4A C8 31 C0 12 ED E5 D7 EF B0 25 88 85 73 DE FC 07 PCR-02: 8A 06 1C B2 CF 13 39 7F A1 A2 28 A4 1F 31 1D 6A D0 92 2E 2F PCR-03: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75 PCR-04: 3D 80 D7 FE 65 8E 83 5D 58 E1 2F 97 F7 2A 71 3A C7 66 08 17 PCR-05: E5 1E B6 A9 F4 18 24 F6 3E C6 0A 44 23 7C 5C 21 16 B4 F9 91 PCR-06: 78 CD 77 59 86 6A 77 D0 31 03 C2 03 5B F7 DC 7E 61 DC 19 2E PCR-07: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75 PCR-08: E6 08 14 11 5E 11 FC 94 18 29 5B F9 43 8F 1F 03 F7 80 37 AA PCR-09: 94 D7 CA 5B D0 78 86 40 56 FC 47 19 68 AF 4F CC CE 4C 1C 67 PCR-10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-11: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-12: 44 AF 1D 83 74 2D F5 97 05 E6 6D 1D 2C 63 76 D5 6C CE 2E 8D PCR-13: 79 85 5C 47 87 93 72 67 DA D4 49 91 C7 0D AD F1 D6 A0 25 8C PCR-14: FE 9A BA 7C 51 BA E0 6A 65 A9 9E 0C BB 86 2D 49 BE 06 D4 F0 PCR-15: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-16: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-17: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF PCR-18: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF PCR-19: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF PCR-20: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF PCR-21: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF PCR-22: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF PCR-23: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 By the way, here is a longer copy of an earlier post to Trousers with details below. Note I got a "fail" message for reusing index 9. This was not really the cause of my problem since I subsequently did a tpm_nvrelease operation on -i 9 and started my process all over, including randomizing my partition /dev/sda2. thanks Bill ================================================= From: Bill Martin Sent: Thursday, November 21, 2013 9:24 AM To: [email protected] Cc: Greg Powell; Cameron Durham Subject: Re: TPM Support for LUKS Partitions. Hi group, Hopefully Kent Yoder will see this and respond. In reference to 2012-11-28 his announcement of the tpm-luks tools. I think there is a problem in tpm_nvdefine / tpm_nvwrite / tpm_nvread still. I am using -f to send in the PCR list. I think maybe the -r and -w options for tpm_nvdefine must be used. This is a long message but is also some feedback of the tpm-luks tool that Kent requested here goes: I have tpm-tools 1.3.9, TrouSers 0.3.10, crypt setup 1.6.2, TrustedGRUB-1.1.5 on an x86 architecture Linux system. After a few mods of tpm-luks scripts I managed to get where I can generate the NVPERMS files for PCRs 4, 5, 12, and 14. We made some mods because for some reason, perhaps our version of bash, some of the commands in the script did not work. My colleague, Cameron Durham, for instance found on line 122 in tpm-luks the line needed an an extra pair of parens around ${NV_INDEXES[$i]} # On line 122 in tpm-luks change line to # if [ $(( ${NV_INDEXES[$i]} )) -lt ${TPM_LUKS_NV_INDEX_LIMIT} ]; then And in tpm-luks-gen-tgrub-pcr-values the lines like KERNELS=( $(cat ${MENU} | awk -F "\n" '$1 ~ /^\Wkernel/ { print $0 }') ) produced an empty line. Our bash had a problem with "^\W" in these lines, for instance. This one worked for me KERNELS=( $(cat ${MENU} | awk '$1 ~ /kernel/ { print $0 }') ) My application is to encrypt a hard disk partition, /dev/sda2 So I start by $ cryptsetup --debug -c aes-cbc-plain -s 256 luksFormat /dev/sda2 The above asks for my initial passphrase and puts it in LUKS index 0 I then made a LUKS name for /dev/sda2 $ cryptsetup open /dev/sda2 secretfs the luksDump is $ cryptsetup luksDump /dev/sda2 LUKS header information for /dev/sda2 Version: 1 Cipher name: aes Cipher mode: cbc-plain Hash spec: sha1 Payload offset: 4096 MK bits: 256 MK digest: 12 26 d7 4c a2 81 6b b5 cd 5e 76 4a 34 b6 52 a7 71 c4 ff fa MK salt: 8c ed 15 7a 74 68 6b 97 e8 13 df 08 14 db b5 0a b0 00 0e 18 fb f8 0b fd 4d be 5f 7e 17 e3 bc 41 MK iterations: 16750 UUID: 7438bfd3-878c-4778-a296-c5eae309a3a3 Key Slot 0: ENABLED Iterations: 66805 Salt: 20 48 70 a5 3a 0f 44 d9 9e 16 95 9f ca 68 de 22 bf 46 be 32 94 bc ce fe ba 25 4d 34 c9 a9 55 c3 Key material offset: 8 AF stripes: 4000 Key Slot 1: DISABLED Key Slot 2: DISABLED Key Slot 3: DISABLED Key Slot 4: DISABLED Key Slot 5: DISABLED Key Slot 6: DISABLED Key Slot 7: DISABLED I then made a mount point /mnt/thePartition/secretfs and mounted /dev/mapper/secretfs there. I put a file junk.dat in /mnt/thePartition/secretfs In /etc/tpm-luks.conf I put the line in like /dev/sda2:9:/usr/sbin/tpm-luks-gen-tgrub-pcr-values So now I ran tpm-luks-init $ tpm-luks-init So from tpm-luks-init (with my added debug statements) and based on my menu.lst I got something like root@crownbay-noemgd:/# tpm-luks-init Generating PCR values for /dev/sda2... w 12 baa02214e76f7edd250994405ad9563dfb483443 w 14 fe9aba7c51bae06a65a99e0cbb862d49be06d4f0 tpm-luks-gen... removed tempfile In tpm-luks Before call to tpm-luks -c...PCRs r-w permissions file is: r 4 3d80d7fe658e835d58e12f97f72a713ac7660817 r 5 e51eb6a9f41824f63ec60a44237c5c2116b4f991 r 12 baa02214e76f7edd250994405ad9563dfb483443 r 14 fe9aba7c51bae06a65a99e0cbb862d49be06d4f0 Creating new TPM NVRAM secret for /dev/sda2... Enter a new TPM NV area password: Re-enter the new TPM NV area password: Enter your TPM owner password: NVINDEX is 9 KEYFILE_SIZE is 32 RW_PERMS is AUTHREAD|AUTHWRITE PERMSFILE is /tmp/tpm-luks-init-7UQrlH Tspi_NV_DefineSpace failed: 0x0000313b - layer=tsp, code=013b (315), NVRAM area already exists tpm-luks tpm_nvdefine uses -f with file /tmp/tpm-luks-init-7UQrlH as below r 4 3d80d7fe658e835d58e12f97f72a713ac7660817 r 5 e51eb6a9f41824f63ec60a44237c5c2116b4f991 r 12 baa02214e76f7edd250994405ad9563dfb483443 r 14 fe9aba7c51bae06a65a99e0cbb862d49be06d4f0 Successfully wrote 32 bytes at offset 0 to NVRAM index 0x9 (9). in nv_devine_and_write just called tpm_nvwrite DATAFILE is /dev/shm/key and dumped: 0000000 0e 30 a6 ec 58 f3 79 0f 43 b8 0b d9 c4 b9 a9 41 0000020 2c cc 0c 17 d6 3d 7d b6 94 74 ce 4e e5 70 44 66 0000040 You will now be prompted to enter any valid LUKS passphrase in order to store the new TPM NVRAM secret in LUKS key slot 1: key slot 1 1 1 cryptsetup KEY_SLOT is 1 DEVICE is /dev/sda2 KEYFILE is /dev/shm/key and dumped: 0000000 0e 30 a6 ec 58 f3 79 0f 43 b8 0b d9 c4 b9 a9 41 0000020 2c cc 0c 17 d6 3d 7d b6 94 74 ce 4e e5 70 44 66 0000040 Enter any passphrase: Using NV index 9 for device /dev/sda2 ---------------------- Okay see I modified the script to spit out the LUKS secret that I presume was "massaged" with the PCRs list in tpm_nvdefine and tpm_nvwrite. The binary dumps are above. The problem is that I can alter menu.lst to add a checkfile. This changes PCR-12 So I do a reboot and I get something in PCR-13 but disturbingly my key-file on the tpm-nvread still worked and decrypted the /dev/sda2 partition! I could access my junk.dat file. I expected to not be able to get to my LUKS partition Why? ------------ root@crownbay-noemgd:/boot/grub# reboot The system is going down for reboot NOW!mgd (pts/0) (Thu Nov 21 01:40:21 2013 root@crownbay-noemgd:/boot/grub# Write failed: Broken pipe macbookpro-708c:Downloads billmartin$ !ssh ssh [email protected] [email protected]'s password: root@crownbay-noemgd:~# cat /sys/class/misc/tpm0/device/pcrs PCR-00: 87 6A 18 78 C5 43 62 C8 95 06 61 48 8E 60 23 49 F2 A0 89 11 PCR-01: 30 66 6A 4A C8 31 C0 12 ED E5 D7 EF B0 25 88 85 73 DE FC 07 PCR-02: 8A 06 1C B2 CF 13 39 7F A1 A2 28 A4 1F 31 1D 6A D0 92 2E 2F PCR-03: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75 PCR-04: 3D 80 D7 FE 65 8E 83 5D 58 E1 2F 97 F7 2A 71 3A C7 66 08 17 PCR-05: E5 1E B6 A9 F4 18 24 F6 3E C6 0A 44 23 7C 5C 21 16 B4 F9 91 PCR-06: 78 CD 77 59 86 6A 77 D0 31 03 C2 03 5B F7 DC 7E 61 DC 19 2E PCR-07: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75 PCR-08: E6 08 14 11 5E 11 FC 94 18 29 5B F9 43 8F 1F 03 F7 80 37 AA PCR-09: 94 D7 CA 5B D0 78 86 40 56 FC 47 19 68 AF 4F CC CE 4C 1C 67 PCR-10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-11: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-12: 44 AF 1D 83 74 2D F5 97 05 E6 6D 1D 2C 63 76 D5 6C CE 2E 8D PCR-13: 79 85 5C 47 87 93 72 67 DA D4 49 91 C7 0D AD F1 D6 A0 25 8C PCR-14: FE 9A BA 7C 51 BA E0 6A 65 A9 9E 0C BB 86 2D 49 BE 06 D4 F0 PCR-15: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-16: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-17: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF PCR-18: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF PCR-19: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF PCR-20: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF PCR-21: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF PCR-22: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF PCR-23: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 root@crownbay-noemgd:~# tpm-luks -o secretfs -d /dev/sda2 Enter your TPM NVRAM password for index 0x00000009: in luks_open tmpfs_keyfile is 0000000 0e 30 a6 ec 58 f3 79 0f 43 b8 0b d9 c4 b9 a9 41 0000020 2c cc 0c 17 d6 3d 7d b6 94 74 ce 4e e5 70 44 66 0000040 root@crownbay-noemgd:~# ls /dev/mapper/ control secretfs root@crownbay-noemgd:~# mount /dev/mapper/secretfs /mnt/thePartition/secretfs/ root@crownbay-noemgd:~# ls -lta /mnt/thePartition/secretfs/ total 145580 -rw-r--r-- 1 root root 148897792 Nov 21 01:31 junk.dat drwxr-xr-x 3 root root 4096 Nov 21 01:30 . drwxr-xr-x 3 root root 4096 Nov 21 01:29 .. drwx------ 2 root root 16384 Nov 21 01:28 lost+found ________________________________________ From: David Challener [[email protected]] Sent: Tuesday, November 26, 2013 7:36 AM To: Bill Martin Subject: Re: [TrouSerS-users] tpm-tool 1.3.9's tpm_nvdefine's parseNVPermsFile: Where are existing PCR readings verified prior to making the PCR composite? You code unfortunately doesn't use TSS commands, so it is hard to tell. Did you actually check the values that are in the PCRs to make sure they differ as they should? On Fri, Nov 22, 2013 at 1:53 PM, Bill Martin <[email protected]<mailto:[email protected]>> wrote: I posted a message to the users list yesterday regarding tpm-luks-init. I am using the latest tpm-tools 1.3.9, trousers 0.3.10, cryptsetup 1.6.2 and TrustedGRUB 1.1.5 I have a related question. This morning I used tpm_nvrelease to get rid of my tpm NVRAM index 9 key, changed my /etc/tpm-luks.conf to use index 2 instead of 9. Then redid my /dev/sda2 - randomized it. I started everything from scratch, starting with cryptsetup to luksFormat my /dev/sda2 My menu.lst has a checkfile command. This of course should affect PCR 13. My tpm-luks script left out the checkfile command line measurement (inadvertently). I know this is a TrustedGRUB stage2 built-in command, so TrustedGrub would extend the checkfile command into the hash. The problem is that tpm_nvdefine allowed the NV Permsfile (with the -f flag) to be used in the composite object regardless. Here is a block of code in the function parseNVPermsFile: if (rw == 'r') { if (*hPcrsRead == NULL_HPCRS) if (contextCreateObject(*hContext, TSS_OBJECT_TYPE_PCRS, TSS_PCRS_STRUCT_INFO_SHORT, hPcrsRead) != TSS_SUCCESS) goto out; if (pcrcompositeSetPcrValue(*hPcrsRead, pcr, pcrSize, (BYTE *)hash_bin) != TSS_SUCCESS) goto out; } else { if (*hPcrsWrite == NULL_HPCRS) if (contextCreateObject(*hContext, TSS_OBJECT_TYPE_PCRS, TSS_PCRS_STRUCT_INFO_SHORT, hPcrsWrite) != TSS_SUCCESS) goto out; if (pcrcompositeSetPcrValue(*hPcrsWrite, pcr, pcrSize, (BYTE *)hash_bin) != TSS_SUCCESS) goto out; } } Before the block of code above I expect a call to a function that will a) get the existing PCR for the current index read out of the pcr variable by calling tpmPcrRead() and b) verify the hash from the per list matches the hash read out of the PCR before allowing this if...else to continue and return an error in case no matching. Am I right or wrong? ------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk _______________________________________________ TrouSerS-users mailing list [email protected]<mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/trousers-users ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk _______________________________________________ TrouSerS-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/trousers-users
