Assess the support of encryption and hash algorithms that libtpms could still enable and in which distros they are supported.

The original TCG code caused an out-of-bounds access to the sieveMark array at index 5 due to next taking on values that it should not. A fix has been applied to the code but we should wait for an official fix of the issue before making another release.

Describe the bug
When running tpm2_createprimary on swtpm with libtpms 0.7.4 to generate an RSA-2048 key, the modulus of the key always contains many zeros in its high bits. By extracting the prime factors from file holding the persistent TPM state, they always have 32 bits set to zero. For example:

• Modulus n = 0xc8f8f77a0000bacc2f18e6a43f600d9990b9079654f85b23da5b26896a7cab24d52ea3dcae0bc754b2cf0aefd3ac036459d4a2bd1ec1c25d56f7822a633c1bd29ad54f4ec7a7e3e8d64697c737283c4b77ec01c9eb0dd36371dfb7fd160b1b6f946db24f0eda15997e488f7427c87f173d5d3baecf98d0d6832a97d28c3da99835cf22a83c39d6dd61f880422541b80d958a0f8756f804a65571c7937768717648deb6f8ccc8343a42a2b672ecd4e523f0ded37822db4b1af769416e4dcdb3d55ad4c7b78f47904a47f1418bc59295c2b2a6e2ea9f3c40caaf1f23a79ed18aab4bfb9754676b47759e705d5ab1ba8fd96be01ac7e475485a4577e105d6dc5e4f
• First prime number p = 0xdd7500000000a998d562fd94dd501fbaedbd693474333472bab4a5889a021b5ae79d4bf98c87d2509831103be119297abdc09e315a66bf1918a2d27a19ed805b01ea87f01e433c14bb6dde779bb70de6878b0697b9f2d1b064fe48bd06c83d11d3170d99a7f1637d2c10f0e00a0f04bd21ce3e02a2fa8803fd8fe5d9512b60b9
• Second prime number q = 0x0xe8520000000026049bfad92bbdea021f996acd0c55557fd42d16acb73fbd94cd908a636fc5da4e635707f7aa1e2f3041f144755520094b6ac322dfd57f5f3b98b679725a7bd33373fd67a11f2d51bbef4cf486bf60db2c89093bfcbc229f640be853f04d98b27aa0b5a613d5edd4350d8c90e7189a4097f0703f4f88f0556347

(Observe the eight 0 hexdigits after the 4 first hexdigits of the prime numbers).

This is due to a bug in function RsaAdjustPrimeCandidate

The issue is that on 64-bit systems, MASK is not 0x0000ffffffffffff but 0x000000000000ffff when RADIX_BITS is 64, so only the 16 lowest bits of *msw are kept instead of the 48 lowest bits. More precisely, in #define MASK (MAX_CRYPT_UWORD >> (RADIX_BITS - 16)), the shift operand should have been 16.

This bug is present in TCG specification (https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-4-Supporting-Routines-01.38-code.pdf section 10.2.15.7 AdjustPrimeCandiate()). This specification was updated and the current version does not have this bug (https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part4_SuppRoutines_code_pub.pdf section 10.2.14.1.6 AdjustPrimeCandiate()). This new version was implemented in April 2020 in 625171b (branch master) but no release of libtpms includes the new version yet.

Therefore I have three questions:

• Could RsaAdjustPrimeCandidate be fixed in branch stable-0.7.0 so that generating new RSA keys do not use prime numbers with many zeros, on 64-bit systems?
• If no, could a comment be added which clearly state that this prime number generator generates prime numbers that have 32 bits always set to zero and that the TCG already fixed this issue in a newer version of "Trusted Platform Module Library Family "2.0" Specification - Part 4: Routines - Code"?
• When will the next release of libtpms (version 0.8?) occur?

To Reproduce
Steps to reproduce the behavior:

1. On Arch Linux on an x86-64 system, install swtpm, tpm2-tools and tpm2-abrmd.
2. Launch swtpm in TPM2-mode and tpm2-abrmd, for example with:

swtpm socket --tpm2 --server port=2321 --daemon --ctrl type=tcp,port=2322 --flags not-need-init --tpmstate dir=/tmp
tpm2-abrmd --allow-root --tcti swtpm:host=127.0.0.1,port=2321

3. Generate a persistent RSA key on the software TPM, for example with:

export TPM2TOOLS_TCTI=tabrmd:bus_type=system
tpm2_createprimary -c /tmp/context.out -g sha256 -G rsa
tpm2_evictcontrol -c /tmp/context.out 0x81000001

4. Analyze the content of /tmp/tpm2-00.permall to retrieve the modulus and the prime numbers of the generated RSA key.

Expected behavior
tpm2_createprimary should create an RSA key with prime numbers which really look random, instead of with 32 bits always set to zero.

Desktop (please complete the following information):

• OS: Arch Linux on an x86-64 CPU (64-bit system)

Versions of relevant components

• libtpms: 0.7.4
• swtpm: 0.5.2

Describe the bug

OpenSSL 3.x builds may require that a host admin enable legacy mode on the host so that applications can use SHA1 in relation to signatures. It's not currently clear whether this eliminates SHA1 entirely or only for signature creation or also for signature verification.

Due to upgradeability of libtpms state SHA1 cannot be disabled in libtpms.

Reference: Discussion here: https://bugzilla.redhat.com/show_bug.cgi?id=2061607

There are some concerns regarding implementation of crypto functions in libtpms in order to get FIPS compliancy.

Most of the crypto functions in libtpms come from the specification
https://trustedcomputinggroup.org/specifications-public-review/

and use openssl.

However, some crypto algorithm are open-coded, or use outdated openssl functions where better alternatives exist.

We need to identify those functions and provide alternatives when possible.
Since the code comes from the specification, we will have to discuss how the code changes can be integrated to the specification, before or after they are changed in libtpms etc.

