Future TPM support

[securitykernel]

The ToDo list currently lists this for TPM support:

• Better TPM support: NVRAM, PCR measurements, sealing
• Add support for TPM 2.0 hardware

Is the first one still desired? Given that TPM 1.2 standard was first released in 2003 and superseded by TPM 2.0 in 2014, I'd suggest to deprecate TPM 1.2 support for removal in 4.0 and add basic TPM 2.0 support as a replacement (if still desired).

[reneme]

Current Status

TPM 1.2 is deprecated as of 9000137. @atreiber94 and me will work on (limited) TPM 2.0 support.

Work Items

• Set up a test environment for CI (based on swtpm)
• TPM-based random number generator (Add TPM2 RNG #4117)
• Support asymmetric crypto for pre-existing keys on the TPM
  • RSA sign/verify
  • RSA encrypt/decrypt ❔
  • ECDSA sign/verify
  • ECDH (not in scope at the moment) ❔
• Support for X.509 Certificate Signing ❔
  See: Architecture Document, Section 31.6 (PDF-page 227)
• Key Management ❔
  • Creation
    • Transient key creation
    • Persist keys (after transient creation)
    • Offloadable keys (via TPM-encrypted blobs)
  • Import
    • existing non-TPM-generated key material ❔
    • offloaded (TPM-encrypted) key blobs
  • Deletion of persistent keys
• Convenient Session Management ❔
  • Password-protected
  • HMAC-Sessions
  • Policy-protection
  • Session Attributes (Encrypt/Decrypt, Audit, Resumption, ...)
  • Audit-Sessions (out of scope)
• Auxiliaries
  • Wrapper for TPM-based Hashes
    (needed internally, for abstraction in sign/verify)
  • Configurable Optional CPU-based hashing for Sign/verify
  • Configurable CPU-based padding for RSA sign/verify/encrypt/decrypt ❔
• Verification of Trust roots (Endorsement Certificate, Platform Certificate, Storage Root Key) -- currently not planned
• For tss2-tpm 4.0+: Use the crypto callbacks (to avoid depending on ossl or gnutls)
• FFI support
• Python bindings

Knowledge Space

This will require a new (optional) dependency to tpm2-tss. This library provides several layers of API abstraction:

• Feature API
  high-level API that manages TPM configuration and crypto profiles in *.json files and maintains a keystore directory structure on the system
• Enhanced System API (ESYS) (spec)
  abstracts session authorization and parameter encryption, needs a "crypto library" (OpenSSL, mbedTLS, or custom callbacks)
• System API
  basically just marshalling of TPM2 commands, no crypto library needed

The "Enhanced System API" is probably want we want. The "Feature API" seems very convenient but it maintains state on the user's hard drive and is quite obviously geared towards use in applications. We'll (optionally) implement the crypto callbacks to allow tpm2-tss to use Botan's primitives and to avoid a transitive dependency to another crypto library. Note that this requires the use of tpm2-tss 4.0 or newer (January 2023), before ESYS_SetCryptoCallbacks() is not available.