Skip to content

Latest commit

 

History

History
71 lines (60 loc) · 5.78 KB

arbitrary-secrets-overview.md

File metadata and controls

71 lines (60 loc) · 5.78 KB
Raw

Arbitrary Secrets

Lock Keeper should provide a general-purpose, human-centric system that stores and retrieves secrets on a single server.

Page Contents

  1. Assumptions and Requirements
  2. System Architecture
  3. Workflows
    1. Setting up secure channels with the key server
    2. Operations on arbitrary secrets
  4. Cryptographic Protocol and Implementation Dependencies

Assumptions and Requirements

  • The primary stakeholder is a human with secrets. We call this human an asset owner.
  • All workflows MUST be initiated from a local device owned and operated by a human, namely the asset owner.
  • There is only one key server. This key server is either run on external cloud infrastructure or hosted locally by a service provider.

System Architecture

See the Systems Architecture page for details.

There are two basic components: a client (which runs on an asset owner device and initiates all workflows) and a key server (which provides the storage and retrieval of arbitrary secrets). These components communicate over secure channels at all times.

Workflows

We provide sketches of the basic generation, storage, and use of arbitrary secrets below. These flows are initiated by the asset owner.

Setting up secure channels with the key server

See the Networking subsection on the Systems Architecture page for details.

  1. The asset owner may register with the key server via an asymmetric password-authenticated key exchange protocol.
    1. Registration MUST occur via a channel that satisfies authentication of the server, confidentiality, and integrity.
  2. The asset owner may open an authenticated session with the key server via an asymmetric password-authenticated key exchange protocol.
    1. Once established, the asset owner can make operation requests on secrets to the key server.
    2. The session MUST provide a secure channel that satisfies mutual authentication, confidentiality, and integrity.
  3. The asset owner may close a session that the asset owner previously established with the key server.

Operations on arbitrary secrets

See the Operations on Arbitrary Secrets page for details.

  1. The asset owner can generate secrets. Generation of secrets may be local or remote:
    1. The asset owner can generate a secret locally, i.e, using the client.
      1. This secret MUST be randomly generated according to the uniform distribution.
      2. This secret should default to 256-bits.
    2. The asset owner can request the key server to generate a secret remotely.
      1. This secret MUST be randomly generated according to the uniform distribution.
      2. This secret should default to 256-bits.
  2. The asset owner can store a secret.
    1. If the secret is generated locally, then the secret is by default stored both locally and at the key server.
    2. If the secret is generated remotely, then the secret is by default stored only at the key server.
    3. Storage on a key server MUST occur via a mutually authenticated channel that satisfies confidentiality and integrity.
    4. Local storage on the user's device should be secure.
    5. An additional functionality that allows the user to store secrets on the remote key server only WILL be added in the future.
    6. An additional functionality that allows the user to store secrets on the local device only may be added in the future.
  3. The asset owner can retrieve a secret from the key server.
    1. Retrieval from a key server MUST occur via a mutually authenticated channel that satisfies confidentiality and integrity.
    2. The key retrieved MUST be a key associated to the authenticated user.
    3. A retrieved secret can be:
      1. Stored locally in secure storage on the user's device.
      2. Copied to the system clipboard.
  4. The asset owner may import a secret to the system in an appropriate format.
    1. The default expected format is as bytes of the form len || secret, where len is 1 byte that represents the length of the secret secret in bytes.
    2. The implementation may define other acceptable import formats.
    3. Any communication with the key server that occurs in serving an import request MUST occur via a mutually authenticated channel that satisfies confidentiality and integrity.
  5. The asset owner may export the secret from the system. The export format for the key SHOULD allow for easy transfer of the key material to another digital asset management system, i.e., secrets should be portable.
    1. The default expected format is as bytes of the form len || secret, where len is 1 byte that represents the length of the secret secret in bytes.
    2. The implementation may define other acceptable export formats.
    3. Any communication with the key server that occurs in serving an export request MUST occur via a mutually authenticated channel that satisfies confidentiality and integrity.
  6. The asset owner may audit the operations performed by the key server on a given secret. This allows the asset owner to retrieve a log of operations from the key server.
    1. Audit log retrieval MUST occur via a mutually authenticated channel that satisfies confidentiality and integrity.
    2. Audit logs should be portable, i.e., easily exportable from the system.
    3. Non-normative note: Given the above properties, we do not achieve integrity of the audit logs in the presence of a cheating key server. Future work may address this concern.