Security Overview

This page tries to give an overview of the TSM, including some details about the low level cryptographic details.

Recall that the TSM consists of a number of MPC nodes. Each MPC node is controlled by its own SDK. Via the SDKs users can instruct the MPC nodes to do various MPC operations such as key generation and signing. If so, the MPC nodes connect via pairwise channels to execute secure multiparty (MPC) protocols. Key generation results in each MPC node generating its own secret share of the key. Each MPC node connects to its own database where it stores, among other things, its own key shares.

MPC Node Configuration and Database

In addition to it's database, each MPC node has a configuration file which contains information about how to communicate with the other MPC nodes (its own private key and the URLs and public keys used to establish secure connections to the other MPC nodes), information about how to connect to its database, how to encrypt its sensitive database contents, which MPC protocols to use, etc.

When starting an MPC node the EncryptorMasterPassword (or the EncryptorKeyFile) from the configuration file is used to derive a key encryption key (KEK) using PBKDF2. This KEK is used to decrypt the master encryption key (MK) stored in the database (automatically generated on first startup). When encrypting and decrypting sensitive database content such as key shares, a content encryption key (CEK) is derived from the MK and some additional (non secret) data (i.e. KeyID) using HKDF. The actual data is encrypted under this CEK. All encryptions are done using AES-GCM with 256 bit keys.

This encryption method can also be used to encrypt the configuration file itself, with exception of the database section as that is needed to instantiate the encryptor. To avoid having the encryption password stored in the clear, the database encryption key can also be read from a file (e.g. on a USB stick that is only present during startup) or read from the command line.

Randomness and Entropy

The source of randomness is Go's rand package, thus the concrete details will depend on the underlying system/environment, e.g.,

  • Linux, FreeBSD: getrandom(2) if available, /dev/urandom otherwise
  • OpenBSD: getentropy(2)
  • Unix-like systems: /dev/urandom
  • Windows: CryptGenRandom API

A version of the TSM based on a platform consisting of Go and BoringCrypto running on Intel hardware is currently in the process of being FIPS-140-3 certified. BoringCrypto is FIPS-140-2 certified and on an Intel platform, the DRBG utilizes RDRAND, which is also FIPS-140-2 certified.

When generating keys in the TSM this will draw upon the described entropy sources at each MPC node. During key generation a node only learns its own share, and the full key is never assembled or available.

Secure Channels between the MPC Nodes

  • If the TSM is configured for direct TLS connections, the MPC nodes will establish secure pairwise connections via 2-way TLS v1.3. The MPC nodes use their private key from the configuration file to set up their TLS server, and the public keys for the other nodes to do public key pinning, i.e. we do not rely on a certificate authority.
  • If the TSM is configured to use a message broker, each MPC node will establish a secure TLS connection with the message broker. The secure termination is terminated at the message broker, but the MPC nodes will apply an additional layer of encryption on top the TLS, meaning that the message broker will not be a trusted party.

SDK Authentication

Each MPC node is controlled by an SDK. The SDK connects to its MPC node using HTTP or HTTPS.

If HTTPS is used, the SDK will validate the MPC node’s certificate using the certificate store from the operating system (public key pinning is also possible). HTTP is not recommended in production unless the communication channel is secured in some other way, or for example in a setup where HTTPS is terminated in a load balancer in front of the node.

The SDK authentication method can be configured in the MPC node’s configuration file:

  • If API key authentication is used, the SDK then sends the API key over the channel and gets a JWT token back. The JWT token lifetime can be configured in the MPC node configuration files.
  • Alternatively, SDKs can be authenticated using TLS. In this case the connection between the SDK and the MPC node will be a 2-way TLS where not only the MPC node, but also the SDK holds a private key.
  • A third alternative is to configure the MPC node to use OIDC, where the SDK is authenticated via a 3rd party OIDC provider, such as Google or Auth0.

SDK authenticating with API keys requires the API keys to be written in the the MPC node configuration files, along with the application ID to which the API key maps. In the case of 2-way TLS and OIDC authentication, applications are created the first time their client certificate passes authentication. The application ID is a hash of the distinguished name (DN) or the OIDC identifier.

Execution of MPC Protocols

When the TSM run distributed MPC protocols the MPC nodes exchange a number of messages in order to generate keys or produce signatures or encryptions using the generated keys. The keys are stored as secret sharings between the MPC nodes.

To run a distributed MPC protocol (such as generating an RSA or ECDSA signature on a message), each of the MPC nodes in the TSM must be told to start the given operation via an SDK call to e.g. SignPKCS1v15. For this to work, the SDK operators (which may belong to different organizations) need to agree on a unique session ID. Each SDK operator must then call SignPKCS1v15 on his own SDK using this session ID. Note that this means that an RSA signature can only be generated on a given message if an (authorized) SDK operator at each MPC node agrees to call the SignPKCS1v15 method on its SDK for that message.

The operations allowed can be controlled via the MPC node config file. E.g., to enable RSA signatures, the MPC configuration file has to contain a section that enables the RSA MPC protocol.

When a session is about to start, all nodes compare their metadata about the session (including a hash of the message to sign, if it is a signing operation), and abort the session if there is a disagreement about which operation is about to be performed.

Dynamic Node Configuration (MPC Node Multi-Tenancy)

The TSM allows the public keys used for establishing secure connection between the MPC nodes to be provided dynamically, when the MPC session starts. This can be used to implement MPC Node “multi-tenancy”, where some MPC nodes remain static, while there can be many instances of other MPC nodes. A typical setup will involve one or two static nodes running as servers, and one multi-tenant node run on a mobile device. The static MPC nodes may decide to accept executing an MPC protocol with a specific mobile device by providing the public key for that device as part of the MPC session configuration when a key or signature is to be generated.

If MPC nodes communicate with direct TLS connections, only one of the nodes can be dynamically configured. If using a message broker, any subset of MPC nodes can be dynamically configured, even all of them.