Builder Vault (TSM) Release 70.2.3 LTS
by Torben LauritzenBuilder Vault (TSM) Release 72.0.0
by Torben LauritzenVersions
Client API: 62.1
Client Communication: 32.1 (!)
Database: 7.12.0
Node Communication: 34.2
Node Configuration: 26.3 (!)
Changelog
Node Communication:
- Added a new MPC TCP communication method
Node Configuration:
- Added support for dynamic API keys via the management server
- Added PacketCommunication method to the MPC TCP server, as well as corresponding
configuration options to the [Players.X] sections
- Allow getting the client IP address from the IPAddressHeader field of the log configuration
- Moved Configuration of metrics to the management server configuration. Profiling is enabled
by adding '-tags profile' when building.
- Added Management Server configuration
Client API:
- Added support for AN10922, RFC5649 and AES-CMAC to SDKv2
Client Communication:
- Added management API endpoints for dynamic API keys
- Moved Metrics and Profiling endpoints to 'management/metrics' and
'management/profiling/debug/[fgprof|pprof]' respectively
- Added Management API endpoints
- Added endpoints for AN10922, RFC5649 and AES-CMAC to SDKv2
Patch changes (no effect on compatibility):
- Upgraded Android NDK in BD_IMAGE from r22 to r28c to build for 16kB page size
Details
SDKv2 support for AN10922, RFC5649, and CMAC
These operations were available on the legacy SDKv1, and are now also supported by SDKv2.
Compared to the "client api" of SDKv1, there are a few changes to import of AN10922 and RFC5649 keys:
- Import now accepts a "desiredKeyID" like other key import methods in SDKv2.
- Both methods require imported keys to be envelope wrapped
- A threshold parameter is accepted (though both currently only work for three MPC nodes and threshold one)
Administrative endpoints have been moved to Management Server
The endpoints for retrieving TSM information, health status, and metrics have been moved to a common Management Server. This change also adds permissions-based access control, which must be configured in the TSM node configuration file.
After the change, the endpoints can be found here:
/management/health (needs permission "HEALTH")
/management/metrics (needs permission "METRICS")
/management/configuration/authinfo (needs permission "TSMINFO")
/management/configuration/auditsigningpublickey (needs permission "TSMINFO")
Dynamic API keys
The [Authentication] section now includes a DynamicAPIKeys option, which enables the use of dynamic API keys. This option is disabled by default.
When DynamicAPIKeys is enabled, all API key management must be done through the Management Server API. This includes creating, deleting, and listing API keys.
Create API Key
POST /management/apikey
Required permission: APIKEY
Delete API Key
DELETE /management/apikey/{apiKeyID}
Required permission: APIKEY
List API Keys
GET /management/apikey
Required permission: APIKEY
To create a new API key, send the following JSON payload in the request body:
{
"applicationId": "myapplication1",
"description": "this is application 1"
}Enabling dynamic API keys allows changes to be made at runtime without restarting the system. When deployed across multiple MPC nodes, changes (such as adding or removing keys) may take up to 10 seconds to propagate to all nodes.
Note that these endpoints allow management of API keys related to normal TSM operations, not the API keys used for accessing the Management Server API.
PacketCommunication feature added to the MPC TCP server
A new TCP communication method (enabled by setting PacketCommunication = true under the MPCTCPServer configuration) has been added.
It switches the TCP transport from a stream‑oriented model to a packet‑framed protocol identical to the existing message‑broker format.
The new protocol has the following benefits:
- Slightly lower overhead when starting MPC sessions.
- Gives fine‑grained control over who dials whom: instead of the fixed “lower index connects up” rule.
- Unifies the communication format, which might in the future enable deployments that mix TCP and broker‑based transports.
It is worth noting that most existing deployments using the MPCTCPServer, cannot simply enable this feature without making changes to the [Players.X] sections. Notably, the following options have been added to the players configurations:
- disableMultiplexing: When PacketCommunication = true, multiplexing can be toggled per player, allowing you to save resources for rarely used peers or when a load balancer would break sticky TCP sessions.
- symmetricConnection: Lets you declare that both players know each other’s address. The actual dialler is then selected dynamically from the session ID, preventing duplicate cross‑connections.
Builder Vault (TSM) Release 71.0.1
by Torben LauritzenBuilder Vault (TSM) Release 71.0.0
by Torben LauritzenVersions
Client API: 62.0 (!)
Client Communication: 31.0 (!)
Database: 7.12.0
Node Communication: 34.1
Node Configuration: 25.0 (!)
Changelog
Node Configuration:
- Added ExportKey, ImportKey, ExportKeyShare, ImportKeyShare to SEPH18S, DKLS19, DKLS23,
and SEPD19s
- Removed BackupKeyShare, RestoreKeyShare, ExportKeyShares, and ImportKeyShares from
SEPH18S, DKLS19, DKLS23, and SEPD19s
- Added ExportKey, ImportKey, ExportKeyShare, ImportKeyShare to SEPH18S, DKLS19, DKLS23,
and SEPD19S
- Removed BackupKeyShare, RestoreKeyShare, ExportKeyShares, and ImportKeyShares from
SEPH18S, DKLS19, DKLS23, and SEPD19S
Client API:
- Added countPresignatures() method to Node.js and WASM SDKv2
- Added utility method GenerateRSAKeyPair to generate encoded RSA public and private key
- Added methods ExportKeyShare/ImportKeyShare to export and import key shares and presignatures
- Removed BackupKeyShare and RestoreKeyShare (ECDSA, Schnorr)
- Renamed ExportKeyShares/ImportKeyShares to ExportKey/ImportKey
- Renamed generateEcdsaKey to generateEcdsaKeyPair in the Java SDK to be consistent with Golang
Client Communication:
- Added endpoints for export key share and import key share
- Removed endpoints for backup share and restore share
Patch changes (no effect on compatibility):
- When using WrappingKey(), the keys created by a node are automatically in the
import/export white list.
Details
Legacy SDK
The legacy SDK is now officially end of life and has been removed. Version 70 is the last major version that supports the legacy SDK.
This also means that the JCE provider has been removed.
Finally, tsmcli has also been removed. The purpose of tsmcli was to create users and administrators, but they are no longer used in the latest SDK.
Export and import changes
There have been some changes to how import and export work. Prior to version 71, there were the following ways of
exporting and importing keys:
- BackupKeyShare/RestoreKeyShare: Would do a local (unencrypted) export of a key share that could later be restored.
- ExportKeyShares/ImportKeyShares: Would export a (encrypted) raw key share and chain code to all players participating in the MPC protocol. This key share would be rerandomized, so to use the imported key, you needed all the shares.
In version 71 these methods have been changed:
ExportKeyShares/ImportKeyShares have been renamed to ExportKey/ImportKey to make it clearer that you are actually exporting the entire key. The functionality remains the same.
BackupKeyShare/RestoreKeyShare have been replaced by the new methods ExportKeyShare/ImportKeyShare. They work similarly to BackupKeyShare/RestoreKeyShare, but with a few significant differences:
- The exported key share is encrypted with a wrapping key
- The export can (optionally) include presignatures as well. If presignatures are exported, then they are removed from the source to reduce the risk of reusing a presignature.
These changes apply to ECDSA, Schnorr, RSA, AES, and HMAC. Note that only ECDSA and Schnorr support the ExportKeyShare/ImportKeyShare methods.
Builder Vault (TSM) Release 62.2.7 LTS
by Torben LauritzenBuilder Vault (TSM) Release 70.2.2 LTS
by Torben LauritzenBuilder Vault (TSM) Release 70.2.1 LTS
by Torben LauritzenBuilder Vault (TSM) Release 70.2.0 LTS
by Torben LauritzenVersions
Client API: 61.3
Client Communication: 30.3
Database: 7.12.0
Node Communication: 34.1
Node Configuration: 24.3
Changelog
Node Configuration:
- Fix error with multiple filters in mTLS configuration, serial number format changed
from decimal to hexadecimal
Patch changes (no effect on compatibility):
- Make postgresql driver look in /config/.postgresql for certificates, unless overridden
by environment variables PGSSLCERT, PGSSLKEY and PGSSLROOTCERT
- Fixed get SDK version methods that were returning a placeholder
Mobile frameworks have been built using: golang.org/x/mobile v0.0.0-20250506005352-78cd7a343bde
Details
N/A
Builder Vault (TSM) Release 70.1.0 LTS
by Thomas P. JakobsenVersions
Client API: 61.3
Client Communication: 30.2
Database: 7.12.0
Node Communication: 34.1
Node Configuration: 24.2
Changelog
Client Communication:
- Added end points for CBC encryption/decryption for the PKCS#11 module
Node Configuration:
- OIDC Access Token configuration now supports hardcoded application ID, or application ID
based on a claim
- Support for multiple loggers with different log levels
- Support for AWS CloudWatch and syslog logging
- Logging can now be configured either through a separate log configuration file, or as part
of the node configuration file
Client API:
- Fixed TypeScript definitions for Node.js SDKv2
- Added support for CKM_AES_CBC and CKM_AES_CBC_PAD in the PCKS#11 module
Patch changes (no effect on compatibility):
- Added option to use a log file to the PKCS#11 module configuration
Mobile frameworks have been built using: golang.org/x/mobile v0.0.0-20250305212854-3a7bc9f8a4de
Details
- The PKCS#11 plugin now supports the
CKM_AES_CBCandCKM_AES_CBC_PADmechanisms. - The MPC node log configuration can now be specified either as before (external file) or in the node configuration file itself. The log configuration is more flexible. It is possible to specify multiple loggers with different log levels, and there is also a logger for logging to AWS CloudWatch. See this for more info.
- It is now possible to map a client authenticating with OIDC to an application ID that is specified in the OIDC token. See more here.
