tpm2-tss question
by Yasuhiro Hosoda
MY name is Yasuhiro Hosoda.
I am developing a program using TSS1.0(Nov１．2016).
I encountered a problem with PolicySecret error 0x98e and need help.
My program uses tpmtest.cpp as a base of development.
The situation is as follows:
1 Create TPM Keys like this.
EK
｜--------
｜ |
MK AK
｜
SK
2 Execute PolicySecret twice using HMAC session. At first, it ends
without error. Then it ends with 0x98e
For clarification, I print out the values of Virtual Handle and Real Handle.
The value of Virtual/Real Handles differ at 2nd excution of the command.
(See NO 25/26 Below)
I understand that the resource manager assigns Virtual Handle and my
program calculates HMAC using that handles.
On the other hand, TPM may calculate HMAC using Real Handle.
That is my hypothesis.
Any suggestion about the usage of Session Handle?
NO Command Virtual/Real Handle LOC
1. CreatePrimary(EK) real=80000000, virtual=80000000 8381
2. HierarchyChangeAuth1 8421
3. HierarchyChangeAuth2 8431
4. StartAuthSession(Policy) real=3000000, virtual=3000000 8480
5. PolicySecret(ENDORSEMENT) 8494
6. Create(MK) 8515
7. PolicySecret(ENDORSEMENT) 8529
8. Load(MK) real=80000001, virtual=80000001 8542
9. Evict(MK) 8552
10. Create(SK) 8590
11. Load(SK) real=80000001, virtual=80000002 8598
12. PolicySecret(ENDORSEMENT) 8609
13. Create(AK) 8635
14. PolicySecret(ENDORSEMENT) 8645
15. Load(AK) real=80000001, virtual=80000003 8655
16. FlushContext(POLICY) 8664
17. StartAuthSession(POLICY) real=3000000, virtual=3000000 8668
18. StartAuthSession(HMAC) real=2000001, virtual=2000001 8678
19. ComputeCommandHMAC(LoadExternal) real=80000000, virtual=80000004 3706
20. ComputeCommandHMAC(HMAC_Start) real=80000001, virtual=80000005 3706
21. PolicySecret(SK) 8711
22. FlushContext(HMAC) 8717
23. FlushContext(POLICY) 8724
24. CertifyCreation(SK) 8738
25. StartAuthSession(POLICY) real=3000000, virtual=3000001 8745
26. StartAuthSession(HMAC) real=2000001, virtual=2000000 8754
27. ComputeCommandHMAC(LoadExternal) real=80000000, virtual=80000005 8782
28. ComputeCommandHMAC(HMAC_Start) real=80000001, virtual=80000004 8782
29. PolicySecret(SK) 8789
The whole source program can be found here.
https://github.com/intel/tpm2-tss/files/1516612/tpmtest.cpp_0x98e_2.txt
Kind regards,
--
Yasuhiro Hosoda
NTT Electronics Corporation （NEL)
Security Support Project
2 years, 3 months
ESAPI StartAuthSession
by Davide Rutigliano
Hello everyone,
I'm in trouble with Esys_StartAuthSession because I receive continuously
this error and I cannot understand why:
"""
ERROR:esys_iutil:esapi/esapi_util/esys_iutil.c:879:esys_GetResourceObject()
Error: Esys handle does not exist (70018).
ERROR:esys:esapi/esapi/Esys_StartAuthSession.c:124:Esys_StartAuthSession()
Error in async function ErrorCode (0x00070018)
TPM2_StartAuthSession failed with 0x70018
"""
I suppose I'm doing something wrong with session handles but I don't know
what.
Could someone help me please?
Thanks in advance,
Davide Rutigliano.
2 years, 7 months
dlopen()'ing raw .so files considered bad
by Trevor Woerner
Hey everyone,
I was playing around with the latest tpm2 tools (i.e. the git master) and I
noticed that this code is now dlopen()'ing the libraries at runtime.
That's a very nice feature, but the way it's been implemented is not
entirely correct.
The filename parameter to dlopen() should be a library's SONAME, not the
raw .so file. The raw .so file is considered a -dev or -devel package
component, not a component of the library package itself. The raw .so
exists as a develop crutch, but shouldn't be used in production.
The raw .so will always point to the latest shared library object. But in
an ideal world, the shared library's API should be denoted by the first
number after ".so.". It would be extremely unlikely that the programs
linking to today's TSS (with its current API) would continue to work should
an API-breaking change occur in the future (thus requiring the first number
after ".so." to be incremented).
In other words, programs should dlopen() a specific API (e.g. ".so.0") and
not just "the latest" (i.e. ".so").
Please see https://lists.debian.org/debian-policy/2002/12/msg00041.html,
for example.
As is, this is going to mess up people packaging this software for various
distros, and users trying to use this software (since they'll have to
install the -dev packages for it to work, which can get messy for
non-developer users).
Thanks and best regards,
Trevor
2 years, 7 months
meta-measured updates
by Trevor Woerner
Hi Philip,
My hope is that one day the OE community will have one security layer to
choose, rather than the three that we have currently.
I've looked at the three different layers and feel that meta-secure-core might
be a better one to target. With respect to its TPM2 recipes, however,
meta-secure-core (and the other, meta-security) lag behind meta-measured. As
such I've been working on some updates for meta-secure-core.
Are you still keen to fold meta-measured into something else? If not I could
prepare a set of patches for meta-measured as well.
Looking at the master commit of tpm2-tss, specifically, I've noticed a number
of changes and was hoping for your feedback.
With the tss 1.x stuff we had:
- libtcti-device
- libtcti-socket
- libsapi
The new tss 2.x stuff has:
- libtss2-esys
- libtss2-mu
- libtss2-sys
- libtss2-tcti-device
- libtss2-tcti-mssim
I'm guessing libtss2-tcti-device is the new name for the old libtcti-device.
But are there any mappings from the new stuff to the older libtcti-socket and
libsapi?
It looks like things are going to get messy. It looks like, going forward,
we're going to need to keep tpm2-tss_1.x.bb around as well as create
tpm2-tss_2.x.bb recipes with differently named PACKAGES so existing recipes
that use tss (and expect the old 1.x behaviour/API) can continue to work while
allowing new code (or updates to the old) to use the new API (?).
Best regards,
Trevor
2 years, 7 months
RES: PCR missing SHA-512 support
by Ricardo Araújo
Hi Dan,
I've been using [1] with [2] as simulator for playing around with TPM 2.0 features, because I can wire it to QEMU and launch a VM with EDK2 UEFI. No precompiled packages for any of these.
So I was testing master version from both tpm2-tools and abrmd with the release candidates for tss and I noticed this error on tpm2_pcrlist after this commit [3] enabling SHA512 and I related to this thread...
I'm not sure yet if this is a simulator problem or something on tools/abrmd/tss side... for now I'll test with another version and hopefully come back with more info. From a noob perspective, the error seems to be the same at [4], maybe I should try the same trick and see what happens.
Ricardo
[1] - https://github.com/stefanberger/swtpm/tree/tpm2-preview.v2
[2] - https://github.com/stefanberger/libtpms/tree/tpm2-preview.rev146.v2
[3] - https://github.com/stefanberger/libtpms/commit/37f24d5c7b3513045abcc4a0d2...
[4] - https://github.com/tpm2-software/tpm2-tools/issues/1021
-----Mensagem original-----
De: Anderson, Daniel [mailto:daniel.anderson@intel.com]
Enviada em: quinta-feira, 24 de maio de 2018 18:02
Para: Ricardo Araújo <ricardo(a)lsd.ufcg.edu.br>
Cc: tpm2(a)lists.01.org
Assunto: RE: [tpm2] PCR missing SHA-512 support
Ricardo,
No I have not seen that before.
This is just a hunch. But I suspect that the code needs to be recompiled
with your simulator (or real TPM).
Some more information would be useful--does your TPM (real or virtual or
simulated) have a SHA-512 PCR bank?
Did you compile it on the same machine? Or did you compile elsewhere or use
a precompiled package or something like that?
Dan
From: Ricardo Araújo [mailto:ricardo@lsd.ufcg.edu.br]
> Not sure it is the same simulator, but I'm using
> https://github.com/stefanberger/libtpms/tree/tpm2-preview.rev146.v2 and
> after SHA-512 was enabled (yesterday) tpm2_pcrlist is crashing with this
> error:
> WARNING:marshal:src/tss2-mu/tpml-types.c:197:Tss2_MU_TPML_PCR_SELECTION_Unmarshal()
> count too big
> ERROR: Tss2_Sys_GetCapability(0x80011) - sys:Response is malformed
2 years, 8 months
signed kernel auth policy
by Briggs, Kevin 1
I've got more of a spec/capability question than a tool specific question. With TPM2.0 and the new Extended Authorization (EA) stuff, I've been reading things like: "Policy authorization, also known as Extended Authorization (EA), is the Swiss army knife of TPM authorizations. With the right expertise, you can do just about any kind of authorization with it." - A Practical Guide to TPM2.0, pg. 207.
So this got me wondering if it would be possible to create an authorization that relies on some external data being signed, and that signature being verified by the TPM with a loaded public key. More specifically, is it possible to tie some TPM protected secret to this signature verification result? The example I'm thinking is:
Let's say I want the TPM to only allow reading of an NV secret if a system booted a signed kernel, and I want the secret to be releasable on any kernel signed by the correct key. I have seen Microsoft's TrEE EFI protocol and according to mjg59's blog post on the subject maybe this is exactly what I'm after, and I understand that booting signed kernels is already within the realm of Secure Boot but hey, this still seems like a useful exercise to think about with regards to TPM and maybe could be used on systems that don't have UEFI or don't boot with Secure Boot, but can use the TPM2.0.
I guess a simple way to do this might be to verify the signature with software prior to GRUB loading the kernel, and just ensure that GRUB module, configuration, and public key get hashed and tie a secret to those. Maybe that's what I should be pursuing, but I'm just wondering if the TPM itself can do the verification.
So this seems like it would need:
* TPM support for a signature verification command that ultimately modifies a policy digest based only on whether the signature verified correctly or not.
* A grub module to do this verification prior to loading the kernel
* The grub module and configuration itself probably needs to be measured if it isn't already (PCR 5?), and the measurement needs to be included in the policy so that someone can't just replace the module and verify the signature but boot a different kernel...
According to the specs, we have TPM2_VerifySignature. It's not a policy command, so I don't think I can use it in a policy, but it does return a TPMT_TK_VERIFIED ticket. The TPMT_TK_VERIFIED is only consumed by TPM2_PolicyAuthorize, but I'm not trying to authorize a new policy here.
And then there is TPM2_PolicyTicket, which looks like it updates the policy digest based on whether a ticket checks out, but looking closer at the command definition, it takes in a TPMT_TK_AUTH ticket, not a TPMT_TK_VERIFIED ticket, and it looks like that kind of ticket is only produced by TPM2_PolicySigned and TPM2_PolicySecret, which seem to be for authorizing specific commands and their parameters by signing them.
So maybe I'm misunderstanding or skipping over something, but am I correct in thinking the TPM commands defined in the spec may not be able to do this, even with EA? And if so, is there any roadblock or flaw in doing the verification with software by GRUB prior to loading the kernel?
2 years, 8 months
PCR missing SHA-512 support
by Anderson, Daniel
I was playing around with tpm2_pcrlist and noticed it supports SHA-1, SHA-256, SHA-384, but SHA-512 is missing:
tumalo ~/tpm/bin$ tpm2_pcrlist -L sha512:22
WARN: Ignore unsupported bank/algorithm: sha512(0x000d)
ERROR: Unable to run tpm2_pcrlist
tumalo ~/tpm/bin$ tpm2_pcrlist -L sha384:22
sha384:
22: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Then I look in the man page and see SHA-512 is supported.
Is this a bug or a feature?
There's also bugs in the man page example, but I will fix that separately.
Dan
2 years, 8 months
Re: [tpm2] Documentation for configure
by Anderson, Daniel
I suggested some documentation on this, but it was pointed out to me that these are rarely-used options and that the documentation is available from here:
./bootstrap; ./configure --help
But to answer your question, configure --enable-tcti-mssim allows use of the Microsoft/IBM TPM 2.0 simulator and
Configure --enable-tcti-device allows use of the real TPM 2.0 (including virtual or firmware TPMs) through the /dev/tpm0 device driver.
Having both enabled is the default and is useful unless you want to do a lot of minimization or something.
If you care, here's the options I use in a testing environment:
./configure --enable-unit --enable-integration --enable-doxygen-doc
Dan
$ ./configure --help
`configure' configures tpm2-tss 2.0.0_rc1 to adapt to many kinds of systems.
Usage: ./configure [OPTION]... [VAR=VALUE]...
. . .
Optional Features:
--disable-option-checking ignore unrecognized --enable/--with options
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]
--enable-shared[=PKGS] build shared libraries [default=yes]
--enable-static[=PKGS] build static libraries [default=yes]
--enable-fast-install[=PKGS]
optimize for fast installation [default=yes]
--disable-libtool-lock avoid locking (might break parallel builds)
--enable-dependency-tracking
do not reject slow dependency extractors
--disable-dependency-tracking
speeds up one-time build
--enable-silent-rules less verbose build output (undo: "make V=1")
--disable-silent-rules verbose build output (undo: "make V=0")
--enable-unit build cmocka unit tests (default is no)
--enable-esapi build the esapi layer (default is yes)
--enable-tcti-device build the tcti-device module (default is yes)
--enable-tcti-mssim build the tcti-mssim module (default is yes)
--enable-integration build and execute integration tests (default is no)
--enable-ld-version-script
enable linker version script (default is enabled when possible)
--enable-debug build with debug info (default is no)
--disable-doxygen-doc don't generate any doxygen documentation
--enable-doxygen-dot generate graphics for doxygen documentation
--disable-doxygen-man don't generate doxygen manual pages
--enable-doxygen-rtf generate doxygen RTF documentation
--enable-doxygen-xml generate doxygen XML documentation
--enable-doxygen-chm generate doxygen compressed HTML help documentation
--enable-doxygen-chi generate doxygen separate compressed HTML help index file
--disable-doxygen-html don't generate doxygen plain HTML documentation
--enable-doxygen-ps generate doxygen PostScript documentation
--enable-doxygen-pdf generate doxygen PDF documentation
--enable-code-coverage Whether to enable code coverage support
Optional Packages:
--with-PACKAGE[=ARG] use PACKAGE [ARG=yes]
--without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
--with-pic[=PKGS] try to use only PIC/non-PIC objects [default=use
both]
--with-aix-soname=aix|svr4|both
shared library versioning (aka "SONAME") variant to
provide on AIX, [default=aix].
--with-gnu-ld assume the C compiler uses GNU ld [default=no]
--with-sysroot[=DIR] Search for dependent libraries within DIR (or the
compiler's sysroot if not specified).
--with-tctidefaultmodule
The default TCTI module for ESAPI. (Default:
libtss2-tcti-default.so
--with-tctidefaultconfig
The default tcti module's configuration.
--with-udevrulesdir=DIR udev rules directory
--with-udevrulesprefix=XY
prefix for udev rules file
--with-maxloglevel={none,error,warning,info,debug,trace}
sets the maximum log level (default is trace)
--with-gcov=GCOV use given GCOV for coverage (GCOV=gcov).
Some influential environment variables:
. . .
2 years, 8 months
