User Onboarding and Recovery

In the TrustBloc environment, KMS server is used as an authorization KMS for supporting ZCAP-LD scheme and as an operational KMS for regular user’s crypto operations.

Both are part of the user onboarding flow in the Wallet.

../_images/onboard_user_flow.png

Authorization KMS

Authorization KMS allows creating Controller identity (identified by a cryptographic key pair) and then using it for signing requests in a ZCAP-LD authorization model.

The key store for the Controller uses the server’s database for storing keys. These keys are encrypted with a Shamir secret lock.

To unlock a key store, the controller’s secret share needs to be present in a Secret-Share header for every request. The other share comes from the Auth server. The URL of the server is configured with KMS_AUTH_SERVER_URL environment variable (or --auth-server-url flag).

Server Key Manager is protected with a Local secret lock.

Operational KMS

Operational KMS manages users’ working keys and supports crypto operations with those keys.

Keys are protected with a Local secret lock and saved to the EDV server provided by the user. EDV parameters are specified in the request upon creating a key store. Refer to the Storage section for the details.

Recipient and MAC keys for accessing an EDV server are stored in Server Key Manager. A primary key for the user’s key store lock is also saved here.

Operational KMS uses ZCAP-LD authorization scheme. Requests are expected to be signed with the Authorization KMS.

Server Key Manager is protected with an AWS secret lock.

Oathkeeper

Certain KMS endpoints are protected with the OAuth scheme. TrustBloc uses Oathkeeper as an authorization proxy in front of KMS services to protect the following endpoints:

  • POST /v1/keystores for creating a key store;

  • POST /v1/keystores/did for creating a DID (e.g. controller for EDV).

An example configuration for Authorization KMS can be found here.

Recovery

Planned functionality.