Re: [tpm2] tpm2 Digest, Vol 19, Issue 12
by Desai, Imran
Yes, EK is also a primary key under endorsement hierarchy. However, the attributes and authpolicy required for the endorsement key to be certified by the TPM manufacturer are distinct and are per TCG specification. You can read the attributes and authpolicy with readpublic tool and compare. This uniqueness justifies the special case/ tool for the unique primary object under endorsement hierarchy.
On 1/31/19, 1:00 PM, "tpm2 on behalf of tpm2-request(a)lists.01.org" <tpm2-bounces(a)lists.01.org on behalf of tpm2-request(a)lists.01.org> wrote:
Send tpm2 mailing list submissions to
tpm2(a)lists.01.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/tpm2
or, via email, send a message with subject or body 'help' to
tpm2-request(a)lists.01.org
You can reach the person managing the list at
tpm2-owner(a)lists.01.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of tpm2 digest..."
Today's Topics:
1. [tpm2-tools] Question about generating EK (Jordan Hand)
----------------------------------------------------------------------
Message: 1
Date: Wed, 30 Jan 2019 18:17:39 -0800
From: Jordan Hand <jordanhand22(a)gmail.com>
To: tpm2(a)lists.01.org
Subject: [tpm2] [tpm2-tools] Question about generating EK
Message-ID:
<CAEjdKLUTWj6BjJQkFF=Oonf=Lk17vrit+KXXfOpkNsBKLAkL6g(a)mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Why do the two following commands generate different RSA keypairs?
1. tpm2_createek -G rsa -c -
2. tpm2_createprimary -a e -g sha256 -G rsa
As I understand it, generating a primary key under the endorsement
hierarchy using the same algorithm should product the same key. This is
because the same seed is used to generate both keys with the same
parameters. Am I missing something about how the TPM generates these keys?
Thanks,
Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.01.org/pipermail/tpm2/attachments/20190130/b1c7aafd/attachme...>
------------------------------
Subject: Digest Footer
_______________________________________________
tpm2 mailing list
tpm2(a)lists.01.org
https://lists.01.org/mailman/listinfo/tpm2
------------------------------
End of tpm2 Digest, Vol 19, Issue 12
************************************
1 year
[tpm2-tools] Question about generating EK
by Jordan Hand
Why do the two following commands generate different RSA keypairs?
1. tpm2_createek -G rsa -c -
2. tpm2_createprimary -a e -g sha256 -G rsa
As I understand it, generating a primary key under the endorsement
hierarchy using the same algorithm should product the same key. This is
because the same seed is used to generate both keys with the same
parameters. Am I missing something about how the TPM generates these keys?
Thanks,
Jordan
1 year
tpm2-tss 2.2.0-rc2
by Tadeusz Struk
Hello,
An updated release candidate for tpm2-tss 2.2.0 is out. It can be found here:
https://github.com/tpm2-software/tpm2-tss/releases/tag/2.2.0_rc2
All changes and fixed issues are listed in the CHAGNELOG.md file.
Please give it some testing. Any feedback is appreciated.
Changes since 2.2.0_rc1:
- build: add doxygen.dox to distribution
- build: remove Gnulib dependency
Thanks,
--
Tadeusz
1 year
Issues experimenting with tpm2-tools and keyctl trusted keys
by Thibaut Sautereau
Hello folks,
I'm experimenting with TPM 2.0 (using swtpm 0.1.0), tpm2-tools 3.1.3,
tpm2-tss 2.1.0 and the Linux 4.19.16 kernel's trusted keys. I found this
thread [1] about the "policydigest" and "policyhandle" options added to
keyctl but I cannot reproduce the given example [2] using tpm2-tools
instead of the author's Python testing scripts [3]. I wonder if I do
something wrong by executing the following commands:
export TPM2TOOLS_TCTI="device:/dev/tpmrm0"
tpm2_takeownership --clear
# I tried fiddling with the object attributes in the following command
# but AIUI the default ones should be OK
tpm2_createprimary --hierarchy=o --halg=sha256 --kalg=rsa \
--context=/tmp/primary.context
tpm2_evictcontrol --auth=o --context=/tmp/primary.context \
--handle=0x80ffffff --persistent=0x81010001
tpm2_createpolicy --policy-file=/tmp/policy.digest --policy-pcr \
--set-list=sha256:0 --policy-digest-alg=sha256
policydigest=$(xxd -p /tmp/policy.digest | tr -d '\n')
keyid=$(keyctl add trusted test \
"new 32 keyhandle=0x81010001 hash=sha256 policydigest=$policydigest" @u)
keyctl link @us @s
keyctl pipe $keyid > /tmp/blob.hex
Until here, everything works fine.
Now for testing I want to reimport the key from the blob file, but I
need a handle to a TPM_SE_POLICY and thus need to directly use the TPM
device, as the in-kernel resource manager I was using so far would
prevent me from keeping a policy session "opened". So I re-export
TPM2TOOLS_TCTI just as Javier Martinez Canillas showed on GitHub [4]:
export TPM2TOOLS_TCTI="device:/dev/tpm0"
# --auth-policy-session implies --extend-policy-session
tpm2_createpolicy --policy-pcr --set-list=sha256:0 \
--policy-digest-alg=sha256 --auth-policy-session
keyctl add trusted test2 \
"load $(cat /tmp/blob.hex) keyhandle=0x81010001 policyhandle=0x03000000" @u
This last command causes: "add_key: Operation not permitted".
In kernel logs, I have:
[ 1350.287556] tpm tpm0: A TPM error (2466) occurred unsealing
[ 1350.289856] trusted_key: key_unseal failed (-1)
The TPM error is 0x9a2, i.e. TPM2_RC_BAD_AUTH. I cannot see what I'm
doing wrong. Do you see something obvious?
[1] https://lkml.org/lkml/2015/11/17/520
[2] https://lkml.org/lkml/2015/11/21/125
[3] https://github.com/jsakkine-intel/tpm2-scripts
[4] https://github.com/tpm2-software/tpm2-tools/issues/510#issuecomment-33138...
Thanks a lot for your time and your work!
--
Thibaut Sautereau
CLIP OS developper
1 year
Re: [tpm2] [tpm2-software/tpm2-tools] NV write/read with authorized policy (#1281)
by Roberts, William C
+tpm2 mailing list. In the future direct questions there.
> -----Original Message-----
> From: Kai Che [mailto:notifications@github.com]
> Sent: Wednesday, January 16, 2019 8:00 AM
> To: tpm2-software/tpm2-tools <tpm2-tools(a)noreply.github.com>
> Cc: Subscribed <subscribed(a)noreply.github.com>
> Subject: [tpm2-software/tpm2-tools] NV write/read with authorized policy
> (#1281)
>
> Hello everyone,
>
> I'm trying to write/read a NV area which was defined with a policy output from
> tpm2_policyauthorize:
I'm assuming you're setup steps would be here and you're just showing the attempt
To define a new space with the policy.
> tpm2_policyauthorize -S session.ctx -o authorized.policy -f pcr.policy -n signing_key.name
> tpm2_nvdefine -x 0x1500001 -a 0x40000001 -s 32 -t "policyread|policywrite" -L authorized.policy
> tpm2_nvread -x 0x1500001 -s 32 -L sha256:8 -o 0
On master, I am seeing no way to pass the authorizing session context to tpm2_nvread. The options to
NV read for PCR policy satisfaction are all internal, and quite limited in support.
You really would want something like:
tpm2_nvread -p session=session.ctx <args|opts>
This way the first handle of the sessions array can be specified.
You also need tpm2-abrmd and not /dev/tpm0 or /dev/tpmrm0 as extended sessions (ie
Session blobs between tool invocations) is an abrmd only feature.
Sorry this support is not there currently, but it's on the roadmap for 2019. My major goal for the 2019
Release is to have:
1. proper session/password support. Each part of the session array should be specifiable.
2. HMAC passwords
3. Consistent options (command line interface will freeze at 4.0)
> ERROR: Failed to read NVRAM area at index 0x1500001
> ERROR: Tss2_Sys_NV_Read(0x99D) - tpm:session(1):a policy check failed
> ERROR: Unable to run tpm2_nvread
>
> Write/read with a "normal" PCR policy is working fine with the proper PCR values:
> tpm2_nvdefine -x 0x1500001 -a 0x40000001 -s 32 -t "policyread|policywrite" -L
> pcr.policy
>
> How can I access the NV area with an authorized policy?
>
> Thanks and best regards,
>
> Kai
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub <https://github.com/tpm2-
> software/tpm2-tools/issues/1281> , or mute the thread
> <https://github.com/notifications/unsubscribe-
> auth/AQ7bB6hC0v0CWNUvFQmwwZ6D4feE2w_Fks5vD0yEgaJpZM4aDY32> .
> <https://github.com/notifications/beacon/AQ7bB_1Kg32-
> 17tEQAoXM8S8E0yOROGeks5vD0yEgaJpZM4aDY32.gif>
1 year, 1 month
Re: [tpm2] Need help in understanding tpm2_makecredential command
by Dhawale, Dinkar
+ Adding alias
_____________________________________________
From: Dhawale, Dinkar
Sent: Tuesday, January 8, 2019 12:13 AM
To: Roberts, William C <william.c.roberts(a)intel.com<mailto:william.c.roberts@intel.com>>; Rawat, Arvind <arvind.rawat(a)intel.com<mailto:arvind.rawat@intel.com>>
Cc: Ghosh, Arijit <arijit.ghosh(a)intel.com<mailto:arijit.ghosh@intel.com>>
Subject: RE: Need help in understanding tpm2_makecredential command
Hi William,
We fixed following after parsing last 256 bytes for Endorsement Key Modulus from tpm2_readpublic. However, we have landed in strange issue. We have java implementation of tpm2_makecredentials in our code as it is done on Attestation Server (which can be installed on VM).
This implementation needed few output formatting changes as per new format of tpm2_activatecredentials. We did those changes and these were working fine on Purley server. However, same changes are not working on Simics server. Simics server crashes while activating credentials and we get following exception on console,
ASSERTION ERROR: Key is too large.
D:\mp\builds\4653165\simics-base\src\extensions\crypto-engine\backends/openssl-wrap.c:599:
Simics core build 5189
Module: Fri Nov 09 13:14:08 2018
Please report this.
#0 0x000000006a87fad0 (C:\PROGRA~1\Simics\SIMICS~1\SIMICS~1.165\win64\bin\libsimics-common.dll + 0x3fad0)
The simulation state has been corrupted. Simulation cannot continue.
Please restart Simics.
Surprisingly, we did not face this issue when we used tpm2_makecredentials commands itself. Could you please review our attached implementation (from line no 100)? and let us know if we need to make any changes with upgraded tpm2 tools.
<< File: Tpm2.java >>
Thanks,
-Dinkar
-----Original Message-----
From: Roberts, William C
Sent: Monday, December 31, 2018 9:01 PM
To: Rawat, Arvind <arvind.rawat(a)intel.com<mailto:arvind.rawat@intel.com>>
Cc: Dhawale, Dinkar <dinkar.dhawale(a)intel.com<mailto:dinkar.dhawale@intel.com>>; Ghosh, Arijit <arijit.ghosh(a)intel.com<mailto:arijit.ghosh@intel.com>>
Subject: RE: Need help in understanding tpm2_makecredential command
>From what I understand, this TPM2_MakeCredential is a convenience function that can be done externally from the TPM as described in section 24 of:
https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-1-A...
The only other thing I could think of making something end up at size 256 is:
1. The key length of an RSA2048 key (as you pointed out, modulus size) 2. The name-algorithm as part of the KDFa routine to generate the symmetric key.
We use sha256 as the default name algorithm in all places (if we don't that's a bug).
Bill
> -----Original Message-----
> From: Rawat, Arvind
> Sent: Friday, December 28, 2018 8:21 AM
> To: Roberts, William C <william.c.roberts(a)intel.com<mailto:william.c.roberts@intel.com>>
> Cc: Dhawale, Dinkar <dinkar.dhawale(a)intel.com<mailto:dinkar.dhawale@intel.com>>; Ghosh, Arijit
> <arijit.ghosh(a)intel.com<mailto:arijit.ghosh@intel.com>>
> Subject: Need help in understanding tpm2_makecredential command
>
> Hi William,
>
>
>
> I was trying to code a software implementation of tpm2_makecredential
> command. From what I understood by looking at the tpm2_makecredential
> code under tpm2-tools, I think that the command is performing RSA
> encryption on random data and generating an encrypted secret along
> with a credential blob with a 8 byte header appended at the beginning.
> I tried to do the same in my software implementation as well. I am
> using the same set of input in my implementation as used by tpm2_makecredentail command from tpm2-tools.
>
>
>
> However, I found that the output generated from my implementation and
> tpm2- tools implementation are different. I tried comparing the hex
> bytes of the two output blobs and I found that the encrypted secret
> part is different in the two blobs. With tpm2-tools implementation, I
> am getting encrypted secret of size 256 bytes, whereas with my
> implementation, the encrypted secret size is coming as
> 316 bytes. I did some research on the RSA encryption and found that
> the encrypted secret size depends on the modulus size. If a key
> modulus is 256 bytes in size, then it will generate 256 bytes
> encrypted secret no matter what the input data size is.
>
>
>
> Based on the above research, I tried to found the modulus size of EK
> public key which is passed as an input to tpm2_makecredential command,
> and found that the modulus size is 316 bytes. Hence, I am getting
> encrypted secret of size 316 bytes with my implementation. But my
> question is, since I am passing same EK public key to tpm2-tools
> implementation as well, then how come there the encrypted secret is
> getting generated of size 256 bytes. Ideally it should also be of
> 316 bytes. Can you tell me what additional thing the tpm2-tools
> implementation of tpm2_makecredential command is doing other than RSA
> encryption that is causing the encrypted secret size to be of 256 bytes instead of 316 bytes.
>
>
>
> I am using tpm2-tools version 3.0.4 with tpm2-abrmd service.
>
>
>
> Thanks,
>
> Arvind
1 year, 1 month
