Builder 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.
Builder Vault (TSM) Release 70.0.0 LTS
by Torben LauritzenChangelog
Client API:
- Added NewSessionConfigWithTimeouts to allow users to specify different values of
connectTimeout and sessionTimeout per session. Must be lower than the values configured
on the server.
- Removed SEPH15PRF
- Removed GenericKey. This was most likely never used since PKCS#11 was changed in 57.0
- Added support for MinaSchnorr, ZilliqaSchnorr and Sr25519
- Schnorr now uses a schnorr variant instead of the elliptic curve name to determine
which scheme to use
- Replaced PKIX public key with JSON public key in ECDSA and schnorr
- AES key import now works with the wrk17 protocol
- WebAssembly SDKv2: Added schnorrSign() helper method, to create signature from raw
private key
- Node.js SDKv2: Added schnorrSign() helper method, to create signature from raw
private key
- Node.js SDKv2: Simplified result from finalizeSignature, to just return signature
- SDKv2 Web Assembly (WASM) added
Client Communication:
- Clients can now override connectTimeout and sessionTimeout per session, as long as
the values are lower than the values configured on the server
- Removed XORSHARE and SEPH15PRF protocols
- Changed endpoints for SEPD19S to support new schnorr protocols
- Endpoint for aes key import now enabled for the wrk17 protocol
Node Communication:
- Added support for MinaSchnorr, ZilliqaSchnorr and Sr25519
- AES-GCM with two players (WRK17) now accepts input that is not a multiple of 16 bytes
- Added support for 192 and 256-bit AES in WRK17 (keygen, key import, aes-ctr, aes-cbc,
aes-gcm)
- Changed protocol implementation for PKCS11 protocol
- Changed protocol implementation for WRK17 (now handled by libmpc)
Node Configuration:
- mTLS certificate filtering has been improved to allow filtering on SerialNumber,
Subject, and Issuer
- Added DKLs23
- Removed XORSHARE and SEPH15PRF configurations
Patch changes (no effect on compatibility):
- Fix bug when dropping privileges to an unknown user
- Fix bug when using maps in mobile SDKs
- Fix bug causing wrk17 keys created prior to TSM v64 to not parse correctly
- Change format of partial results for wrk17 operations
- Fix bug in wrk17 related to matrix multiplication
- Introduced new key format for wrk17 keys (old key material still supported)
Mobile frameworks have been built using golang.org/x/mobile v0.0.0-20250305212854-3a7bc9f8a4de
Versions
Client API: 61.1 (!)
Client Communication: 30.1 (!)
Database: 7.12.0
Node Communication: 34.1 (!)
Node Configuration: 24.0 (!)
Old SDK has Entered Maintenance State
When changes are made to the SDK, we implicitly mean the new SDK (SDKv2). If there are changes to the legacy SDK it will be explicitly mentioned.
PKCS#11 for Two Players
The PKCS#11 module now works with two players. Note that running with n=2, t=1 significantly reduces performance compared to n=3,t=1
Support for ECDSA Signatures over the Stark Curve
Specify "StarkCurve" as the name of the elliptic curve when running ECDSA protocols to get signatures compatible with Starknet.
New Schnorr Schemes
The Schnorr protocol now supports the schnorr protocol used in Mina (MinaSchnorr), the one used in Zilliqa (ZilliqaSchnorr) as well as Sr25519. To use a schnorr scheme, you must now specify the name of the scheme instead of the elliptic curve. Valid schemes are: Ed25519, Ed448, BIP-340, MinaSchnorr, ZilliqaSchnorr and Sr25519. There are also constants defined in the SDK for each scheme.
New Public Key Format for ECDSA and Schnorr
The format of public keys in the SDK has been changed from PKIX public keys to a JSON format. A public key now has the following format:
{ "scheme": "...", "curve": "...", "point": "..." }
Scheme is either ECDSA or one of the schnorr schemes. Curve is the name of the elliptic curve, but can be empty if
it is uniquely defined by the scheme. Point is a compressed or uncompressed point representing the public key.
There are utility functions for converting between the old and the new format.
WASM SDKv2
A new Web Assembly SDK is available, see the docs Web Assembly docs, in the .tar.gz file, you will find a number of tests showing how to use the SDK.
Caveat
The new WASM SDKv2 does not include the option to run an embedded TSM node.
TSM Release 69.0.0
by Torben LauritzenChangelog
Node Configuration:
- Add support for AWS Secrets Manager and dynamic IAM RDS authentication
- Make OCSP hash algorithm configurable
Client API:
- SDKv2(Go, C, Java): Added method to count number of pre-signatures
- SDKv2(Go, C, Java): Added utility method to sign with a raw Schnorr private key
- SDKv2(C, Java, Node.js): Added hash algorithm to OCSP methods
- Make OCSP hash algorithm configurable
Mobile frameworks have been built using golang.org/x/mobile v0.0.0-20250106192035-c31d5b91ecc3
Versions
Client API: 59.0 (!)
Client Communication: 29.1
Database: 7.12.0
Node Communication: 32.1
Node Configuration: 21.4
AWS Secrets Manager and IAM RDS Authentication (Node Configuration: 21.4)
It is now possible to use the aws tag anywhere in the node config file, like this:
[Database]
EncryptorMasterPassword = "{{ aws prod/encryptor-master-password eu-central-1 }}"
The node will then replace this with secret named prod/encryptor-master-password from AWS SecretsManager.
The replacement happens once, at startup. The config file can contain multiple secrets like this, but they must all fetch from the same AWS region. To work, the TSM node must be allowed to perform the IAM action secretsmanager:GetSecretValue on each secret, e.g., by running the TSM node on an EC2 instance that is assigned an IAM role with this permission.
It's also possible to connect to AWS RDS using IAM authentication via the iam tag, as follows:
[Database]
DataSourceName = "{{ iam mariadb dbuser my-rds.cf4m8zm7yt0e.eu-central-1.rds.amazonaws.com:3306 db eu-central-1 }}"
This will be replaced by an RDS IAM token for the given RDS database. Here dbuser is the user for the RDS database, and db is the database name. For this to work, the TSM node must be allowed to perform the IAM action rds-db:connect for the given database user and database, e.g., by running the TSM node on an EC2 instance that is assigned an IAM role with this permission. The iam tag works for mariadb, mysql and postgres databases.
Unlike the aws tag which gets replaced once, when the node starts up, the iam tag gets expanded each time a new database connection is created. Combined with ConnectionMaxLifetime as in the following example, this
ensures that the TSM node will refresh its RDS IAM tokens at least every 10th minute.
[Database]
DriverName = "postgres"
DataSourceName = "{{ iam postgres my_db_user my_rds.cf4m8zm7yt0e.eu-central-1.rds.amazonaws.com:5432 my_db eu-central-1 }}"
ConnMaxLifetime = "10m"
Client API changes (Client API 55.0)
WithPublicKeyPinning is now an option on the client configuration, whereas it was part of the mTLS configuration before. This means that public key pinning is now also possible for API key and OIDC authentication.
When using mTLS you can now choose to OCSP staple the client certificate. If this is not used, just pass nil as the ocspStapling value when configuring mTLS authentication.
Finally, all the builder steps in the configuration can no longer return an error. The error will instead be reported when instantiating the client.