Builder Vault (TSM) Release 72.3.0
by Michael Bæksvang ØstergaardVersions
Node Configuration: 26.6
Client API: 62.3
Client Communication: 32.5
Database: 7.13.0
Node Communication: 34.2Changelog
Node Configuration:
- Added support for running MPC operations in a secure enclave. This is configured via the [Enclave] section.
- DKLS23 now supports NONE as the DeactivatedPlayersCache in addition to MEMORY and DATABASE.
Patch changes (no effect on compatibility):
- Made it possible to control for how long dynamic API keys are cached. Also changed the default from 10 to 30 seconds
- Make fewer calls to the database encryptorDetails
Secure Enclaves
We’ve added support for running MPC operations inside a secure enclave, providing stronger isolation and protection of key material.
Enclaves can be configured via the [Enclave] section by specifying the address and port of the enclave server. When enabled:
- All MPC operations and key material usage are handled within the enclave, separate from the rest of the TSM.
- The enclave encrypts sensitive data, ensuring that the TSM never has access to key material in clear text.
Because the enclave server is stateless, there are scenarios where key material could be exposed (e.g., by reusing a presignature or exporting keys). To mitigate this, the enclave can be restricted to allow only specific operations.
As part of this, a new option NONE has been added to the DeactivatedPlayersCache setting under [DKLS23]. When enabled, it prevents the use of precomputed data for sining, to match the setting configured within the enclave.
Note: The enclave server is distributed separately and is not bundled with the TSM.
Deactivated players
In DKLS23, it is possible to reuse certain key material data when signing and generating presignatures. This significantly improves performance by reducing computation time and protocol rounds.
However, this optimization introduces a trade-off: if a player is detected cheating during the protocol, any precomputed data associated with that key material must be discarded and never reused.
When such an event occurs, the protocol automatically falls back to a slower but fully secure mode until the key material is reshared.
To manage this, the TSM tracks which players have been deactivated due to cheating. The way this information is stored and accessed is controlled by the DeactivatedPlayersCache setting under [DKLS23].
Available Modes for DeactivatedPlayersCache
-
MEMORY The TSM keeps track of deactivated players in an in-memory data structure that is persisted to disk whenever updates occur.
Fastest method. Reloaded into memory at startup. Not suitable for load-balanced deployments.
-
DATABASE The TSM stores deactivated player information directly in the database.
Compatible with load-balanced scenarios. Slightly slower, as it requires a database lookup for each signing and presignature generation operation.
New in This Release
-
NONE The TSM does not reuse any precomputed data to speed up operations. Instead, it generates fresh data for each operation.
Completely eliminates attacks related to precomputed data. Comes with a significant performance overhead.
The NONE option should generally only be used, if one of the players are using an enclave that has disabled the use of precomputed data.