# Changelog

## Legend

|            Icon            | Description                                 |
| :------------------------: | ------------------------------------------- |
|    :white\_check\_mark:    | Improvement upon the Trust1Connector        |
|   :small\_red\_triangle:   | Bugfix                                      |
| :ballot\_box\_with\_check: | Story / new feature for the Trust1Connector |

## v3.7.11

<details>

<summary>Release 30/10/2023</summary>

## Release notes

#### Bug

[T1C-2806](https://trust1t.atlassian.net/browse/T1C-2806) Shared environment - issue with 904300-Signature data does not equal the expected data: reg should not send out the signature in the responses (or verify if the client pub is correctly loaded for REMOTE environments) -> local is not an issue

#### Task

[T1C-2777](https://trust1t.atlassian.net/browse/T1C-2777) Apple al-tool deprecation for signing/notarization

#### Story

[T1C-2560](https://trust1t.atlassian.net/browse/T1C-2560) Direct download of SSL when digest is not equal to the published version on DS

[T1C-2808](https://trust1t.atlassian.net/browse/T1C-2808) Add the integration with Local Signing Application

[T1C-2809](https://trust1t.atlassian.net/browse/T1C-2809) Sidecar for Certificate check upon start and init

[T1C-2810](https://trust1t.atlassian.net/browse/T1C-2810) Add swagger-ui initial set of exposed apis

[T1C-2812](https://trust1t.atlassian.net/browse/T1C-2812) Provide an initial openApi spec for LSA module

#### Improvement

[T1C-2638](https://trust1t.atlassian.net/browse/T1C-2638) As an integrator I can ask T1C to digest data before sign for each module

</details>

## v3.7.10

<details>

<summary>Release 03/10/2023</summary>

### Release Notes

#### Bug

[T1C-2710](https://trust1t.atlassian.net/browse/T1C-2710) t1c-sdk-js make excessive failing "pre-flight" requests

[T1C-2742](https://trust1t.atlassian.net/browse/T1C-2742) Ds Logs push using CURL has issues -> not sending over the PUT json body

[T1C-2747](https://trust1t.atlassian.net/browse/T1C-2747) File exchange list content type on macos sometimes gives read access errors on a just created folder via the API

[T1C-2765](https://trust1t.atlassian.net/browse/T1C-2765) SSL certifiicate synchronisation does not happen after first startup

[T1C-2804](https://trust1t.atlassian.net/browse/T1C-2804) Update T1C SSL certificates when running binaries from user session, while binaries are located in admin location

#### Task

[T1C-2671](https://trust1t.atlassian.net/browse/T1C-2671) Update notarization in packager, altool being deprecated

[T1C-2755](https://trust1t.atlassian.net/browse/T1C-2755) RMCR - Upgrade sentry to latest version

[T1C-2760](https://trust1t.atlassian.net/browse/T1C-2760) Document Dashboard setup

#### Story

[T1C-2380](https://trust1t.atlassian.net/browse/T1C-2380) As a User/Support desk I would like to change the log-level (info|debug|warn)

[T1C-2652](https://trust1t.atlassian.net/browse/T1C-2652) As a System I need to keep my transactions between installations

#### Improvement

[T1C-2805](https://trust1t.atlassian.net/browse/T1C-2805) Update Cryptoki on Mac/Win for updated PKCS11 drivers

</details>

## v3.7.9

{% hint style="info" %}
Released 26/07/2023
{% endhint %}

<details>

<summary>Release notes</summary>

#### Bug

[T1C-2735](https://trust1t.atlassian.net/browse/T1C-2735) Validate and consent Lock error on mutex should not return invalid consent but should give a propper try again later error

[T1C-2780](https://trust1t.atlassian.net/browse/T1C-2780) As a system administator I want to see the transactions of devices - somehow the transactions don't reach the DS

[T1C-2788](https://trust1t.atlassian.net/browse/T1C-2788) Prevent the refresh needed when polling during connector update/upgrade

#### Task

[T1C-2733](https://trust1t.atlassian.net/browse/T1C-2733) Add version to the installer

[T1C-2778](https://trust1t.atlassian.net/browse/T1C-2778) Upgrade Rust Edition 2021

[T1C-2779](https://trust1t.atlassian.net/browse/T1C-2779) Update Clap

#### Story

[T1C-2781](https://trust1t.atlassian.net/browse/T1C-2781) As a connector running on a local device I want to support key rotation from the application consumer

[T1C-2782](https://trust1t.atlassian.net/browse/T1C-2782) Update clap to v4 as CLI parser

[T1C-2783](https://trust1t.atlassian.net/browse/T1C-2783) Enable insecure for debugging when running in dev mode

[T1C-2784](https://trust1t.atlassian.net/browse/T1C-2784) Update the token information returned to the web application to contain a valid type

[T1C-2785](https://trust1t.atlassian.net/browse/T1C-2785) Finalise PKCS11 session for each running instance when ending a remote transaction

[T1C-2786](https://trust1t.atlassian.net/browse/T1C-2786) Update the PNA specification as an extension on previous release (announced Google Chrome v117)

[T1C-2787](https://trust1t.atlassian.net/browse/T1C-2787) Add documentation for ReadMyCards Web Application used for demonstration and showcase

[T1C-2790](https://trust1t.atlassian.net/browse/T1C-2790) Upgrade utility libs

[T1C-2791](https://trust1t.atlassian.net/browse/T1C-2791) Initial version for an independant debugger

#### Improvement

[T1C-2789](https://trust1t.atlassian.net/browse/T1C-2789) Add tracing events to the connector api and registry

</details>

## v3.7.7

{% hint style="info" %}
Released 30/05/2023
{% endhint %}

<details>

<summary>Release notes</summary>

#### Bug

[T1C-2102](https://trust1t.atlassian.net/browse/T1C-2102) JWT token validation consistently fails due to incorrect device time

#### Story

[T1C-2266](https://trust1t.atlassian.net/browse/T1C-2266) As a DS I need to provide a JWT token based on the time information of the requester.

[T1C-2705](https://trust1t.atlassian.net/browse/T1C-2705) Pass through the optional lable from the JWT SUB to the transactions file and DS

[T1C-2741](https://trust1t.atlassian.net/browse/T1C-2741) As a system I should be able to send the log files to the DS so that support can easily look for issues with a device

#### Improvement

[T1C-2695](https://trust1t.atlassian.net/browse/T1C-2695) As a client of the T1C API I want the api to validate the JWT token sent before proceeding with the use case

[T1C-2696](https://trust1t.atlassian.net/browse/T1C-2696) As a T1C API I want to renew the certificate needed for validation of the JWT when rotation happens on the DS

</details>

## v3.7.5

{% hint style="info" %}
Released 18/01/2023
{% endhint %}

<details>

<summary>Release notes</summary>

#### Bug

* After registering the device a synchronisation needs to happen

</details>

## v3.7.4

{% hint style="info" %}
Released 22/12/2022
{% endhint %}

<details>

<summary>Release notes</summary>

#### Task

* Upgrade compiler version to latest stable

#### Story

* As a system I when installed in a separate folder I want to validate the SSL certificate validity and domain based on the root file

</details>

## v3.7.2

{% hint style="info" %}
Released 20/10/2022
{% endhint %}

<details>

<summary>Release notes</summary>

***Story***

* As a system I should be able to send the log files to the DS so that support can easily look for issues with a device

</details>

## v3.7.1

{% hint style="info" %}
Released 20/10/2022
{% endhint %}

<details>

<summary>Release notes</summary>

***Bug***

* Remove header that was added in 3.7.0 from testing APN (w3c draft) implementation which caused older versions to fail

</details>

## v3.7.0

{% hint style="info" %}
Released 19/10/2022
{% endhint %}

<details>

<summary>Release notes</summary>

***Bug***

* Registry does not retrieve the base cors list on startup
* Mutex lock causes Registry and api to go into a deadlock
* When the user has a custom date/time set on his System it causes the API to crash on DS communication
* Shared environment/multi user setup makes the Registry and API get in a deadlock state
* Vulnerabilities based on Penetration test of Connective<br>

***Improvement***

* Use separate endpoint for reg to validate if api is registered on the correct user
* As an integrator I can ask for all readers and ask to exclude readers by name<br>

***Story***

* As a system I want to use the private and public device key to encrypt and decrypt the response data so that an integrator/SDK can validate that no man in the middle attack has happened

</details>

### 🔺Mutex <a href="#mutex" id="mutex"></a>

The API and Registry use a feature called Mutexes to have data that can be shared over multiple OS threads. Using this is necessary for some functionality. In previous versions when you have a Shared environment (citrix for example) you could make the API and Registry get into what's called a DeadlockThis caused the Mutex to never be unlocked for use by another OS thread. Causing the connector to be blocked completely.This has now been solved and has been tested on instances of 1000 concurrent devices.

### 🔺System time out of sync <a href="#system-time-out-of-sync" id="system-time-out-of-sync"></a>

We had a user which Operating system had a custom date set (not synced) which caused issues with DS communication. The DS communication also checks wether the time of request is not in the future or in the past (with some slack ofcourse). So if you use the Connector with a custom date you will not be able to contact the DS because it requires a request within a correct time-zone.If this is not the case it could be that a malicious user is trying to exploit the DS at which point the DS refuses the request. The issue was that this caused the Connector to crash.This has been solved so that the Connector does not crash.System time must be correct, otherwise DS communication can not be done (secrity issue)

### ✅ Private Network Access <a href="#private-network-access" id="private-network-access"></a>

Private Network Access is a new CORS draft. Which prevents remote servers to contact local instances without any extra checks. Chrome has already implemented this draft in a non-blocking manner, the implemenation of chrome is to send 2 pre-flight requests. One which is the normal pre-flight and another one where the PNA implementation has been done.At this point the pre-flight for the PNA implementation is non-blocking meaning that if the pre-flight fails it will not block the request.When the PNA Cors draft is final this will become blocking.In this release we've already started adding some required components to support this in an upcoming release.

### ​:ballot\_box\_with\_check: Sync log files with DS <a href="#sync-log-files-with-ds" id="sync-log-files-with-ds"></a>

In this release we've implemented a feature where the Connector will send it's log files towards the DS. This is so that support desks can easily get the log files of the device which is requesting support.

### ​:ballot\_box\_with\_check: HTTP verify response signature <a href="#http-verify-response-signature" id="http-verify-response-signature"></a>

We've added a feature where you can run the Connector in regualr HTTP mode. To still be secure we've added a signature field to the responses which can be verified to not be tampered with at the client's side. This verification is implemented in the JS SDK.

## v3.6.3

{% hint style="info" %}
Released 19/08/2022
{% endhint %}

<details>

<summary>Release notes</summary>

#### Bug

t1c-sdk-js tries to validate any present consent token when consent is disabled (optional consent)

#### Improvement

Remove the implicit CORS request from API info endpoint to DS, and provide/expose a public function in JS for application to force a CORS sync

#### Story

As a dashboard user I want to see how many installation have the DNS rebind issue

</details>

## v3.6.1

{% hint style="warning" %}
Javascript SDK 3.6.0 has been unpublished and contains a bug in the consent flow where the error code is not returned correctly
{% endhint %}

{% hint style="info" %}
Released 01/04/2022
{% endhint %}

{% hint style="warning" %}
The Mac Silicon (M1) is not yet supported for this version
{% endhint %}

<details>

<summary>Release notes</summary>

#### Bug

* Update consent error codes for 3.6.x so that they do not interfere with other error codes

#### Improvement

* As an SDK integrator I want to be able to fetch all the certificates on a token, including their information
* As a user I want to validate the signed hash from a PKCS11 token, using the validation function of the PKCS11 interface

#### Story

* As a user I want ot use Camerfirma token
* As a user I want to use Chambersign token
* As a SDK integrator I want to be able to call the TokenInfo enpdoint on PKCS11 tokens

</details>

### :small\_red\_triangle: Consent error code update

The consent error code has been updated in the Trust1Connector API library, and t1c-sdk-js clients have no impact on that change

### :small\_red\_triangle: Multi-client support and race condition fix

When using different instances of the Trust1Connector (optionally from another partner) on a Windows system, a port collision could be possible due to a race condition in port assignment upon initialization. Ports are now protected with anti-collision and are salted to make a port less guessable.

### :small\_red\_triangle: Implicit creation of LaunchAgents folder on Mac/OSX

When no LaunchAgents folder was present on the system, the installation procedure creates this folder implicitly.

### :ballot\_box\_with\_check: Exposed Camerfirma interface

Camerfima is a new PKCS11 token added to the modules of the Trust1Connector. The Camerfirma token pre-requisites the installation of the Carmerfirma middleware.

### :ballot\_box\_with\_check: Exposed Chambersign interface

Chambersign is a new PKCS11 token added to the modules of the Trust1Connector. The Chambersign token pre-requisites the installation of the Chambersign middleware.

### :ballot\_box\_with\_check: Token Info endpoint will now returned detailed information when using a PKCS11 token

The token info endpoint has been implemented before only for identity tokens. We have added support for Token Info of the PKCS11 modules. As the response has a different data structure, an additional type has been added for clients to parse the response correctly.

The PKCS11 token info exposes information on the algorithms which can be used for different use cases (digital signature, validation, authentication, ...). In a future release additional functionality will be provided such as: encryption, decryption, key exchange,...

### :white\_check\_mark: Fetch all the certificates on a token including all their information

For the different notification types, many tokens share multiple certificates for a single type. The original interface supported only a single certificate response. To be backwards compatible, those certification function have been adapted to be behave the same as in v3.5.x.&#x20;

New functions are available to support multiple certificate reponses, they are called: **\[certificateType]Extended.** For PKCS11 tokens the certificate response also returns, besides the base64 encoded certificate and the certificate id, the following properties:

* issuer
* subject
* serial number
* hash sub pub key
* hash iss pub key
* exponent (payment modules)
* remainder (payment modules)
* parsed certificate (ASN1 format of the base64 encoded certificate)

You can find an example for [certigna here](https://t1t.gitbook.io/t1c-js-guide-v3/3.7.x/token/certigna#extended-certificates)

### :white\_check\_mark: Signed hash validation function exposed for PKCS11 tokens

A new function has been added for all PKCS11 modules called the 'validate' endpoint. This endpoint, when available, can be used to validate a signed hash received after calling the 'sign' function. In an next version a variant of the validation function using OpenSSL will be added for all tokens.

### :white\_check\_mark: PKCS11 migration towards RUST

For the Trust1Connector to support more PKCS11 functionality, the intermediate PKCS11 layer has been removed in preference of a direct PKCS11 LIB integration. FFI is used in RUST to support any library which need to be loaded.

### :white\_check\_mark: Token Algortihm input validation for signing and authentication

Additional guard has been implemented to prevent empty algorithms for the digital signature and validation endpoints. PKCS11 tokens will verify as well if the provided algortihm is exposed as an allowed mechanism for the targetted use case.

### :white\_check\_mark: JCOP3 ATR added

The Trust1Connector can now detec Java Card Object Platform 3 typed cards

### :white\_check\_mark: Select default PKCS11 non-repudation or authentication certificate

When requesting for a signature or an authentication, the correct certificate must be provided. For PKCS11 tokens the certificate id (or reference) can be ommitted. The PKCS11 token will be default pick the first certificate (for the type needed) and use this with the specified mechanism to sign/authenticate.
