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.
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.
NTT Electronics Corporation （NEL)
Security Support Project
Author: Carlos Santos <casantos(a)datacom.ind.br>
Date: 2018-01-30 (Tue, 30 Jan 2018)
Fix build with LibreSSL
OPENSSL_VERSION_NUMBER is used to test the version of OpenSSL but this
test alone breaks the build with LibreSSL due to implicit declarations
of functions 'RSA_set0_key' and 'HMAC_CTX_free'.
Test if OpenSSL < 1.1.0 or LIBRESSL_VERSION_NUMBER is defined, instead.
Signed-off-by: Carlos Santos <casantos(a)datacom.ind.br>
Last week we migrated to the new tpm2-software github organization without too much hassle. We've migrated our infrastructure / CI as well but coveralls is being problematic (thanks to Peter for pointing out the initial problem). I've created an issue in the tpm2-tss tracker here:
and reported the issue to coveralls / lemurheavy here:
Hopefully we'll hear back from them with a work-around but I'm not very optimistic based on the small bit of research I've done: this issue has been seen by others:
and their work around was to abandon coveralls and use codecov instead:
I'd like to keep from switching services like this but we may not have a choice. I'll keep the issue tracker up to date as we triage this issue and will update this thread with links to new issues if we have problems in the other repos.
Thanks for your patience,
Hello tpm2 list,
No doubt you all have noticed the increasing churn in our source tree
over the last few weeks. We’ve added some much needed features like the
new TCTI initialization mechanism that we’re now working to standardize
as well as the re-write of our logging infrastructure thanks to a
generous contribution from @AndreasFuchsSIT. In the run up to our next
major release that we’re planning for “around March” you can expect
additional churn much of which will *not* be backward compatible.
In an attempt to keep all affected parties informed we’ve been laying
out our planned work in the per-repo Github issue trackers. We’re
organizing related tasks / issue into ‘milestones’ and aligning the
milestones with our planned releases. The milestones currently scheduled
for our 2.0 release all have the ‘due-date’ field set accordingly:
https://github.com/intel/tpm2-tss/milestones. Similar milestones have
been created for the tpm2-tools and tpm2-abrmd for the same purpose.
Finally, we’ve established a new Github organization dedicated to the
tss2 effort and will be migrating the 3 repos to it over the next few
days. The purpose of this new org is to foster the continued growth of
this fledgling project and to encourage wider engagement with the community.
The migration to this new org should be completed in the next few days.
Happy new year,
Author: Jia Zhang <zhang.jia(a)linux.alibaba.com>
Date: 2018-01-24 (Wed, 24 Jan 2018)
tpm2_errata: mute the noises when more data is available
Infineon SLB9665 (PT_REV 1.16) is affected by the errata
"Sign/decrypt attribute encoding" and the related test case thus
needs -Z option.
However, the test cases print lots of noises about more-data-available
because this tpm chip always responds more data available when the
requesting property is PT_FIXED. Digging into the internal, PT_VAR is
implied as the potentially available data.
More worse, launching test.sh -Z causes each test case generating the
The errata logic only requires the first few fields from PT_FIXED so
the check for more_data can be ignored in order to mute the noises
when the errata is applied.
Signed-off-by: Jia Zhang <zhang.jia(a)linux.alibaba.com>