Versions

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.