libtpms fails to build with openssl 3.0 (https://wiki.openssl.org/index.php/OpenSSL_3.0).

Porting the code to support 3.0 would help with FIPS compliancy.

However, since a lot of code is imported from the specification, afaik, how do we tackle this? How can we share the work?

Hi stefanberger,

Are SM2/3/4 algorithms supported in libtpms and swtpm? If not, what's the best way to implement SM2/3/4 in libtpms and swtpm?

thanks!

$ ./autogen.sh --with-tpm2 --with-openssl --prefix=/usr
......
$ make all
......
Making all in src
make[2]: Entering directory '/home/bigfoot/libtpms-0.6.0/src'
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -include tpm_library_conf.h -I../include/libtpms -fstack-protector-strong -D_POSIX_ -DTPM_POSIX -DTPM_LIBTPMS_CALLBACKS -I ./tpm2 -I ./tpm2/crypto -I ./tpm2/crypto/openssl -g -O2 -Wall -Werror -Wreturn-type -Wsign-compare -Wno-self-assign -MT tpm2/crypto/openssl/libtpms_tpm2_la-TpmToOsslMath.lo -MD -MP -MF tpm2/crypto/openssl/.deps/libtpms_tpm2_la-TpmToOsslMath.Tpo -c -o tpm2/crypto/openssl/libtpms_tpm2_la-TpmToOsslMath.lo test -f 'tpm2/crypto/openssl/TpmToOsslMath.c' || echo './'tpm2/crypto/openssl/TpmToOsslMath.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -include tpm_library_conf.h -I../include/libtpms -fstack-protector-strong -D_POSIX_ -DTPM_POSIX -DTPM_LIBTPMS_CALLBACKS -I ./tpm2 -I ./tpm2/crypto -I ./tpm2/crypto/openssl -g -O2 -Wall -Werror -Wreturn-type -Wsign-compare -Wno-self-assign -MT tpm2/crypto/openssl/libtpms_tpm2_la-TpmToOsslMath.lo -MD -MP -MF tpm2/crypto/openssl/.deps/libtpms_tpm2_la-TpmToOsslMath.Tpo -c tpm2/crypto/openssl/TpmToOsslMath.c -fPIC -DPIC -o tpm2/crypto/openssl/.libs/libtpms_tpm2_la-TpmToOsslMath.o
tpm2/crypto/openssl/TpmToOsslMath.c: In function ‘PointFromOssl’:
tpm2/crypto/openssl/TpmToOsslMath.c:431:5: error: ‘EC_POINT_get_affine_coordinates_GFp’ is deprecated [-Werror=deprecated-declarations]
OK = EC_POINT_get_affine_coordinates_GFp(E->G, pIn, x, y, E->CTX);
^~
In file included from /usr/local/include/openssl/opensslv.h:124,
from /usr/local/include/openssl/opensslconf.h:13,
from /usr/local/include/openssl/e_os2.h:13,
from /usr/local/include/openssl/bn.h:14,
from ./tpm2/Implementation.h:188,
from ./tpm2/Tpm.h:66,
from tpm2/crypto/openssl/TpmToOsslMath.c:72:
/usr/local/include/openssl/ec.h:543:1: note: declared here
DEPRECATEDIN_3(int EC_POINT_get_affine_coordinates_GFp(const EC_GROUP *group,
^~~~~~~~~~~~~~
tpm2/crypto/openssl/TpmToOsslMath.c: In function ‘EcPointInitialized’:
tpm2/crypto/openssl/TpmToOsslMath.c:457:2: error: ‘EC_POINT_set_affine_coordinates_GFp’ is deprecated [-Werror=deprecated-declarations]
EC_POINT_set_affine_coordinates_GFp(E->G, P, bnX, bnY, E->CTX);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/local/include/openssl/opensslv.h:124,
from /usr/local/include/openssl/opensslconf.h:13,
from /usr/local/include/openssl/e_os2.h:13,
from /usr/local/include/openssl/bn.h:14,
from ./tpm2/Implementation.h:188,
from ./tpm2/Tpm.h:66,
from tpm2/crypto/openssl/TpmToOsslMath.c:72:
/usr/local/include/openssl/ec.h:528:1: note: declared here
DEPRECATEDIN_3(int EC_POINT_set_affine_coordinates_GFp(const EC_GROUP *group,
^~~~~~~~~~~~~~
tpm2/crypto/openssl/TpmToOsslMath.c: In function ‘BnCurveInitialize’:
tpm2/crypto/openssl/TpmToOsslMath.c:497:3: error: ‘EC_POINT_set_affine_coordinates_GFp’ is deprecated [-Werror=deprecated-declarations]
&& EC_POINT_set_affine_coordinates_GFp(group, P, bnX, bnY, CTX);
^~
In file included from /usr/local/include/openssl/opensslv.h:124,
from /usr/local/include/openssl/opensslconf.h:13,
from /usr/local/include/openssl/e_os2.h:13,
from /usr/local/include/openssl/bn.h:14,
from ./tpm2/Implementation.h:188,
from ./tpm2/Tpm.h:66,
from tpm2/crypto/openssl/TpmToOsslMath.c:72:
/usr/local/include/openssl/ec.h:528:1: note: declared here
DEPRECATEDIN_3(int EC_POINT_set_affine_coordinates_GFp(const EC_GROUP *group,
^~~~~~~~~~~~~~
tpm2/crypto/openssl/TpmToOsslMath.c: At top level:
cc1: error: unrecognized command line option ‘-Wno-self-assign’ [-Werror]
cc1: all warnings being treated as errors
make[2]: *** [Makefile:2861: tpm2/crypto/openssl/libtpms_tpm2_la-TpmToOsslMath.lo] Error 1
make[2]: Leaving directory '/home/bigfoot/libtpms-0.6.0/src'
make[1]: *** [Makefile:507: all-recursive] Error 1
make[1]: Leaving directory '/home/bigfoot/libtpms-0.6.0'
make: *** [Makefile:414: all] Error 2

Platform:
Failed: ArchLinux: gcc (GCC) 8.2.1 20181127 (Kernel: 4.20.7)
Success: CentOS: gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36) (Kernel: 3.10.0)
Success: Deepin: gcc (Debian 7.3.0-19) 7.3.0 (Kernel: 4.15.0)

references __GNUC_MINOR. The correct name is __GNUC_MINOR__.

Cf. https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html

With gcc 10.1.0 I get with current master:

bin/sh ../libtool  --tag=CC   --mode=compile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I..    -include tpm_library_conf.h -I../include/libtpms -I../include/libtpms -fstack-protector-strong    -D_POSIX_ -DTPM_POSIX -DTPM_LIBTPMS_CALLBACKS -I ./tpm2 -I ./tpm2/crypto -I ./tpm2/crypto/openssl -g -O2 -DUSE_OPENSSL_FUNCTIONS_SYMMETRIC=1 -DUSE_OPENSSL_FUNCTIONS_EC=1 -DUSE_OPENSSL_FUNCTIONS_ECDSA=1 -DUSE_OPENSSL_FUNCTIONS_RSA=1  -Wall -Werror -Wreturn-type -Wsign-compare -Wno-self-assign -c -o tpm2/libtpms_tpm2_la-NVDynamic.lo `test -f 'tpm2/NVDynamic.c' || echo './'`tpm2/NVDynamic.c
libtool: compile:  x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -include tpm_library_conf.h -I../include/libtpms -I../include/libtpms -fstack-protector-strong -D_POSIX_ -DTPM_POSIX -DTPM_LIBTPMS_CALLBACKS -I ./tpm2 -I ./tpm2/crypto -I ./tpm2/crypto/openssl -g -O2 -DUSE_OPENSSL_FUNCTIONS_SYMMETRIC=1 -DUSE_OPENSSL_FUNCTIONS_EC=1 -DUSE_OPENSSL_FUNCTIONS_ECDSA=1 -DUSE_OPENSSL_FUNCTIONS_RSA=1 -Wall -Werror -Wreturn-type -Wsign-compare -Wno-self-assign -c tpm2/NVDynamic.c  -fPIC -DPIC -o tpm2/.libs/libtpms_tpm2_la-NVDynamic.o
tpm2/NVDynamic.c: In function ‘NvNextByType’:
tpm2/NVDynamic.c:126:10: error: ‘nvHandle’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
  126 |  *handle = nvHandle;
      |  ~~~~~~~~^~~~~~~~~~
tpm2/NVDynamic.c: At top level:
cc1: note: unrecognized command-line option ‘-Wno-self-assign’ may have been intended to silence earlier diagnostics
cc1: all warnings being treated as errors
make[2]: *** [Makefile:2583: tpm2/libtpms_tpm2_la-NVDynamic.lo] Error 1

The following change silences the warning but I'm unsure if it's semantically correct:

diff --git a/src/tpm2/NVDynamic.c b/src/tpm2/NVDynamic.c
index 32f46bb..c51233e 100644
--- a/src/tpm2/NVDynamic.c
+++ b/src/tpm2/NVDynamic.c
@@ -114,7 +114,7 @@ NvNextByType(
             )
 {
     NV_REF           addr;
-    TPM_HANDLE       nvHandle;
+    TPM_HANDLE       nvHandle = 0;
     while((addr = NvNext(iter, &nvHandle)) != 0)
        {
            // addr: the address of the location containing the handle of the value

PR #35 addresses the issue of the NVRAM not being available during TPM2_Shutdown() when using cached state (TPMLIB_SetState()) and having called the sequence of TPMLIB_Terminate() and TPMLIB_MainInit() in the program while expecting to resume the TPM 2 with the previous permanent and volatile state.

The Linux kernel TPM 2 resource manager (/dev/tpmrm0) cannot deal with larger context sizes due to RSA 3072 bit support in libtpms 0.8.0. The effect is that certain utilities from Intel's TSS 2 stack stall and the Linux device driver prints out an error message like this:

[  842.301584] tpm tpm0: tpm2_save_context: out of backing storage
[  842.305463] tpm tpm0: tpm2_commit_space: error -12 

The release of libtpms 0.8.0 needs to be deferred until the device driver has been properly patched and the fix applied to previous kernels and those kernels have been packaged for Distros, otherwise those TPM 2 tools will not work and also Clevis (/Tang) will not work with a TPM 2 (that support 3072 bit RSA keys).

The following simple test case should always work:

# echo hi | clevis encrypt tpm2 '{"key":"rsa"}' | clevis decrypt
hi

Describe the bug
Since libtpms version 0.8.5, attempting to run tpm2 pcrevent (from tpm2-tools) through tpm2-abrmd generates the following TPM failure:

libtpms/tpm2: Entering failure mode; code: 3, location: CryptDigestUpdate line 429
libtpms/tpm2: TPM2_Process: Entered failure mode through command:
80 02 00 00 00 22 00 00 01 5c 80 00 00 00 00 00
00 09 40 00 00 09 00 00 00 00 00 00 05 74 65 73
74 0a

I guess this is related to commit 33a0398, which seems to corrupt the internal TPM state in this use case.

To Reproduce
Steps to reproduce the behavior:

1. Start swtpm and tpm2-abrmd:

   swtpm socket --tpm2 --server port=2321 --ctrl type=tcp,port=2322 --flags not-need-init --tpmstate dir=/tmp &
   tpm2-abrmd --session --dbus-name=com.intel.tss2.Tabrmd2321 --tcti=swtpm:port=2321 &
   

2. Try to run tpm2 pcrevent using the simulator:

   $ echo test | tpm2 pcrevent --tcti="tabrmd:bus_type=session,bus_name=com.intel.tss2.Tabrmd2321"
   WARNING:esys:src/tss2-esys/api/Esys_SequenceUpdate.c:287:Esys_SequenceUpdate_Finish() Received TPM Error
   ERROR:esys:src/tss2-esys/api/Esys_SequenceUpdate.c:97:Esys_SequenceUpdate() Esys Finish ErrorCode (0x00000101)
   ERROR: Esys_SequenceUpdate(0x101) - tpm:error(2.0): commands not being accepted because of a TPM failure
   WARNING:esys:src/tss2-esys/api/Esys_FlushContext.c:234:Esys_FlushContext_Finish() Received TPM Error
   ERROR:esys:src/tss2-esys/api/Esys_FlushContext.c:89:Esys_FlushContext() Esys Finish ErrorCode (0x00000101)
   ERROR: Esys_FlushContext(0x101) - tpm:error(2.0): commands not being accepted because of a TPM failure
   ERROR: Unable to run pcrevent
   

Expected behavior
The command should succeed and print the calculated hashes. Instead, libtpms/swtpm enters a TPM failure with the above error messages.

Desktop (please complete the following information):

• OS: Arch Linux
• Version: rolling release

Versions of relevant components

• libtpms: 0.8.5
• openssl: 1.1.1l
• tpm2-tss: 3.1.0
• tpm2-abrmd: 2.4.0
• tpm2-tools: 5.1.1

Additional context
When running tpm2 pcrevent directly against the simulator instead of through the tpm2-abrmd context manager (i.e. with echo test | tpm2 pcrevent --tcti=swtpm), the problem doesn't occur, probably because there is no context save involved.

On systems without nss-config we get this compile time error. It should be caught in configure time and not compile time.

/bin/bash: nss-config: command not found

Hi Stefan!

I'm having some issues trying to understand how the libtpms works. I am trying to create a docker enviroment in order to fuzzing but when I try to run the Example that you have in the wiki from @ruilopez it generates an error with mk-build-deps.

E: You must put some 'source' URIs in your sources.list
mk-build-deps: Unable to find package name in `apt-cache showsrc debian/control'

In addition, do you have any extended documentation that help me to understand how libtpms works?

Thanks in advance

Fernando

nspr-config is needed to build. This should be caught during config instead of generating a compile error during make.

/bin/bash: nspr-config: command not found

Describe the bug

Compilation of libtpms-0.9.x (and probably many other versions) for PowerPC64 fails on Ubuntu Jammy (Launchpad PPA). All other architectures amd64, arm64, armhf, and s390x do not report this issue. The reported issue seems to be a false positive.

In function ‘MakeIv’,
    inlined from ‘TestSymmetricAlgorithm’ at tpm2/AlgorithmTests.c:223:25:
tpm2/AlgorithmTests.c:200:23: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
  200 |                 *iv++ = i;
      |                 ~~~~~~^~~
In file included from tpm2/Global.h:78,
                 from tpm2/Tpm.h:78,
                 from tpm2/AlgorithmTests.c:66:
tpm2/AlgorithmTests.c: In function ‘TestSymmetricAlgorithm’:
tpm2/TpmTypes.h:1440:33: note: at offset 16 into destination object ‘buffer’ of size 16
 1440 |         BYTE                    buffer[MAX_SYM_BLOCK_SIZE];
      |                                 ^~~~~~
In function ‘MakeIv’,
    inlined from ‘TestSymmetricAlgorithm’ at tpm2/AlgorithmTests.c:223:25:
tpm2/AlgorithmTests.c:200:23: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
  200 |                 *iv++ = i;
      |                 ~~~~~~^~~
In file included from tpm2/Global.h:78,
                 from tpm2/Tpm.h:78,
                 from tpm2/AlgorithmTests.c:66:
tpm2/AlgorithmTests.c: In function ‘TestSymmetricAlgorithm’:
tpm2/TpmTypes.h:1440:33: note: at offset 17 into destination object ‘buffer’ of size 16
 1440 |         BYTE                    buffer[MAX_SYM_BLOCK_SIZE];
      |                                 ^~~~~~

[...]

In file included from tpm2/Global.h:78,
                 from tpm2/Tpm.h:78,
                 from tpm2/AlgorithmTests.c:66:
tpm2/AlgorithmTests.c: In function ‘TestSymmetricAlgorithm’:
tpm2/TpmTypes.h:1440:33: note: at offset 29 into destination object ‘buffer’ of size 16
 1440 |         BYTE                    buffer[MAX_SYM_BLOCK_SIZE];
      |                                 ^~~~~~
In function ‘MakeIv’,
    inlined from ‘TestSymmetricAlgorithm’ at tpm2/AlgorithmTests.c:233:5:
tpm2/AlgorithmTests.c:200:23: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
  200 |                 *iv++ = i;
      |                 ~~~~~~^~~
In file included from tpm2/Global.h:78,
                 from tpm2/Tpm.h:78,
                 from tpm2/AlgorithmTests.c:66:
tpm2/AlgorithmTests.c: In function ‘TestSymmetricAlgorithm’:
tpm2/TpmTypes.h:1440:33: note: at offset 30 into destination object ‘buffer’ of size 16
 1440 |         BYTE                    buffer[MAX_SYM_BLOCK_SIZE];
      |                                 ^~~~~~

It seems to indicate that there is a buffer overflow error in the buffer[MAX_SYM_BLOCK_SIZE], which is of size 16 but it's writing to offsets 16 .. 30.

The offending code is this here in TestSymmetricAlgorithm:

static void
TestSymmetricAlgorithm(
                       const SYMMETRIC_TEST_VECTOR     *test,          //
                       TPM_ALG_ID                       mode           //
                       )
[...]
    //
    // Get the appropriate IV
    iv.t.size = (UINT16)MakeIv(mode, test->ivSize, iv.t.buffer);

The function TestSymmetricAlgorithm is always called like this:

                                        TestSymmetricAlgorithm(&c_symTestValues[index], mode);

The c_symTestValues[] are here: https://github.com/stefanberger/libtpms/blob/stable-0.9/src/tpm2/SymmetricTest.h#L80-L135

Per the definition of the SYMMETRIC_TEST_VECTOR structure (https://github.com/stefanberger/libtpms/blob/stable-0.9/src/tpm2/SelfTest.h#L102-L110), the ivSize field is the 4th element. The c_symTestValues's ivSizes are therefore only 8 and 16.

static UINT32
MakeIv(
       TPM_ALG_ID    mode,     // IN: symmetric mode
       UINT32        size,     // IN: block size of the algorithm
       BYTE         *iv        // OUT: IV to fill in
       )
{
    BYTE          i;
    if(mode == TPM_ALG_ECB)
        return 0;
    if(mode == TPM_ALG_CTR)
        {
            // The test uses an IV that has 0xff in the last byte
            for(i = 1; i <= size; i++)
                *iv++ = 0xff - (BYTE)(size - i);
        }
    else
        {
            for(i = 0; i < size; i++)
                *iv++ = i;                         <========= alleged buffer overflow
        }
    return size;
}

With size max 16, how should this cause a buffer overflow?

Bug description
When running TPM2_ContextSave followed by a TPM2_ContextLoad inside a Windows guest in qemu as part of a certreq command, the TPM2_ContextLoad fails.

The reason for this seems to be that the Windows driver sends a context padded until TPM_PT_MAX_OBJECT_CONTEXT when issuing TPM2_ContextLoad, even though TPM2_ContextSave responded with a context smaller than TPM_PT_MAX_OBJECT_CONTEXT.

To Reproduce
Steps to reproduce the behavior:

1. Start a Windows guest in qemu:

qemu-system-x86_64 -hda /home/fedora/vm-store/server-2019.qcow2 \
-boot d \
-cdrom /home/fedora/vm-store/Windows_2019_Server.iso \
-vnc 127.0.0.1:0,password \
-m 8192 \
-enable-kvm \
-monitor stdio \
-chardev socket,id=chrtpm,path=/home/fedora/vm-store/tpm-state/swtpm-sock \
-tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0 \
-nic user,hostfwd=tcp::3389-:3389,hostfwd=tcp::1771-:1771,hostfwd=tcp::137-:137,hostfwd=udp::137-:137,hostfwd=udp::138-:138,hostfwd=tcp::139-:139

2. Setup a certificate authority following these instructions: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/manage/component-updates/tpm-key-attestation
3. Run certreq -q -enroll TPM_KEY inside the Windows guest

Expected behavior
certreq command should succeed in issuing the certificate. Other TPM2_ContextSave & TPM2_ContextLoad valid workflows should succeed as well under Windows guests.

Desktop (please complete the following information):

• OS: Fedora
• Version 33

Versions of relevant components

• libtpms: 0.8.2
• swtpm: 0.5.2

Additional context
The first encounter of this problem was during a test run of HLK Windows test suite.

The commit that triggers this seems to be 1e1648f .

Describe the bug
In function PERSISTENT_DATA_Unmarshal in https://github.com/stefanberger/libtpms/blob/901c9a76c79cc60413484ea5d9b0ee425b7c559d/src/tpm2/NVMarshal.c, the name parameter of BLOCK_SKIP_READ takes several different values:

// Line 3929
        BLOCK_SKIP_READ(skip_num_policy_pcr_group, needs_block, buffer, size,
                        "PERSISTENT_DATA", "pcrPolicies");
// Line 4038
        BLOCK_SKIP_READ(skip_future_versions, hdr.version >= 3, buffer, size,
                        "Volatile State", "version 3 or later");
// Line 4042
        BLOCK_SKIP_READ(skip_future_versions, hdr.version >= 4, buffer, size,
                        "PERSISTENT DATA", "version 4 or later");
// Line 4058
        BLOCK_SKIP_READ(skip_future_versions, FALSE, buffer, size,
                        "PERSISTENT DATA", "version 5 or later");

The use of "Volatile State" is likely a copy-paste error, and using both "PERSISTENT_DATA" (with an underscore) and "PERSISTENT DATA" (with no underscore) is inconsistent.

To Reproduce
Steps to reproduce the behavior:

1. Open src/tpm2/NVMarshal.c
2. Search for BLOCK_SKIP_READ in function PERSISTENT_DATA_Unmarshal
3. Observe the name parameter of this macro

Expected behavior
I expect that all invocations of BLOCK_SKIP_READ in PERSISTENT_DATA_Unmarshal use the same name.

Versions of relevant components

• libtpms: master (as well as some previous versions).

Additional context
I was trying to understand the content of the file which stores the persistent data of the TPM used by swtpm when I stumbled upon this inconsistency.

While testing the tpm2_preview.rev138 code (called from a swtpm interface), I encountered a seg fault in SessionProcess.c (line 585).

The fault is triggered by a TPM2_Startup command (launched from swtpm_bios). It seems that an incorrect hash algo ID is provided (somehow) there. Is this a known issue?

I have not yet tested the tpm2_preview.rev142 code.

Hi,
this message occurs on Debian (Bullseye/11) ppc64el when building latest upstream ( 967e52e ).

make  check-local
make[3]: Entering directory '/<<PKGBUILDDIR>>/src'
There are undefined symbols in libtpms (    )
/usr/bin/ld: ./.libs/libtpms.so: ABI version 2 is not compatible with ABI version 0 output
/usr/bin/ld: failed to merge target specific data of file ./.libs/libtpms.so
make[3]: *** [Makefile:3663: check-local] Error 1

Versions of relevant components

• libtpms: 0.10.0~dev1 but also with 0.9.0
• openssl: 1.1.1k-1+deb11u1
• gcc version 10.2.1 20210110 (Debian 10.2.1-6)

F.

Hi, stefan. rev164 has support CC_ECC_Encrypt and CC_ECC_Decrypt commands, and the code PR #292 are from Trusted Platform Module Library Part 3: Commands and Trusted Platform Module Library Part 4: Supporting Routines.

Upgrade the code to revision 155 or later.

hi, just a quick note here

In v0.8.4 there was a change to gitignore adding "/man/man3/*.3"
The issue is that there are still files in the man3 directory that are being used in the makefile. Since these are already committed, they aren't ignore by git, but if the codebase is cloned, those start getting ignored and make fails (in my case "TPM_Free.3").

cpp-coveralls seems to create wrong filename paths due the fact that the Makefile used for building sources is in src/ and used to build files in src/tpm12 and src/tpm2 subdirectories. The results submitted to coverall.io are not complete since we have to filter out certain paths.

https://github.com/stefanberger/libtpms/blob/master/.travis.yml#L54

In issue has been submitted to cpp-coveralls: eddyxu/cpp-coveralls#135

I am filing this on behalf of William Roberts [email protected]

Describe the bug
libtpms added an OpenSSL back-end to the encryption code, however, the encryption routines are supposed to update the ivInOut paramater on successful execution of the AES cipher. However, the openssl backend code fails to do this, but when configured with --disable-use-openssl-functions, the crypto code goes back to the reference code implementation which properly updates the ivInOut. The side effect of not updating the ivInOut is that the output IV returned to applications is the same as the input IV. This results in weakened AES rounds.
Steps To Reproduce:
I have attached a script that uses the tpm2-software stack to reproduce the bug, as well as attached a fix patch.

1. Create an AES key with the TPM
2. Call EncryptDecrypt or EncryptDecrypt2 using that key.
3. Note the sent IV is same as returned IV.

*** Example of Running the Test Script **

./pcap-enc-dec.sh.sh swtpm
<snip>
IV in
00000000: dead beef dead beef dead beef dead beef  ................
IV out
00000000: dead beef dead beef dead beef dead beef  ................
Encrypted Result
00000000: 7642 3cc5 7eb8 4acb 6f9e 5fc8 f068 fdb4  vB<.~.J.o._..h..

Notice that IV in is equal to IV out.
After you apply the patch to libtpms, and rebuild swtpm, you can verify different output.

./pcap-enc-dec.sh.sh swtpm
<snip>
IV in
00000000: dead beef dead beef dead beef dead beef  ................
IV out
00000000: 211e 86fe 7199 8e7b f20f 4b95 6624 6bfc  !...q..{..K.f$k.
Encrypted Result
00000000: 211e 86fe 7199 8e7b f20f 4b95 6624 6bfc  !...q..{..K.f$k.

Note that the script can take two arguments:
First argument is the TCTI, like swtpm, device, or mssim.
Second argument, if specified must specify argument 1, AES mode of operation.
Also note, that I attached tpm2_log.pcap for a single run of that tool, you can open it in wireshark v3.0 or greater and see the TPM transmission bytes between the script and swtpm/libtpms.
Supporting Material/References: [Images are preferred. Videos (mp4) are allowed.]
See attached.
tpm2_log.pcap: pcap log file, can be opened with wireshark v3.0+.
pcap-enc-dec.sh.sh: reproduction script. Uses tpm2-software stack: https://github.com/tpm2-software
0001-CryptSym-fix-AES-output-IV.patch: fix patch to apply to libtpms
Access Vector Required for Exploitation:
Application data encrypted with multiple rounds of AES will be weakened, access to that cipher text could be compromised.
Vulnerability Exists in Default Configuration?:
Yes, you need to configure with --disable-use-openssl-functions to avoid it.
Is the exploitation trivial or does it involve a multi-step process that may depend on user/victim interaction?:
Depends.
Exploitation Requires Authentication?:
Depends on how the ciphertext is protected.
Under what privileges does the vulnerable service or component run?:
Access to ciphertext could be compromised.
Impact
Compromising encrypted data.

We need to find all variables in functions that hold sensitive data that need clearing before the function returns.

What is the procedure to cross compile libtpm tools with openssl and tpm2 options enabled ?

I have tried cross compiling ,but I get the following error :
./autogen.sh --host=arm-linux-gnueabi --prefix=/tpm_tools_bin --with-tpm2 --with-openssl
autoreconf: Entering directory .' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force -I m4 autoreconf: configure.ac: tracing autoreconf: running: libtoolize --copy --force libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, '.'. libtoolize: copying file './ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'. libtoolize: copying file 'm4/libtool.m4' libtoolize: copying file 'm4/ltoptions.m4' libtoolize: copying file 'm4/ltsugar.m4' libtoolize: copying file 'm4/ltversion.m4' libtoolize: copying file 'm4/lt~obsolete.m4' autoreconf: running: /usr/bin/autoconf --force autoreconf: running: /usr/bin/autoheader --force autoreconf: running: automake --add-missing --copy --force-missing configure.ac:57: installing './compile' configure.ac:14: installing './missing' src/Makefile.am: installing './depcomp' autoreconf: Leaving directory .'
checking build system type... x86_64-pc-linux-gnu
checking host system type... arm-unknown-linux-gnueabi
checking target system type... arm-unknown-linux-gnueabi
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for arm-linux-gnueabi-strip... arm-linux-gnueabi-strip
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking for debug-enabled build... no
checking whether make supports the include directive... yes (GNU style)
checking for arm-linux-gnueabi-gcc... arm-linux-gnueabi-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether arm-linux-gnueabi-gcc accepts -g... yes
checking for arm-linux-gnueabi-gcc option to accept ISO C89... none needed
checking whether arm-linux-gnueabi-gcc understands -c and -o together... yes
checking dependency style of arm-linux-gnueabi-gcc... gcc3
checking whether the linker accepts -Wl,--version-script=./src/test.syms... yes
Building with TPM2 support
checking how to run the C preprocessor... arm-linux-gnueabi-gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for AES_set_encrypt_key in -lcrypto... no
configure: error: Faulty openssl crypto library

Later I have tried to provide the path of cross compiled openssl lib. I get the same error there as well. I have attached the build log below.

./autogen.sh --host=arm-linux-gnueabi --prefix=/tpm_tools_bin --with-tpm2 --with-openssl=/openssl/
autoreconf: Entering directory .' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force -I m4 autoreconf: configure.ac: tracing autoreconf: running: libtoolize --copy --force libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, '.'. libtoolize: copying file './ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'. libtoolize: copying file 'm4/libtool.m4' libtoolize: copying file 'm4/ltoptions.m4' libtoolize: copying file 'm4/ltsugar.m4' libtoolize: copying file 'm4/ltversion.m4' libtoolize: copying file 'm4/lt~obsolete.m4' autoreconf: running: /usr/bin/autoconf --force autoreconf: running: /usr/bin/autoheader --force autoreconf: running: automake --add-missing --copy --force-missing configure.ac:57: installing './compile' configure.ac:14: installing './missing' src/Makefile.am: installing './depcomp' autoreconf: Leaving directory .'
checking build system type... x86_64-pc-linux-gnu
checking host system type... arm-unknown-linux-gnueabi
checking target system type... arm-unknown-linux-gnueabi
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for arm-linux-gnueabi-strip... arm-linux-gnueabi-strip
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking for debug-enabled build... no
checking whether make supports the include directive... yes (GNU style)
checking for arm-linux-gnueabi-gcc... arm-linux-gnueabi-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether arm-linux-gnueabi-gcc accepts -g... yes
checking for arm-linux-gnueabi-gcc option to accept ISO C89... none needed
checking whether arm-linux-gnueabi-gcc understands -c and -o together... yes
checking dependency style of arm-linux-gnueabi-gcc... gcc3
checking whether the linker accepts -Wl,--version-script=./src/test.syms... yes
Building with TPM2 support
checking how to run the C preprocessor... arm-linux-gnueabi-gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for AES_set_encrypt_key in -lcrypto... no
configure: error: Faulty openssl crypto library

Please let me know if I'm missing steps.

Describe the bug
libtpms 0.8.0 since commit 1e1648f uses ANY_OBJECT_Marshal to save key contexts. However, public keys loaded using TPM2_LoadExternal have a sensitive portion of NULL, leading to the following error when trying to run TPM2_ContextSave on them:

libtpms/tpm2: Entering failure mode; code: 4, location: TPMU_SENSITIVE_COMPOSITE_Marshal line 2126
libtpms/tpm2: TPM2_Process: Entered failure mode through command:
80 01 00 00 00 0e 00 00 01 62 80 00 00 00 

To Reproduce
Steps to reproduce the behavior:

1. Install libtpms 0.8.0, swtpm 0.5.2, OpenSSL 1.1.1j and tpm2-tools 5.0.
2. Run the following commands:

   openssl genrsa -out priv.key 2048
   openssl rsa -in priv.key -pubout -out pub.key
   swtpm socket --tpm2 --server port=2321 --ctrl type=tcp,port=2322 --flags not-need-init,startup-clear --tpmstate dir=/tmp &
   tpm2_loadexternal --tcti=swtpm --key-algorithm=rsa --public=pub.key --key-context=key.ctx
   

3. Observe the last command failing with the error message

   libtpms/tpm2: Entering failure mode; code: 4, location: TPMU_SENSITIVE_COMPOSITE_Marshal line 2126
   libtpms/tpm2: TPM2_Process: Entered failure mode through command:
   80 01 00 00 00 0e 00 00 01 62 80 00 00 00
   WARNING:esys:src/tss2-esys/api/Esys_ContextSave.c:247:Esys_ContextSave_Finish() Received TPM Error
   ERROR:esys:src/tss2-esys/api/Esys_ContextSave.c:92:Esys_ContextSave() Esys Finish ErrorCode (0x00000101)
   ERROR: Esys_ContextSave(0x101) - tpm:error(2.0): commands not being accepted because of a TPM failure
   ERROR: Unable to run tpm2_loadexternal
   

4. With libtpms <= 0.7.5, the tpm2_loadexternal command succeeds, printing something like

   name: 000b5bf247d84aedc11dd556c59aa600386cb28de8e03be313c82ddd2177911bd8c5
   

   in return instead.

Expected behavior
Saving a context for a public key loaded using TPM2_LoadExternal should work without producing an internal TPM failure.

Desktop

• OS: Arch Linux (rolling release)

Versions of relevant components

• libtpms: 0.8.0
• openssl: 1.1.1j
• swtpm 0.5.2

Additional context
This breaks some tests of the tpm2-tools test suite which rely on externally loaded public keys.

when I run the following tpm command using tpm2-tools, the error code is 0x103.

dd if=/dev/urandom of=hash.in count=1 bs=2093 2> /dev/null 
tpm2 pcrevent -Q -P foo hash.in
tpm2 flushcontext -t

I found it will flush sequence object in ExecuteCommand, when the evict attributes of object is set. However, when run TPM2_EventSequenceComplete, or TPM2_SequenceComplete, this evict attributes is set. So it cannot be flushed, when TPM2_SequenceUpdate failed.

Hello again!

I have manually started the tpm (via TPMLIB_MainInit()), then I executed TPM_Startup command. I provisioned new EK certificate (TPM_CreatePrimary under TPM_RH_ENDORSEMENT, issue cert, TPM_NV_DefineSpace, TPM_NV_Write). Then, I started the VM, and inside it, I read the certificate from the NV. Everything works fine so far.

Then, I try to create new attestation key. The storage root key does not exist, hence I try to create it with TPM_CreatePrimary using TPM_RH_OWNER as the primary handle. The swtpm responds:
code=389, description=TPM_RC_HIERARCHY - hierarchy is not enabled or is not correct for the use Handle number 1

Ok, I executed TPM_HierarchyControl authHandle=TPM_RH_OWNER and enable=TPM_RH_OWNER. It returned success, but the error remains.

Is the storage hierarchy enabled by default? or is it a BIOS which has to enable/disable it? Even after enabling it, I cannot create new key. Do you have any idea what I did wrong?

TSS_Execute_valist: Step 1: initialization
TSS_Execute_valist: Step 5: command encrypt
TSS_Sessions_GetDecryptSession: Found 0 decrypt sessions at 0
TSS_Execute_valist: Step 6 calculate HMACs
TSS_Execute_valist: Step 7 set command authorizations
TSS_Execute_valist: Step 8: process the command
TSS_AuthExecute: Executing TPM2_NV_ReadPublic
TSS_Dev_Open: Opening /dev/tpm0
TSS_Dev_SendCommand: TPM2_NV_ReadPublic
 TSS_Dev_SendCommand length 14
 80 01 00 00 00 0e 00 00 01 69 01 c0 00 02 
TSS_Dev_ReceiveCommand:
 TSS_Dev_ReceiveCommand length 62
 80 01 00 00 00 3e 00 00 00 00 00 0e 01 c0 00 02 
 00 0b 62 05 00 05 00 00 04 4c 00 22 00 0b 73 36 
 2d 7f 6a 18 de b5 aa 35 cf a4 f9 10 ef e3 c6 45 
 81 64 3a 1e be 45 20 db b3 93 66 c2 09 a5 
TSS_Dev_ReceiveCommand: rc 00000000
TSS_Execute_valist: Step 9 get response authorizations
TSS_Execute_valist: Step 13: response decryption
TSS_Sessions_GetEncryptSession: Found 0 encrypt sessions at 0
TSS_Execute: Command 00000169 unmarshal
TSS_Execute: Command 00000169 post processor
TSS_PO_NV_ReadPublic
TSS_Name_Store: Handle 01c00002
TSS_Execute: Command 0000017a marshal
TSS_Execute_valist: Step 1: initialization
TSS_Execute_valist: Step 5: command encrypt
TSS_Sessions_GetDecryptSession: Found 0 decrypt sessions at 0
TSS_Execute_valist: Step 6 calculate HMACs
TSS_Execute_valist: Step 7 set command authorizations
TSS_Execute_valist: Step 8: process the command
TSS_AuthExecute: Executing TPM2_GetCapability
TSS_Dev_SendCommand: TPM2_GetCapability
 TSS_Dev_SendCommand length 22
 80 01 00 00 00 16 00 00 01 7a 00 00 00 06 00 00 
 01 2c 00 00 00 01 
TSS_Dev_ReceiveCommand:
 TSS_Dev_ReceiveCommand length 27
 80 01 00 00 00 1b 00 00 00 00 01 00 00 00 06 00 
 00 00 01 00 00 01 2c 00 00 04 00 
TSS_Dev_ReceiveCommand: rc 00000000
TSS_Execute_valist: Step 9 get response authorizations
TSS_Execute_valist: Step 13: response decryption
TSS_Sessions_GetEncryptSession: Found 0 encrypt sessions at 0
TSS_Execute: Command 0000017a unmarshal
TSS_Execute: Command 0000017a post processor
TRACE:tpm20tss::info: Read max NV buffer: 1024
TSS_Execute: Command 0000014e marshal
TSS_Execute_valist: Step 1: initialization
TSS_Execute_valist: Step 2: authorization 0
TSS_Execute_valist: session 0 handle 40000009
TSS_Execute_valist: Step 5: command encrypt
TSS_Sessions_GetDecryptSession: Found 0 decrypt sessions at 0
TSS_Execute_valist: Step 6 calculate HMACs
TSS_HmacSession_SetHMAC: Step 6 session 40000009
TSS_Execute_valist: Step 7 set command authorizations
TSS_Execute_valist: Step 8: process the command
TSS_AuthExecute: Executing TPM2_NV_Read
TSS_Dev_SendCommand: TPM2_NV_Read
 TSS_Dev_SendCommand length 35
 80 02 00 00 00 23 00 00 01 4e 01 c0 00 02 01 c0 
 00 02 00 00 00 09 40 00 00 09 00 00 00 00 00 04 
 00 00 00 
TSS_Dev_ReceiveCommand:
 TSS_Dev_ReceiveCommand length 1045
 80 02 00 00 04 15 00 00 00 00 00 00 04 02 04 00 
 30 82 03 85 30 82 02 6d a0 03 02 01 02 02 02 03 
 e8 30 0d 06 09 2a 86 48 86 f7 0d 01 01 0b 05 00 
 30 3a 31 0b 30 09 06 03 55 04 06 13 02 44 45 31 
 0f 30 0d 06 03 55 04 08 0c 06 53 61 78 6f 6e 79 
 31 0c 30 0a 06 03 55 04 0a 0c 03 54 55 44 31 0c 
 30 0a 06 03 55 04 03 0c 03 4c 41 53 30 1e 17 0d 
 31 39 30 33 32 32 31 30 35 30 32 37 5a 17 0d 32 
 30 30 33 32 31 31 30 35 30 32 37 5a 30 39 31 0b 
 30 09 06 03 55 04 06 13 02 49 54 31 0c 30 0a 06 
 03 55 04 08 0c 03 54 42 45 31 0d 30 0b 06 03 55 
 04 0a 0c 04 78 54 50 4d 31 0d 30 0b 06 03 55 04 
 03 0c 04 78 54 50 4d 30 82 01 22 30 0d 06 09 2a 
 86 48 86 f7 0d 01 01 01 05 00 03 82 01 0f 00 30 
 82 01 0a 02 82 01 01 00 b4 7e 85 14 00 00 cc 26 
 28 69 01 30 83 cf 43 66 40 8d 23 b7 47 1b ca ff 
 dd 91 d0 43 47 d6 49 ab 0b 32 b0 25 65 8e b9 87 
 d5 87 8c 64 1c 85 4e 72 81 a2 09 82 56 9c d6 77 
 da 87 61 38 6f 32 bc ac e0 ee bf b1 7e 67 45 6f 
 aa 87 75 8f dc 25 4d 7c 3f ee 70 8a 55 9c 8b 9c 
 07 de f0 d8 5f a4 89 f0 db fb 74 88 92 04 66 e6 
 8f 77 b4 53 cd 90 c0 e3 62 fd 4f 38 56 db 02 a3 
 78 7d d1 90 47 03 82 61 a9 9f 80 63 a4 0b e7 00 
 17 e9 25 12 83 c2 57 d6 ea 6e c8 84 05 aa ed c7 
 3d 4b 27 2f 11 5b fc 3d 70 12 68 90 31 a1 f8 36 
 3e 94 13 32 ed 71 64 35 0d e8 67 21 50 7c 74 aa 
 7e 10 a2 ad 13 ca 65 41 1f 2a 18 bd 53 a0 ad 94 
 34 a9 2c e4 61 7d d7 5b 1a b3 79 ce 60 6e 83 e5 
 ec 2b e0 a1 cd 43 86 b5 cb 69 7d c3 c2 d1 1a af 
 74 69 df 29 70 2f 43 30 84 de c8 42 bf dc ce 87 
 4c 3f 2f 5c fa f1 26 95 02 03 01 00 01 a3 81 95 
 30 81 92 30 09 06 03 55 1d 13 04 02 30 00 30 0b 
 06 03 55 1d 0f 04 04 03 02 05 a0 30 22 06 03 55 
 1d 25 04 1b 30 19 06 08 2b 06 01 05 05 07 03 01 
 06 08 2b 06 01 05 05 07 03 02 06 03 88 37 01 30 
 1d 06 03 55 1d 0e 04 16 04 14 da 39 a3 ee 5e 6b 
 4b 0d 32 55 bf ef 95 60 18 90 af d8 07 09 30 1f 
 06 03 55 1d 23 04 18 30 16 80 14 da 39 a3 ee 5e 
 6b 4b 0d 32 55 bf ef 95 60 18 90 af d8 07 09 30 
 14 06 03 55 1d 11 04 0d 30 0b 82 09 6c 6f 63 61 
 6c 68 6f 73 74 30 0d 06 09 2a 86 48 86 f7 0d 01 
 01 0b 05 00 03 82 01 01 00 5f 57 86 b2 cb 86 53 
 c3 6d 09 14 ee 06 eb 2b 3f ac 9d c8 d1 27 2a 60 
 93 81 f4 de f4 05 7f 2d 78 d7 04 06 66 6e a4 4c 
 67 ae 60 f8 17 d6 a3 a8 36 c1 7b 27 ab e5 27 bd 
 0a ed 59 20 94 e8 c9 c1 06 dd 8e 58 ee e0 b4 70 
 95 1b a4 50 16 46 55 3c b2 80 a0 4f 87 9b 98 4c 
 44 c5 12 ca 95 90 bc bd dd be 90 d0 c6 ed 6f b3 
 b3 6c 25 04 62 ae ad e6 03 83 d2 0c f7 68 22 a6 
 48 6b e7 cd 8e 39 54 73 23 c5 6e 18 70 d0 36 79 
 4e bf 52 55 ae 21 86 a4 f8 e7 e1 06 6a 46 ef 3b 
 35 19 66 28 fe 0f b4 0d 07 cc de 7f 17 51 b9 d8 
 03 a8 49 22 da d8 8c 2d e4 8c 84 c3 72 e2 2e 8c 
 09 24 9c 36 cb 8d 34 2e 18 17 06 bc 06 77 79 5b 
 25 e6 83 a1 49 49 d2 fc 43 30 54 9f 83 d3 c5 e0 
 18 a1 71 cc d3 50 47 28 e4 74 7a 3f c8 6d cd 5b 
 91 df 0e d3 31 68 58 91 a7 44 8a 3e 2f da 6e 29 
 13 90 d8 4f dc db b1 f2 9a ff ff ff ff ff ff ff 
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
 00 00 01 00 00 
TSS_Dev_ReceiveCommand: rc 00000000
TSS_Execute_valist: Step 9 get response authorizations
TSS_Execute_valist: Step 10: process response authorization 40000009
TSS_Execute_valist: Step 13: response decryption
TSS_Sessions_GetEncryptSession: Found 0 encrypt sessions at 0
TSS_Execute: Command 0000014e unmarshal
TSS_Execute: Command 0000014e post processor
TSS_Execute: Command 0000014e marshal
TSS_Execute_valist: Step 1: initialization
TSS_Execute_valist: Step 2: authorization 0
TSS_Execute_valist: session 0 handle 40000009
TSS_Execute_valist: Step 5: command encrypt
TSS_Sessions_GetDecryptSession: Found 0 decrypt sessions at 0
TSS_Execute_valist: Step 6 calculate HMACs
TSS_HmacSession_SetHMAC: Step 6 session 40000009
TSS_Execute_valist: Step 7 set command authorizations
TSS_Execute_valist: Step 8: process the command
TSS_AuthExecute: Executing TPM2_NV_Read
TSS_Dev_SendCommand: TPM2_NV_Read
 TSS_Dev_SendCommand length 35
 80 02 00 00 00 23 00 00 01 4e 01 c0 00 02 01 c0 
 00 02 00 00 00 09 40 00 00 09 00 00 00 00 00 00 
 4c 04 00 
TSS_Dev_ReceiveCommand:
 TSS_Dev_ReceiveCommand length 97
 80 02 00 00 00 61 00 00 00 00 00 00 00 4e 00 4c 
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff ff ff ff ff ff ff ff ff 00 00 01 00 
 00 
TSS_Dev_ReceiveCommand: rc 00000000
TSS_Execute_valist: Step 9 get response authorizations
TSS_Execute_valist: Step 10: process response authorization 40000009
TSS_Execute_valist: Step 13: response decryption
TSS_Sessions_GetEncryptSession: Found 0 encrypt sessions at 0
TSS_Execute: Command 0000014e unmarshal
TSS_Execute: Command 0000014e post processor
TSS_Execute: Command 0000017a marshal
TSS_Execute_valist: Step 1: initialization
TSS_Execute_valist: Step 5: command encrypt
TSS_Sessions_GetDecryptSession: Found 0 decrypt sessions at 0
TSS_Execute_valist: Step 6 calculate HMACs
TSS_Execute_valist: Step 7 set command authorizations
TSS_Execute_valist: Step 8: process the command
TSS_AuthExecute: Executing TPM2_GetCapability
TSS_Dev_SendCommand: TPM2_GetCapability
 TSS_Dev_SendCommand length 22
 80 01 00 00 00 16 00 00 01 7a 00 00 00 01 81 00 
 00 00 00 00 00 01 
TSS_Dev_ReceiveCommand:
 TSS_Dev_ReceiveCommand length 19
 80 01 00 00 00 13 00 00 00 00 00 00 00 00 01 00 
 00 00 00 
TSS_Dev_ReceiveCommand: rc 00000000
TSS_Execute_valist: Step 9 get response authorizations
TSS_Execute_valist: Step 13: response decryption
TSS_Sessions_GetEncryptSession: Found 0 encrypt sessions at 0
TSS_Execute: Command 0000017a unmarshal
TSS_Execute: Command 0000017a post processor
DEBUG:tpm20tss::attestation: Storage Root Key does not exist. Creating new one
TSS_Execute: Command 0000017a marshal
TSS_Execute_valist: Step 1: initialization
TSS_Execute_valist: Step 5: command encrypt
TSS_Sessions_GetDecryptSession: Found 0 decrypt sessions at 0
TSS_Execute_valist: Step 6 calculate HMACs
TSS_Execute_valist: Step 7 set command authorizations
TSS_Execute_valist: Step 8: process the command
TSS_AuthExecute: Executing TPM2_GetCapability
TSS_Dev_SendCommand: TPM2_GetCapability
 TSS_Dev_SendCommand length 22
 80 01 00 00 00 16 00 00 01 7a 00 00 00 01 81 00 
 00 00 00 00 00 01 
TSS_Dev_ReceiveCommand:
 TSS_Dev_ReceiveCommand length 19
 80 01 00 00 00 13 00 00 00 00 00 00 00 00 01 00 
 00 00 00 
TSS_Dev_ReceiveCommand: rc 00000000
TSS_Execute_valist: Step 9 get response authorizations
TSS_Execute_valist: Step 13: response decryption
TSS_Sessions_GetEncryptSession: Found 0 encrypt sessions at 0
TSS_Execute: Command 0000017a unmarshal
TSS_Execute: Command 0000017a post processor
TSS_Execute: Command 00000131 marshal
TSS_Execute_valist: Step 1: initialization
TSS_Execute_valist: Step 2: authorization 0
TSS_Execute_valist: session 0 handle 40000009
TSS_Execute_valist: Step 5: command encrypt
TSS_Sessions_GetDecryptSession: Found 0 decrypt sessions at 0
TSS_Execute_valist: Step 6 calculate HMACs
TSS_HmacSession_SetHMAC: Step 6 session 40000009
TSS_Execute_valist: Step 7 set command authorizations
TSS_Execute_valist: Step 8: process the command
TSS_AuthExecute: Executing TPM2_CreatePrimary
TSS_Dev_SendCommand: TPM2_CreatePrimary
 TSS_Dev_SendCommand length 67
 80 02 00 00 00 43 00 00 01 31 40 00 00 01 00 00 
 00 09 40 00 00 09 00 00 00 00 00 00 04 00 00 00 
 00 00 1a 00 01 00 0b 00 03 04 72 00 00 00 06 00 
 80 00 43 00 10 08 00 00 00 00 00 00 00 00 00 00 
 00 00 00 
TSS_Dev_ReceiveCommand:
 TSS_Dev_ReceiveCommand length 10
 80 01 00 00 00 0a 00 00 01 85 
TSS_Dev_ReceiveCommand: rc 00000185
TSS_Dev_Close: Closing /dev/tpm0```

Release v 0.7

Hello,

actually main problem is we interfaced slb 9670(tpm-2.0) with 16 bit msp430 controller which does not support linux kernel or any OS.

now our task is to store a 100 byes of data in NV memory, without any authorisation technique, as simple as possible.

please guide me in that way.

slb 9670 is interfaced with msp430 controller through SPI protocol.

I able to read device id , version id of slb9670 , so spi communication is working fine with our controller .

what is packet format to be send with our data , i am not able to understand the TCG documents .

theoretically iam able to understand we have to do nvdefinespace , nvwrite ,nvread .. internaly what is the format i have to be send not able to understand

can you please guide me , or share any code snippet .

sorry if i trouble you or any irrelevant questions.

Regards,
Manoj,
mail : [email protected]
+91-9063249308

Hello, I have another question, when I run the following tpm command using tpm2-tools, I got 0x2d2.
tpm2 create -C primary.ctxt -g sha256 -G rsa -r key.prv -u key.pub -L policy.dat -a "sensitivedataorigin"
I found it returns this error code in PublicAttributesValidation function:
// See if sign and decrypt are the same if(IS_ATTRIBUTE(attributes, TPMA_OBJECT, sign) == IS_ATTRIBUTE(attributes, TPMA_OBJECT, decrypt)) { // a restricted key cannot have both SET or both CLEAR if(IS_ATTRIBUTE(attributes, TPMA_OBJECT, restricted)) return TPM_RC_ATTRIBUTES; // only a data object may have both sign and decrypt CLEAR // BTW, since we know that decrypt==sign, no need to check both if(publicArea->type != TPM_ALG_KEYEDHASH && !IS_ATTRIBUTE(attributes, TPMA_OBJECT, sign)) **return TPM_RC_ATTRIBUTES; // error code return** }
However, in Trusted Platform Module Library Part 1: Architecture, there are the following descriptions:
Revision 148
Reworked the attestation key certification to indicate that an encrypted challenge response is a more likely use case than an encrypted certificate.
Field upgrade should not affect TPM2_CreatePrimary() outputs under certain conditions.
The reset of the TIme circuit is related to TPM power, not TPM_Init.
MAX_SYM_DATA 128 changed from shall to should.
sign and decrypt both CLEAR or SET and scheme not TPM_ALG_NULL returns TPM_RC_SCHEME.
TPM2_PCR_Allocate() takes effect at _TPM_Init(), not TPM2_Startup().

so is whether the error code inconsistent with the TCG standard?

Hi,

I notice the libtpms on ubuntu depend on libnss3-dev 3.17.2. Could anyone provide some guideline how to download this specific version of library on ubuntu?

Thanks in advance

I think this is an important discussion to have since downgrading of state has come up in some discussions and it's not quite clear how to go about.

First, downgrading of state means that the state of a TPM 2.0 can be migrated for example from libtpms version 0.12 to version 0.9, or more general from version (n+m) to version n and with the latest release being version 0.9, n can only possibly be version 0.9 since previous versions do not allow downgrading anyway. There is at least the following to consider for downgrading:

Applications cannot just loose functionality: Assuming a new crypto algorithm was added to v0.12 and we now want to migrate to a machine that only has libtpms v0.9 without the crypto algorithm, applications or kernel drivers would not be able to use the crypto algorithm anymore and en- or decrypt data. So just loosing functionality when downgrading is generally not an option.

The solution may be to extend the code in such a way that one can run libtpms v0.12 'at the level' of libtpms v0.9. This means that all additional algorithms that were added between v0.9 and v0.12 can be made inaccessible and invisible, meaning applications neither can use these algorithms nor that the TPM 2.0 would advertise these algorithms as available. But this also means that a version of libtpms later than v0.9 must be able to write the state in the format understandable to the previous version, so libtpms v0.12 needs to be able to write the state understandable for v0.9. And of course, for this all to work the user or cloud admin has to know at which level to run libtpms so that this whole downgrading story has a chance to work.

A couple of concerns that arise out of this:

1. What effects does this have on the code when future extensions need to be made accessible or invisible? I cannot predict how the TPM 2 code will evolve but it has algorithm agility and could theoretically be extended in many ways. futureTPM tries to add quantum-safe crypto to TPM 2 for example.
2. How does one test this then?

Committing to downgrading of state considering unknown future evolution of the TPM 2 code is 'difficult' also considering the fact that it's a complicated device already and testing just its plain functionality is quite an involved process just to begin with. Now we would need to put emphasis on testing of downgrading of state...

So, the following options exist:

1. Libtpms v0.9 is the last version. It's currently more advanced than any TPM 2.0 out there and implements the latest revision of the spec, revision 164. Eventually all systems will be on libtpms v0.9 level and downgrading won't be an issue.
2. Libtpms gets further developed as before but it is the sole responsibility of the distros to package future versions of libtpms and ensure that their migration requirements are met. Libtpms will not commit to downgrading of state.
3. We (additional maintainers required) commit to downgrade-ability of libtpms as outlined above (unless of course someone else comes up with a better definition).

Hi, the build of libtpms does currently not work in Debian 9.

As far as I understood, in Debian openssl must be used, since libnss is missing a header in Debian.

configure: error: nss-softokn-freebl-devel/libnss3-dev is missing blapi.h

Anyway, the current build does not work. The APIs for openssl changed, so the RSA struct is no longer directly accessible.

https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes

Here is the build output:

debuild
 dpkg-buildpackage -rfakeroot -us -uc
dpkg-buildpackage: info: source package libtpms
dpkg-buildpackage: info: source version 0.6.0
dpkg-buildpackage: info: source distribution UNRELEASED
dpkg-buildpackage: info: source changed by Stefan Berger <[email protected]>

...

CFLAGS=-g -O2 -fdebug-prefix-map=/home/ar/repositories/libtpms=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Werror -Wreturn-type -Wsign-compare
HARDENING_CFLAGS=-fstack-protector-strong -Wl,-z,relro -Wl,-z,now
LDFLAGS=-Wl,-z,relro

Version to build : 0.6.0
Crypto library   : openssl
Debug build      : no

...


libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time -D_FORTIFY_SOURCE=2 -include tpm_library_conf.h -I../include/libtpms -fstack-protector-strong -Wl,-z,relro -Wl,-z,now -DTPM_V12 -DTPM_PCCLIENT -DTPM_VOLATILE_LOAD -DTPM_ENABLE_ACTIVATE -DTPM_AES -DTPM_LIBTPMS_CALLBACKS -DTPM_NV_DISK -DTPM_POSIX -g -O2 -fdebug-prefix-map=/home/ar/repositories/libtpms=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Werror -Wreturn-type -Wsign-compare -c tpm12/tpm_svnrevision.c  -fPIC -DPIC -o tpm12/.libs/libtpms_tpm12_la-tpm_svnrevision.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time -D_FORTIFY_SOURCE=2 -include tpm_library_conf.h -I../include/libtpms -fstack-protector-strong -Wl,-z,relro -Wl,-z,now -DTPM_V12 -DTPM_PCCLIENT -DTPM_VOLATILE_LOAD -DTPM_ENABLE_ACTIVATE -DTPM_AES -DTPM_LIBTPMS_CALLBACKS -DTPM_NV_DISK -DTPM_POSIX -g -O2 -fdebug-prefix-map=/home/ar/repositories/libtpms=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Werror -Wreturn-type -Wsign-compare -c tpm12/tpm_svnrevision.c -o tpm12/libtpms_tpm12_la-tpm_svnrevision.o >/dev/null 2>&1
/bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2 -include tpm_library_conf.h -I../include/libtpms -fstack-protector-strong -Wl,-z,relro -Wl,-z,now  -DTPM_V12 -DTPM_PCCLIENT -DTPM_VOLATILE_LOAD -DTPM_ENABLE_ACTIVATE -DTPM_AES -DTPM_LIBTPMS_CALLBACKS -DTPM_NV_DISK -DTPM_POSIX  -g -O2 -fdebug-prefix-map=/home/ar/repositories/libtpms=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Werror -Wreturn-type -Wsign-compare -c -o tpm12/libtpms_tpm12_la-tpm_crypto.lo `test -f 'tpm12/tpm_crypto.c' || echo './'`tpm12/tpm_crypto.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time -D_FORTIFY_SOURCE=2 -include tpm_library_conf.h -I../include/libtpms -fstack-protector-strong -Wl,-z,relro -Wl,-z,now -DTPM_V12 -DTPM_PCCLIENT -DTPM_VOLATILE_LOAD -DTPM_ENABLE_ACTIVATE -DTPM_AES -DTPM_LIBTPMS_CALLBACKS -DTPM_NV_DISK -DTPM_POSIX -g -O2 -fdebug-prefix-map=/home/ar/repositories/libtpms=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Werror -Wreturn-type -Wsign-compare -c tpm12/tpm_crypto.c  -fPIC -DPIC -o tpm12/.libs/libtpms_tpm12_la-tpm_crypto.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time -D_FORTIFY_SOURCE=2 -include tpm_library_conf.h -I../include/libtpms -fstack-protector-strong -Wl,-z,relro -Wl,-z,now -DTPM_V12 -DTPM_PCCLIENT -DTPM_VOLATILE_LOAD -DTPM_ENABLE_ACTIVATE -DTPM_AES -DTPM_LIBTPMS_CALLBACKS -DTPM_NV_DISK -DTPM_POSIX -g -O2 -fdebug-prefix-map=/home/ar/repositories/libtpms=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Werror -Wreturn-type -Wsign-compare -c tpm12/tpm_transport.c -o tpm12/libtpms_tpm12_la-tpm_transport.o >/dev/null 2>&1
tpm12/tpm_crypto.c: In function ‘TPM_RSAGenerateKeyPair’:
tpm12/tpm_crypto.c:362:9: error: ‘RSA_generate_key’ is deprecated [-Werror=deprecated-declarations]
         rsa = RSA_generate_key(num_bits, e, NULL, NULL);                /* freed @1 */
         ^~~
In file included from /usr/include/openssl/asn1.h:15:0,
                 from /usr/include/openssl/rsa.h:16,
                 from /usr/include/openssl/engine.h:24,
                 from tpm12/tpm_crypto.c:50:
/usr/include/openssl/rsa.h:193:1: note: declared here
 DEPRECATEDIN_0_9_8(RSA *RSA_generate_key(int bits, unsigned long e, void
 ^
tpm12/tpm_crypto.c:370:58: error: dereferencing pointer to incomplete type ‘RSA {aka struct rsa_st}’
         rc = TPM_bn2binMalloc(n, &nbytes, (TPM_BIGNUM)rsa->n, num_bits/8); /* freed by caller */
                                                          ^~
cc1: all warnings being treated as errors
Makefile:1075: recipe for target 'tpm12/libtpms_tpm12_la-tpm_crypto.lo' failed
make[3]: *** [tpm12/libtpms_tpm12_la-tpm_crypto.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/home/ar/repositories/libtpms/src'
Makefile:501: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/ar/repositories/libtpms'
Makefile:408: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/home/ar/repositories/libtpms'
dh_auto_build: make -j4 returned exit code 2
debian/rules:6: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
debuild: fatal error at line 1116:
dpkg-buildpackage -rfakeroot -us -uc failed

The first error can be avoided when removing -Werror from the relevant Makefile. The second one can be fixed by using the new approach how to access the rsa struct.
I.e.:

369     if (rc == 0) {                                                                                                                                                                                                                     
370         const BIGNUM *nn;                                                                                                                                                                                                              
371         RSA_get0_key(rsa, &nn, NULL, NULL);                                                                                                                                                                                            
372         rc = TPM_bn2binMalloc(n, &nbytes, (TPM_BIGNUM) nn, num_bits/8); /* freed by caller */                                                                                                                                          
373     }                                                                                                                                                                                                                                  
374     /* load p */                                                                                                                                                                                                                       
375     if (rc == 0) {                                                                                                                                                                                                                     
376         const BIGNUM *np;                                                                                                                                                                                                              
377         RSA_get0_key(rsa, &np, NULL, NULL);                                                                                                                                                                                            
378         rc = TPM_bn2binMalloc(p, &pbytes, (TPM_BIGNUM) np, num_bits/16); /* freed by caller */                                                                                                                                         
379     }
...                                                                                                                                                                                                                                  

However, accessing the rsa structs happens quite often in the code. So I suppose applying these "workarounds" are not sufficient to properly adopt the code to the new API.

There is an unspecified external dependency on plbase64.h that generates a compile error. This should be caught during config and not during make.

tpm_library.c:49:23: fatal error: plbase64.h: No such file or directory

include <plbase64.h>

Describe the bug

The following compiler warning is emitted when compiling with gcc 10.3.0:

tpm2/NVDynamic.c: In function 'NvRamGetEnd':
tpm2/NVDynamic.c:378:12: warning: function may return address of local variable [-Wreturn-local-addr]
  378 |     return iter;
      |            ^
tpm2/NVDynamic.c:339:26: note: declared here
  339 |     NV_RAM_HEADER        header;
      |                          ^
tpm2/NVDynamic.c: In function 'NvRamGetIndex':
tpm2/NVDynamic.c:411:12: warning: function may return address of local variable [-Wreturn-local-addr]
  411 |     return currentAddr;
      |            ^
tpm2/NVDynamic.c:339:26: note: declared here
  339 |     NV_RAM_HEADER        header;
      |                          ^

Further examination of the code seems to indicate that this is a false positive and all memory addresses are within the array of s_indexOrderlyRam (also see here). The header variable in line 339 is used to copy data out of the NVRAM (for alignment purposes) and header.size is then accessed to advance the pointer to the next entry withing the s_indexOrderlyRam array.

Desktop (please complete the following information):

• OS: Pop OS!
• Version 21.04

Versions of relevant components

• libtpms: master branch

The current 'context gap' is only 0xff and would ideally be 0xffff. The context gap depends on this here:

src/tpm2/TpmProfile.h:#define CONTEXT_SLOT                    UINT8   /* libtpms: use 'old' type */

This should be UINT16 to get a context gap of 0xffff.
The only challenge here is to make it seamless for suspend / upgrade / resume operations.

This is part of state_reset_data:

CONTEXT_SLOT        contextArray[MAX_ACTIVE_SESSIONS];    // This array contains
// contains the values used to track
// the version numbers of saved
// contexts (see
// Session.c in for details). The
// default reset value is {0}.

with src/tpm2/TpmProfile.h:#define MAX_ACTIVE_SESSIONS 64

does it make sense to have a dockerfile in this repository to build the various distributions packages? e.g. for ubuntu 18.04.

Hi folks,

I noticed this week that when I reboot a VM accessing swtpm (running on the host) via qemu, any key created with tpm2_getpubek or tpm2_getpubak is erased in the process. The only exception is if this key is generated with swtpm_setup on handle 0x81010001.

I'm using:

• libtpms latest from tpm2-preview.rev146.v2 branch
• swtpm latest from tpm2-preview.v2 branch
• qemu from master
• host with ubuntu 16.04
• vm with ubuntu 16.04 (same behavior on 18.04) and seabios

I tried a few combinations and discovered that this happens after the commit 073849a at libtpms.

Is this the expected behavior? If so, is there anything else I should be doing to persist this keys?

Thanks!

Hello, Coverity has pointed out that that BN_div() is called in InitOpenSSLRSAPrivateKey() without checking the return value for an error.

Thanks

dpkg-buildpackage results in a lot of wanrings on Debian Bullseye

 fakeroot debian/rules clean
dh clean --parallel --with autotools-dev --with autoreconf
dh: warning: Compatibility levels before 10 are deprecated (level 9 in use)
dh: warning: The autotools-dev sequence is deprecated and replaced by dh in debhelper (>= 9.20160115)
dh: warning: This feature will be removed in compat 12.
   dh_auto_clean -O--parallel
dh_auto_clean: warning: Compatibility levels before 10 are deprecated (level 9 in use)
   dh_autotools-dev_restoreconfig -O--parallel
dh_autotools-dev_restoreconfig: warning: Compatibility levels before 10 are deprecated (level 9 in use)
dh_autotools-dev_restoreconfig: warning: dh_autotools-dev_restoreconfig is deprecated; please see dh_autotools-dev_restoreconfig(1) for a replacement
dh_autotools-dev_restoreconfig: warning: This feature will be removed in compat 12.
   dh_autoreconf_clean -O--parallel
   dh_clean -O--parallel
dh_clean: warning: Compatibility levels before 10 are deprecated (level 9 in use)
 dpkg-source -b .
dpkg-source: info: using source format '3.0 (native)'
dpkg-source: info: building libtpms in libtpms_0.9.0~dev1.tar.xz
dpkg-source: info: building libtpms in libtpms_0.9.0~dev1.dsc
 debian/rules build

Hello, I have another question, when I run the following tpm command using tpm2-tools, I got 0x2d2.
tpm2 create -C primary.ctxt -g sha256 -G rsa -r key.prv -u key.pub -L policy.dat -a "sensitivedataorigin"
I found it returns this error code in PublicAttributesValidation function:

    // See if sign and decrypt are the same
    if(IS_ATTRIBUTE(attributes, TPMA_OBJECT, sign)
       == IS_ATTRIBUTE(attributes, TPMA_OBJECT, decrypt))
	{
	    // a restricted key cannot have both SET or both CLEAR
	    if(IS_ATTRIBUTE(attributes, TPMA_OBJECT, restricted))
		return TPM_RC_ATTRIBUTES;
	    // only a data object may have both sign and decrypt CLEAR
	    // BTW, since we know that decrypt==sign, no need to check both
	    if(publicArea->type != TPM_ALG_KEYEDHASH
	       && !IS_ATTRIBUTE(attributes, TPMA_OBJECT, sign))
		**return TPM_RC_ATTRIBUTES; // error code return**
	}

However, in Trusted Platform Module Library Part 1: Architecture, there are the following descriptions:
Revision 148
Reworked the attestation key certification to indicate that an encrypted challenge response is a more likely use case than an encrypted certificate.
Field upgrade should not affect TPM2_CreatePrimary() outputs under certain conditions.
The reset of the TIme circuit is related to TPM power, not TPM_Init.
MAX_SYM_DATA 128 changed from shall to should.
sign and decrypt both CLEAR or SET and scheme not TPM_ALG_NULL returns TPM_RC_SCHEME.
TPM2_PCR_Allocate() takes effect at _TPM_Init(), not TPM2_Startup().

so is whether the error code inconsistent with the TCG standard?

Hello, the test data of SM4 is from IEIF (https://tools.ietf.org/html/draft-ribose-cfrg-sm4-04#appendix-A.2). The Iv is inconsistent with libtpms，so do we need to modify the dataOut_SM4128_CTR or MakeIv founction?

In the version 0.7.4, in the debian/changelog file there is an error which prevent the debian package building.
There is a misspell of the package name: litpmss instead of libtpms
Below the diff to correct it

diff --git a/debian/changelog b/debian/changelog
index 5df4344..42549b8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,4 @@
-litpmss (0.7.4) RELEASED; urgency=medium
+libtpms (0.7.4) RELEASED; urgency=medium

• Addressed potential constant-time issues in TPM 1.2 and TPM 2 code

TPM related failing test cases are:

• ECDSASignValidate
• ECDHSecretAgreementTest

Modify the TPM 2 code to allow for RSA keys with 3072 bits.