Crypto and KMS as pluggable Service Provider Interfaces

The goal of the integration of crypto and KMS components in Aries framework is to provide a pluggable service providers interfaces for Cryptographic operations such as Encryption, Decryption, Signing and Verification as well as keys management operations usually offered by a KMS (Key Management Service).

Aries Agents should be able to plugin a Crypto module and a KMS module and use their services regardless of their detailed implementation. This will help integrate crypto operations as well as manipulating and querying keys in an agent with minimal change.

Tink, a library created to make crypto easy for non cryptographers, is a strong candidate that offers pluggability of crypto operations and supports integration with multiple KMS solutions like AWS KMS, GCP (Google Cloud KMS), HashiCorp Vault and Android Keystore KMS. It supports multi languages including Go. Tink serves to wrap the crypto functions in a KMS, so the client cannot see secrets, and so the client works with a simpler API that makes it harder to break your crypto. It also supports key wrapping using ECDH, but it does not match ECDH-1PU which will require additional work.

The plan is to have a new service provider interface (SPI for short) to handle Crypto and KMS operations. These operations will serve as wrapper to Tink primitive functions like Encrypt(), Decrypt(), Sign(), Verify(), GenerateKey(), DisableKey(), etc. See Diagram below that depicts the design of this Aries Crypto framework. In this diagram, Tink's Crypto primitives are used directly in the Crypto SPI default implementation and will use a KMS implementation provided by Tink directly (Phase 1). The second part of the diagram provides a more generic KMS interface that is not directly tied to Tink to allow for third party KMS integrations (Phase 2). In order to maintain compatibility with Tink, an adapter is required to translate the KMS implementation with Tink's Crypto primitives (ie translate keys into *keyset.Handle instances). Phase 2 can be done at a later stage once the first phase is completed.

The introduction of Tink begins with Crypto interface for which a, default, implementation will use Tink primitives for the crypto operations. Tink will need to be updated to use a custom AEAD cipher with key wrapping using ECDH-1PU. The implementation will somewhat resemble the Hybrid AEAD one in Tink with the difference in the key derivation function differs in 1PU (here) than the conventional and standardized HKDF (example here and defined here) mode.

In Tink, operations are isolated in a distinguished interface grouped by the type of crypto used. There are interfaces for deterministic aead (payload re encryptions yield the same output, this implementation is not recommend), aead (direct mode, no key wrapping), hybrid aead (with key wrapping including key derivation defined as ECDH-ES), signatures and MAC hashing. For the purpose of Aries Agents, only AEAD, Signer and Verifier primitives will be used. The implementation of 1PU will require additional work to see if a new Tink primitive is required or can be implemented separately in the Crypto plugin.