Scope and plan for PSA Cryptoprocessor Driver Interface 1.0

[athoelke]

This is a more complete outline of the changes and additions to the Driver Interface that are expected before we finalize version 1.0. The banner in the document itself only highlights the major changes in the interface.

In scope for v1.0.0

General

• Glossary of terms

• Updated and extended requirements definition

• Expanded overview of the implementation architecture

  • Definition of components and interfaces

• Level of detail and 'polish' lower than in other API specs for v1.0.

Driver interface

• Driver initialisation
• Full coverage of cryptographic operations
  • All of Crypto API v1.3, including PQC
  • v1.4 content
    • Definitely: WPA3-SAE, Xof, key-wrap
    • TBD: Ascon, contexts for signature
  • Patterns for deriving driver/dispatch interface design from Crypto API specification
  • Details for complex operation types
    • PAKE & KDF : propose to adopt the designs from Oberon PSA Crypto
• Key management
  • Import/export
  • Key generation
  • Copy
  • Destroy key
  • Handling of built-in/platform keys
• RNG/Entropy
  • Simple single-driver-source design
  • But might need to permit more complex designs?
• Responsibility for validation
  • What validation must be done by the Core, and what validation must be done by a driver entry-point?

Dispatch interface

• Define the interface between the Core and the Dispatch logic
  • Function definitions to match the Driver interface
• Coverage to match Driver interface
  • But also key capability queries
• Description of common alternative implementations, e.g. hash + sign-hash for sign-message

Driver description/manifest

• Coverage of all features in Driver interface
• Question of whether this remains beta in v1.0?

Other interfaces

• Platform interface Identified in the spec
  • For example, concurrency support
  • Content will be TBD/alpha/beta in v1.0?
• Crypto utilities identified in the spec
  • For example, memory-scramble, constant-time 'is same'.
  • Content will be TBD/alpha/beta in v1.0?

Interface filename conventions

• Required for integration with Core implementations
  • Might be TBD/alpha/beta in v1.0?

Not in v1.0.0 specification

Validation/testing/compliance

The timeline for test suites should be decoupled from that of the v1.0 specification.

• Development of a new test suite for the Driver interfaces.
• Will need to define the requirements for such a test suite.

Topics for future versions of the specification

• Deinitialization
• Complex RNG
• Final platform or utility interface definitions.
• Driver description finalised and proven
  • Coverage
  • Configuration
  • Naming conventions
• PSA_WANT_XXX configuration mechanism. RiOT has its own model for this.
• Interruptible operations
• Robust handling of distributed transaction between secure element that stores key material and core storing key index/metadata.