Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend TPM 2.0 support #3877

Open
securitykernel opened this issue Jan 8, 2024 · 2 comments
Open

Extend TPM 2.0 support #3877

securitykernel opened this issue Jan 8, 2024 · 2 comments
Assignees
Labels
enhancement Enhancement or new feature

Comments

@securitykernel
Copy link
Collaborator

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).

randombit added a commit that referenced this issue May 11, 2024
In #3910 we introduced a nice way of marking specific modules as
deprecated. However this change did not set the lifecycles of any
specific modules.

Additionally, officially deprecate the TPM support which is pretty
obsolete and these days not well tested. (GH #3877)
randombit added a commit that referenced this issue May 11, 2024
In #3910 we introduced a nice way of marking specific modules as
deprecated. However this change did not set the lifecycles of any
specific modules.

Additionally, officially deprecate the TPM support which is pretty
obsolete and these days not well tested. (GH #3877)
randombit added a commit that referenced this issue May 11, 2024
In #3910 we introduced a nice way of marking specific modules as
deprecated. However this change did not set the lifecycles of any
specific modules.

Additionally, officially deprecate the TPM support which is pretty
obsolete and these days not well tested. (GH #3877)

Mark various headers and classes that are entirely deprecated as such
to provide some additional compile time warning for users.
randombit added a commit that referenced this issue May 11, 2024
In #3910 we introduced a nice way of marking specific modules as
deprecated. However this change did not set the lifecycles of any
specific modules.

Additionally, officially deprecate the TPM support which is pretty
obsolete and these days not well tested. (GH #3877)

Mark various headers and classes that are entirely deprecated as such
to provide some additional compile time warning for users.
@reneme
Copy link
Collaborator

reneme commented Jun 5, 2024

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
  • 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.

@reneme
Copy link
Collaborator

reneme commented Oct 17, 2024

Current Situation

The pull requests merged so far (slated for release with Botan 3.6.0) provide limited support to create and use TPM-hosted keys (both RSA and ECDSA), as well as an interface to the TPM's random number generator. Also, a feature-complete "crypto backend" (requires TSS 4.x) was added. With that, the underlying TSS can utilize Botan's crypto algorithms for securely communicating with the TPM.

Below there's a list of current limitations (adapted from #4337) that may stand as an (incomplete) list of TODOs. Currently we don't have immediate plans to tackle any of those, but that may change. Therefore, this ticket is not assigned to any release milestone for the time being.

Limitations aka. TODO

  • Configuration of key pair properties on creation (perhaps based on #4318)
    • Restrict key usage (sign vs. X.509 certification vs. verify)
    • Restrict signature schemes (e.g. signing only with PSS)
    • Duplicatability ("fixed to TPM", "fixed to parent key")
    • Usage restrictions
    • Hierarchies (currently only "Owner")
    • Primary and/or Derived Keys (currently only "Ordinary" Keys)
    • ...
  • Sessions
    • Audit sessions
    • Policy sessions
    • for existing HMAC-sessions: allow specifying a "caller nonce"
  • Verification of the TPM
    • Access/Validate the Endorsement Key and its Certificate
    • Access/Validate the platform certificate
  • Access to NVRAM
  • Symmetric Cryptography
  • Measurements/PCRs
  • Remote Attestation
    • e.g. to certify a key pair via X.509-sign

@reneme reneme changed the title Future TPM support Extend TPM 2.0 support Oct 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Enhancement or new feature
Projects
None yet
Development

No branches or pull requests

3 participants