Per "TCG FIPS 140-3 guidance for TPM 2.0" document the following functions
must prevent an asymmetric ECC key derivation:
- Table 14: TPM2_CreateLoaded
- Table 18: TPM2_ZGen_2Phase
- Table 26: TPM2_Commit
- Table 26: TPM2_EC_Ephemeral
Return TPM_RC_TYPE as a return code to indicate failure of deriving a key.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Add new field hierarchy to OBJECT and assign values to it and access it.
Beyond the sync with upstream we need to also set the hierachy when
- an older OBJECT is converted to the current OBJECT
- an OBJECT is unmarshalled
Remove ObjectGetHierarchy since it is not needed anymore.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
The maximum SEED_COMPAT_LEVEL that libtpms may use depends on the earliest
version of libtpms that a profile can run on. Therefore, implement
RuntimeProfileGetSeedCompatLevel() to determine the SEED_COMPAT_LEVEL that
a profile can use, which depends on the profile's stateCompatLevel (which
in turn depends on the version of libtpms)
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Add a simplified version of HierarchyNormalizeHandle that simply returns
the passed handle and sync the callers with upstream.
HierarchyNormalizeHandle will be extended at some later point.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
When a child key is derived from an Object, we need to know what
SEED_COMPAT_LEVEL the Object was created under (or what the its seed is)
so that we can later on derive child with the appropriate
SEED_COMPAT_LEVEL.
When an external object is loaded we set the SEED_COMPAT_LEVEL to
SEED_COMPAT_LEVEL_ORIGINAL so that any RSA key that could possibly be
derived from it will always create the same RSA key independent
of the SEED_COMPAT_LEVEL of the hierarchy it is loaded under. This
way any key derivation that could happen on an external key remains
the same before and after this code change.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Add a SEED_COMPAT_LEVEL to the DRBG state that is associated with the seed
and indicates the seed compatibility level we need to maintain when deriving
RSA keys from seeds. We only need to be able to handle RSA keys derived via
the DRBG state. Other keys, such as symmetric keys, are not affected. Also
RSA keys cannot be derived from a KDR, so the KDF does not need to carry
the SEED_COMPAT_LEVEL.
All functions that need to pass a value set SEED_COMPAT_LEVEL to
SEED_COMPAT_LEVEL_ORIGINAL (0) for now.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
This patch addresses the following valgrind issue detetcted by swtpm test suite:
== Syscall param write(buf) points to uninitialised byte(s)
==3515669== at 0x4DC14B7: write (in /usr/lib64/libc-2.30.so)
==3515669== by 0x48547FB: write_full (utils.c:242)
==3515669== by 0x48548F3: writev_full (utils.c:301)
==3515669== by 0x48520A6: SWTPM_IO_Write (swtpm_io.c:229)
==3515669== by 0x4850662: mainLoop (mainloop.c:282)
==3515669== by 0x402BE7: swtpm_main (swtpm.c:497)
==3515669== by 0x4CF61A2: (below main) (in /usr/lib64/libc-2.30.so)
==3515669== Address 0x52413a2 is 34 bytes inside a block of size 2,006 alloc'd
==3515669== at 0x483980B: malloc (vg_replace_malloc.c:309)
==3515669== by 0x48548A1: writev_full (utils.c:287)
==3515669== by 0x48520A6: SWTPM_IO_Write (swtpm_io.c:229)
==3515669== by 0x4850662: mainLoop (mainloop.c:282)
==3515669== by 0x402BE7: swtpm_main (swtpm.c:497)
==3515669== by 0x4CF61A2: (below main) (in /usr/lib64/libc-2.30.so)
==3515669== Uninitialised value was created by a stack allocation
==3515669== at 0x4953993: TPM2_Load (ObjectCommands.c:132)
==3515669==
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
