Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The different architectures supported by the Trust1Connector
The Trust1Connector can be configured to comply with different installation scenario’s. This can be done when packaging the Trust1Connector, and is managed through setting the correct command-line arguments upon startup. To facilitate this, the Trust1Connector ships with a partner specific launcher which can be adapted to comply with different reqeusts.
The Trust1Connector can be installed in different ways, depending on the requirements for a specific business context. By default the Trust1Connector uses the best approach for a device in an unknown context.
The different setups describes below all share *the same codebase*. For each target the executables are exactly the same.
We achieve this through command line parametrization of the executable. Updating the CLI parameters for the API or Registry modifies the behaviour of the runtime execution.
This provides us with the following benefits:
same code base, same binaries
change behaviour for a specific context
change behaviour at runtime
The installation profiles, as we tend to have many command line arguments, are encapsulated in a separate executable, this is called 't1c-launch'.
The 't1c-launc' does the following:
validate the environment
validate prerequisites
start the connector executables
provide the correct CLI params, decided upon compilation time
This document describes all achievable different scenario’s with pros and cons, depending on the business case.
To understand how the Trust1Connector can be setup, it is good to have an overview of all components in the Trust1Connector eco system.
The Trust1Connector can be installed in ‘offline’ mode. This is the case when:
no internet connection is available
no centralised Distribution Service is available/wanted
Following this approach, the installation base (devices with T1C installed) is managed from an software application distribution platform (version management, insights, …).
The Trust1Connector is fully functional in an offline environment and contains all module logic in the installation footprint. The options explained here describes what are the possible modes for offline installations.
Trusted browser and no PIN encryption between the browser and the connector application interface.
Untrusted browser and PIN encryption enforced through the connector application interface.
The Shared Registry executable is introduced to resolve client address ports during initialization. The shared registry runs a single instance on one of the connected clients OR the host application.
When the host is NOT running the shared registry, clients are dynamically checking if a registry is available. When a registry instance is not found, a random client launches a registry instance, untill the client becomes unavailable.
In this mode the Distribution Service is used for one or both of the following categories of use cases:
connector client instance synchronization
central port resolution
The former category denotes the device synchronization and management operational use cases.
The lattter adds to the functionality by acting as a central registry, becoming a critical component during connector client instance initialization.
In that scenario, connector instances are always bound to DS (Distribution Service); the DS is the centralized service handling the address port resolution for every client. A client will register it’s dynamically assigned port (from a configurable port range) at the DS. The DS resolves the address port for each web application trying to connect with it’s local client. The handshake is performed using an the web application consent flow.
The DS is a central service collection all anonimized operation data for every linked connector instance.
The DS serves the operational use cases:
demographic information
SSL and Device certificate rotation
client-demand log dispatching
CORS management
The communication from the web application towards the connector instance is secured and requires pre-requested JWT from the Distribution Service.
The local connector instances enforces JWT validation prior to use case execution.
Additional functionality for device key-rotation and application registry bindings are available in this context.
In this mode, DS communication is established but not blocking operationally once installed.
PIN Encryption and shared registry is configured on the host or on the client dynamically (local election algorithm). The shared registry stores a list of agents, keeping track of agents-port correlation.
The JWT authentication/validation on API is optional and configured during packaging.
An extension on the profile above, is when an admin runs the 'registry' process on-startup, as a service user, in a shared environment. This means that the registry process will run always, and will not be changed throughout user sessions (especially when a user session gets invalidated, or stays acive even when de user has logged out.
For shared environments, our recommendation is to start the registry process on a shared environment for all remote terminals/clients.
The DS keeps track of the client address ports and resolves the port upon every new session between the browser and the local connector instance during initialisation. Additionally the public key for web application encryption is shared between the registry and the requestion client application.
The variants decribed hereafter differs in how the packager stores the files and executables during installation.
In this mode, a user image is by default stateless and the connector is initialized upon every new user session.
This implies that the connector instance will register upon startup, for every new user login.
The user always starts with a clean installation when logged-in. This approach resembles with how Docker starts new images instances and can be used thus in a Docker image.
This variant is called ‘split installer’ and splits the location of the executables during installation and the user session related configuration files (transaction info, consent, device certificates, logs, …).
In this approach, the executables are provision in a predefined path (typically system program files or system folder).
The user session related files are stored in a user specific folder location.
An optional Local Registry for multi-host or shared environments.
It is required when using Trust1Connector on a shared machine with multiple users. The component is optional, and a central registry can be used as well. The integrating party must choose whether to opt for a local dynamic registry or a central Distribution Service Registry
T1C-Registry [Centralised]
An optional Centralised Registry for multi-host or shared environments. The service can only be used when a Distribution Service is provided in the solution architecture.
It is required when using Trust1Connector on a shared machine with multiple users. The component is optional, and a local dynamic registry can be used as well. The integration party must choose whether to opt for a decentralised or centralised approach. When choosing a centralised approach, a Distribution Service setup is needed.
T1C-DS
The Trust1Connector Distribution Server is a central management service for the T1C.
The DS is serving use cases for version management, demographic information, key rotation, additional security protection, dynamic CORS, application management and more
Virtual Reader
The remote loading implementation for a backend smart card service
The virtual card reader acts as a remote smart card reader, able to communicate with any card on a remote client enabling HSMs (High security modules), central card management systems, smart card personalisation use cases and more
API Gateway
An optional API gateway introduced when using the T1C-DS for security policy enforcement
As the T1C-DS acts as a REST microservice, additional security measurement must be taken into account. The API gateway implements different security policies applied on:
Device to DS communication
Application to DS communication
Component
Description
Note
T1C-SDK-JS
An easy to use Javascript SDK for quick integration into partner web applications
This is an optional component which can be used to ease and speed up the integration of the Trust1Connector into any web application. The SDK acts as an interface for the consuming web application and supports backwards compatibility
REST Client
A 3rd Party Rest client
Any REST client can be used to address the Trust1Connector use cases directly from your consuming application. Applications can be native desktop applications or web applications in any technology
T1C-Sandbox
A secured Sandbox for smart card APDU execution, exposing a gRPC interface
The Sandbox can be used directly for certain applications, but it’s main goal is to isolate the APDU interactions towards smart cards, and card readers (contact or contactless)
T1C-Rust-API
An OpenAPI REST interface, acting as an addressable microservice.
The local REST Service, installed on the local device, serving the functionality used directly from consuming applications or from the T1C-SDK-JS. The OpenAPI YAML is published and can be used to generate a REST client in any technology








T1C-Registry [Decentralised]
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.
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 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.
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.
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.
Javascript SDK 3.6.0 has been unpublished and contains a bug in the consent flow where the error code is not returned correctly
The Mac Silicon (M1) is not yet supported for this version
The consent error code has been updated in the Trust1Connector API library, and t1c-sdk-js clients have no impact on that change
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.
When no LaunchAgents folder was present on the system, the installation procedure creates this folder implicitly.
Camerfima is a new PKCS11 token added to the modules of the Trust1Connector. The Camerfirma token pre-requisites the installation of the Carmerfirma middleware.
Chambersign is a new PKCS11 token added to the modules of the Trust1Connector. The Chambersign token pre-requisites the installation of the Chambersign middleware.
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,...
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.
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
You can find an example for
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.
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.
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.
The Trust1Connector can now detec Java Card Object Platform 3 typed cards
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.
T1C-2899 Add flag to check SSL certificate on startup
T1C-2888 Simplesign SDK-JS points to wrong endpoint
T1C-2866 Document host file issue
T1C-2889 As a user I want to get the version available for the Belgian eID
T1C-2894 Detect DNS Rebind and fix by asking user to allow update of the local host file
T1C-2717 As an integrator I can ask for all readers and ask to exclude readers by name
T1C-2881 DNS Rebind check + dialog to fix it with admin rights
T1C-2886 T1C SDK JS, retrieve reader list should exclude windows hello for business
T1C-2890 Update the SimpleSign bootstrap filename to the original
T1C-2883 As an integrator I want correct error codes when cancelling the pin action on Sign, Authenticate or verify pin actions
T1C-2884 As an integrator I want correct error codes when timeout the pin action on Sign, Authenticate or verify pin actions
T1C-2885 As an integrator I want access to the SimpleSign module
T1C-2820 Allow t1c-sdk-js to initialize using multiple endpoints
T1C-2843 Cleanup certificates interfaces
T1C-2851 Allow sdk initialisation with multiple hosts, selecting first-to-respond
T1C-2852 Implement Truststore Certificates interface
T1C-2853 Implement Truststore Transactions interface
T1C-2854 Add global x509 utility endpoints for certificate parsing (DER|PEM|x509)
T1C-2855 Remove deprecated proxy url and port from SDK initialization
T1C-2856 Remove PKI.js dependency (replaced with the addition of API x509 endpoints
T1C-2857 Add parsing of certificates into Subject or Issuer CN
T1C-2858 Impelementing reader and truststore cross-over model
T1C-2859 Adding Keychain integration for Mac OSX
T1C-2860 Adding MSCAPI (wincrypt) and CNG for Windows
T1C-2819 Update the T1C with the new SSL for DNS t1c.t1t.io
T1C-2845 Update system crate
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
T1C-2777 Apple al-tool deprecation for signing/notarization
T1C-2560 Direct download of SSL when digest is not equal to the published version on DS
T1C-2808 Add the integration with Local Signing Application
T1C-2809 Sidecar for Certificate check upon start and init
T1C-2810 Add swagger-ui initial set of exposed apis
T1C-2812 Provide an initial openApi spec for LSA module
T1C-2638 As an integrator I can ask T1C to digest data before sign for each module
T1C-2710 t1c-sdk-js make excessive failing "pre-flight" requests
T1C-2742 Ds Logs push using CURL has issues -> not sending over the PUT json body
T1C-2747 File exchange list content type on macos sometimes gives read access errors on a just created folder via the API
T1C-2765 SSL certifiicate synchronisation does not happen after first startup
T1C-2804 Update T1C SSL certificates when running binaries from user session, while binaries are located in admin location
T1C-2671 Update notarization in packager, altool being deprecated
T1C-2755 RMCR - Upgrade sentry to latest version
T1C-2760 Document Dashboard setup
T1C-2380 As a User/Support desk I would like to change the log-level (info|debug|warn)
T1C-2652 As a System I need to keep my transactions between installations
T1C-2805 Update Cryptoki on Mac/Win for updated PKCS11 drivers
T1C-2733 Add version to the installer
T1C-2778 Upgrade Rust Edition 2021
T1C-2779 Update Clap
T1C-2781 As a connector running on a local device I want to support key rotation from the application consumer
T1C-2782 Update clap to v4 as CLI parser
T1C-2783 Enable insecure for debugging when running in dev mode
T1C-2784 Update the token information returned to the web application to contain a valid type
T1C-2785 Finalise PKCS11 session for each running instance when ending a remote transaction
T1C-2786 Update the PNA specification as an extension on previous release (announced Google Chrome v117)
T1C-2787 Add documentation for ReadMyCards Web Application used for demonstration and showcase
T1C-2790 Upgrade utility libs
T1C-2791 Initial version for an independant debugger
T1C-2789 Add tracing events to the connector api and registry
T1C-2266 As a DS I need to provide a JWT token based on the time information of the requester.
T1C-2705 Pass through the optional lable from the JWT SUB to the transactions file and DS
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
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 As a T1C API I want to renew the certificate needed for validation of the JWT when rotation happens on the DS
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
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
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
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
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
As a dashboard user I want to see how many installation have the DNS rebind issue
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
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
hash iss pub key
exponent (payment modules)
remainder (payment modules)
parsed certificate (ASN1 format of the base64 encoded certificate)
Verband Deutscher Dental Software (VDDS-media 1.4)
VDDS-media 1.4 defines an interface for the exchange of multimedia data between practice management software and the X-ray/camera software
The Trust1Connector has a custom `vdds` module which can be used in combination with the `file-exchange` module.
The `file-exchange` module exposes an API for abstract file management. For more information see: File Exchange. In summary, the `file-exchange` module allows you to define `scoped` abstractions for folders and files, in a web context (based on the origin of the requesting web applciation).
The additional functionality exposed by the `vdds` module, is mainly:
open the Image viewer with a pre-defined image ID
import/export data to/from an IPS (Image Processing System)
The typical client application is a web PMS (Practice Management System).
The following communication diagram depicts the information exchange defined in the specification:
The executable names are hard-coded and statically extended to the abstract file descriptor on the T1C-API.
The HTTP/REST API is used by the T1C-SDK-js (javascript client).
A file descriptor is defined in terms of the entity and entity type, the absolute path can be used to build a relative folder path starting from the folder mapping (linked to the entity type).
The supported commands available are denoted in the following enumeration:
The `vdds` execution endpoint has a single, multi-purpose struct:
The execution endpoint assumes a proper file management handled by the requesting web application.
The file-exchange entity, entity-type and thus type-mapping MUST exist prior to the command execution request.
the ExecDescriptor contains a field 'argFilePathQuatesDisable', that field basically resolves the file path parameter to a list of strings (split on whitespaces) to simulate passing the argument on a shell, without the double quotes ' " '. Shell execution wraps a file path argument in a C-like string, but some bat or exe files who are not complying to this, can thread the whitespaces in a path as a concatentation of arguments.
Initialize a Trust1Connector client:
Get the module using the client
Now you can use the vdds client to call its functionality.
The following responses are returned when an exception is thrown:
wrong or missing arguments in request body defined by (entity, entity-type, file-name or args)
wrong or missing executable path reference defined by (entity, entity-type, command)
file-exchange has not been initialized prior to the documented use case
referencing file is not found on the local device file system, this is typically the case when a wrong entity-type of relative folder has been provided in the request
To test the VDDS module execution, you can use a bunch of stubbed executables which are available on [].
This is nothing fancy, just a cpp repo, which generates 3 executables and dumps the arguments on std::out.
The testing track described here follow the T1C-API, and does NOT use the T1C-SDK-js !
If you are using the javascript SDK, you can skip or continue reading to have more insights on how it works *under the hood*.
Use an REST client of curl to create an entity and entity type -> this will pop-up a file-chooser, where you need to select the folder (where you want the entity-type to link to):
Response example:
/// Filepath abstraction for VDDS
#[derive(Debug, Deserialize, Clone)]
pub struct FileDescriptor {
pub entity: String,
#[serde(rename = "type")]
pub entity_type: String,
#[serde(skip_serializing_if = "Option::is_none")]
#[serde(rename = "relPath")]
pub rel_path: Option<Vec<String>>,
#[serde(rename = "fileName")]
pub file_name: String,
}#[derive(Debug, Clone, Deserialize)]
pub enum VddsCmd {
import,
export,
view,
}#[derive(Debug, Serialize, Deserialize, Clone, Validate)]
pub struct VddsExecutable {
#[validate(length(min = 1, max = 256))]
#[serde(rename = "entity")]
pub entity: String,
#[validate(length(min = 1, max = 256))]
#[serde(rename = "type")]
pub entity_type: String,
#[serde(skip_serializing_if = "Option::is_none")]
#[serde(rename = "relPath")]
pub rel_path: Option<Vec<String>>,
#[serde(rename = "cmd")]
pub cmd: String, //import, export, view
#[serde(rename = "argFilePathQuotesDisable")]
pub arg_file_path_quotes_disable: Option<bool>,
}export interface AbstractVdds {
import(body: VddsImportRequest): Promise<VddsResponse>;
export(body: VddsExportRequest): Promise<VddsResponse>;
view(body: VddsViewRequest): Promise<VddsResponse>;
}
// Models
export interface VddsImportRequest {
exec: ExecDescriptor,
file: FileDescriptor
}
export interface VddsExportRequest {
exec: ExecDescriptor,
file: FileDescriptor
}
export interface VddsViewRequest {
exec: ExecDescriptor,
args: Array<String>
}
export interface ExecDescriptor {
entity: String,
type: String,
relPath?: Array<String>
argFilePathQuotesDisable?: boolean,
}
export interface FileDescriptor {
entity: String,
type: String,
relPath?: Array<String>
fileName: String
}
export class VddsResponse extends T1CResponse {
constructor(public success: boolean){
super(success, null);
}
} T1CSdk.T1CClient.initialize(config).then(res => {
client = res;
}, err => {
console.error(error)
});var vdds = client.vdds();let body = {
exec: {
entity: "Crossuite",
type: "vdds",
relPath: ["build"],
},
file: {
entity: "Crossuite",
type: "vdds",
relPath: ["files"],
fileName: "somefile.txt"
}
};
vdds.import(body).then(res => {
// handle response
}).catch(error => {
// handle error
});let body = {
exec: {
entity: "Crossuite",
type: "vdds",
relPath: ["build"],
},
file: {
entity: "Crossuite",
type: "vdds",
relPath: ["files"],
fileName: "somefile.txt"
}
};
vdds.export(body).then(res => {
// handle response
}).catch(error => {
// handle error
});let body = {
exec: {
entity: "Crossuite",
type: "vdds",
relPath: ["build"],
},
args: ["rnd_image_id"]
};
vdds.view(body).then(res => {
// handle response
}).catch(error => {
// handle error
});# InvalidInput
{
"success": false,
"code": 106997,
"description": "Invalid Input"
}
# ConfigurationError
{
"success": false,
"code": 505126,
"description": "Configuration Error"
}
# FileNotFoundException
{
"success": false,
"code": 505126,
"description": "File not found"
}
# checkout
git clone https://github.com/Trust1Team/vdds-test-exec
# build
mkdir build
cd build
cmake ..
cmake --build .```powershell
curl --location 'https://t1c.t1t.io:55000/v3/modules/fileexchange/apps/file/create-type' \
--header 'X-CSRF-Token: t1c-js' \
--header 'Content-Type: application/json' \
--header 'Authorization: ••••••' \
--data '{
"entity": "MyCompany",
"type": "vdds",
"modal": true
}'
```{
"success": true,
"data": {
"entity": "MyComp",
"type": "vdds",
"absPath": "/Users/michallispashidis/_git/vdds-test-exec",
"accessMode": "d",
"total": 0,
"appId": "unknown"
}
}curl --location 'https://t1c.t1t.io:55000/v3/modules/vdds/cmd/exec' \
--header 'Content-Type: application/json' \
--header 'Authorization: ••••••' \
--data '{
"exec": {
"entity": "MyComp",
"type": "vdds",
"relPath": ["build"],
"cmd": "import"
},
"file": {
"entity": "Crossuite",
"type": "vdds",
"relPath": ["files"],
"fileName": "somefile.txt"
}
}
'{
"exec": {
"entity": "MyComp",
"type": "vdds",
"relPath": ["build"],
"cmd": "export"
},
"file": {
"entity": "Crossuite",
"type": "vdds",
"relPath": ["files"],
"fileName": "somefile.txt"
}
}{
"exec": {
"entity": "Crossuite",
"type": "vdds",
"relPath": ["build"],
"cmd": "view"
},
"args": ["rnd_image_id"]
}
Issues related to device time not in sync
The connector can only work when the device date/time is correctly set. This is due to the security applied on exchanged tokens and keys.
When a connector has been installed on a device, at a moment which is in the past (other day/time), this results in the connector not working, even though the date/time has been set correctly on the system (post-installation).
To solve this problem the followin steps need to be executed:
remove all device related keys
restart the connector
Go to the installation folder of the connector:
%localappdata%/Trust1Connector
Delete all security relate files (selected below):
Those files are:
device.priv
device.pub
device_der.priv
device_der.pub
Restart the connector by executing the 't1c-launch'
The process will be stopped, and restarted. The 't1c-launch' process must stop running, and the new processes will trigger the re-generation of the new keys.
Due to this action, the device performs a new registration to the Distribution service, this can be verified in the api.log file (in the /Logs folder)
Go to the installation folder of the connector:
cd ~/Library/Application\ Support/Trust1Team/Trust1Connector/
Open the folder in finder:
open .
Delete all security relate files (selected below):
Those files are:
device.priv
device.pub
device_der.priv
device_der.pub
Use the terminal to open the connector installation folder:
cd ~/Library/Application\ Support/Trust1Team/Trust1Connector
Execute the t1c-launch to restart
./t1c-launch --restart
The process will be stopped, and restarted. The 't1c-launch' process must stop running, and the new processes will trigger the re-generation of the new keys.
Due to this action, the device performs a new registration to the Distribution service, this can be verified in the api.log file (in the /Logs folder)
ds-ssl.json
ds-txs.bck
ds-ssl.json
ds-txs.bck


You can find the trust1connector JS SDK for the Trust1Connector v3 via NPM
You can also find the source code here https://github.com/Trust1Team/t1c-sdk-js/tags
Running the Trust1Connector in a shared environment, such as Citrix, XenApp and Remote Desktop, requires additional installation steps. In this section we explain the concept and approach used.
The following schematic seems rather complicated as it explains the inner workings of the Trust1Connector components, the concept is explained further on this page. If you are only interested in what the integration impact is for your Web Application in a Shared Environment, you can skip and go directly to the following section: Integration in Web Applications
The Web Application can use the T1C-SDK-JS or a custom REST API client for integration purpose. As the Web Application operates in a browser context, resolving an agent, by means of a consent, will result in a browser cookie being provided.
The T1C-SDK-JS implements the detection of a Shared Environment during the initialisation of the library. When initialisation succeeds without a controlled exception, the setup is a standalone; when the initialisation throws an 401 Error, the T1C-SDK-JS can be used to request the user for a Consent.
When using the REST API directly form your web application, reading the browser cookie and performing the initialisation must be done by the integrating Web Application itself.
Compared to Trust1Connector v2, the v3 release has a separate component to be be installed on a shared host. This component is called the T1C-Registry and only exposes the following use cases:
Verify random available ports [in a predefined range] which can be used by an Agent (Session of T1C-API running in user space)
Port reservation upon installation of a new T1C-API in an active user session
Port registration upon initialisation of a T1C-API in an active user session
Management of an in-memory list of active Agents
The T1C-Registry operates by Default on the API port defined in the T1C-DS (Distribution Server). From a Web Application perspective, this is the only information known. When a Web Application requests the information of the device, the PROXY device type will inform the Web Application that the targeted underlying API is a PROXY, which means that the Web Application must ask for the Agent specific API port to configure an URI which can be used to execute the use cases.
When using the T1C-SDK-JS this is done implicitly during initialisation.
A T1C-API installed for a specific users runs in [User Space]. To avoid possible attack vectors, the Trust1Connector v3 will always run in [User Space].
Upon installation of the T1C-API, during the post install phase, the T1C-API will try to verify automatically if it is running in a shared environment. If this is the case, the T1C-API will ask the T1C-Registry for available ports and will reserve those post, prior to initialisation and startup.
The ports which are reserved by the T1C-Registry are the following:
T1C-API Port: This is the port exposing the OpenAPI interface towards Web Applications and used by the T1C-SDK-JS
When receiving ports during post-install, an user agent device is temporary RESERVED in the Agent Registry of the T1C-Registry. Upon T1C-API initialisation, the port configurations will be confirmed and the Agent Registry will set the device state on REGISTERED. From this moment on, a T1C-API instance, running in an active user session, will be available for the Web Application via the .
The T1C-sandbox instance is inherently a component from the T1C-API, and thus is managed by the T1C-API. As each user must have it's own hardened runtime for communication purpose, the port assigned for T1C-sandbox will be registered and configured by the T1C-API (and restarted when needed).
Starting from this release (v3) of the Trust1Connector, each device must have a link with an active and running T1C-DS (Trust1Connector Distribution Server). This is to guarantee security, updates, and avoid potential risk in production.
The T1C-DS is proceeded by an API Gateway who is managing the security offloading in the application layer. For a Web Application to communicate with a T1C-Registry or T1C-API, a JWT (Json Web Token) is needed and obliged. The T1C-DS is responsible for the key management, the certificate management and other use cases which are described in a separate wiki.
In order to retrieve a valid JWT, the T1C-DS can be requested from your application back-end with a valid api-key. The JWT is valid for a given amount of time, and sets the context used when requesting the T1C-API on a device.
The PIN handling logic is implemented in the Trust1Connector API. More information on the basic and/or advanced rules can be found on the following link:
The Trust1Connector API v3 exposes a secure REST API on the client device. Trust1Team has created a t1c.t1t.io DNS entry (or customer-specific DNS entry) that points to 127.0.0.1 in order to facilitate SSL communication. This means that if the customer infrastructure uses a proxy for all network traffic, an exemption must be made for t1c.t1t.io to always point to the origin device's loopback address. The same holds true for the localhost domain name, this should redirect to 127.0.0.1 on the user's local system, not the localhost of the proxy server.
If no exemption is made and https://t1c.t1t.io is handled by a proxy, it will redirect to 127.0.0.1 IP of the proxy server instead of the local machine, and the Trust1Connector API will be unreachable.
The reserved domain from Trust1Team (t1c.t1t.io) has been registered with DNSSEC on the aforementioned URI. When a PARTNER uses its own DNS, we strongly recommend applying DNSSEC on the domain used in production.
Some (corporate) networks have a policy that disables the ability to bind a domain to a local network IP. The Trust1Connector relies on this for t1c.t1t.io which resolves in to 127.0.0.1 which is a local ip for localhost
If DNS rebind protection is enabled it is unable to use t1c.t1t.io for connection towards the Trust1Connector because the network does not allow this Domain to be a local ip-address.
To resolve the issue either DNS rebind protection can be disabled or you can whitelist the domain t1c.t1t.io to allow this domain.
Applications that want to make use of the Trust1Connector will be run from a specific domain. This means that the Trust1Connector needs to know that certain domains/applications want to make use of the Trust1Connector's functionality.
For these applications to gain access to the Trust1Connectors API we need to whitelist the domain in whats called the cors list. This list contains all the accepted domains that can make use of the Trust1Connector.
In order to correctly function, the Trust1Connector API must be able to connect to its configured Distribution Service. You must allow REST traffic to the following URLs (if applicable):
Acceptance: https://acc-ds.t1t.io
Production: https://ds.t1t.io
A partner can opt for its own Distribution server, whereas the URIs mentioned above, will be defined by the hosting party.
In some cases (environments) the Domain acc-ds.t1t.io or ds.t1t.io are not accessable. If this is because the domain cannot be resolved we do recommend to either ask the network/system administrator to make sure that those domains can be resolved on the network. Or changing the DNS server to the google DNS (8.8.8.8 & 8.8.4.4), this has solved the issue for some of our customers.
Trust1Connector installer is about 20Mb in size. The installed size comes to 40-50Mb.
This includes the Trust1Connector API, Registry and Sandbox.
Trust1Connector installer is about 20Mb in size. The installed size comes to 40-50Mb.
This includes the Trust1Connector API, Registry and Sandbox.
The increased size over windows mainly comes to the way MacOS handles dialogs. These are distributed with the Trust1Connector as seperate binaries.
All endpoints of the Trust1Connector API are secured and require a JWT to access. To obtain a token, an .
This API key must be requested from TRUST1TEAM, or created by the customer if they are hosting their own Distribution Service. The API key must never be used in a front-end application (where the API key can be compromised). The API key is needed to exchange the token, using a Distribution Server, resulting in a short-lived Json Web Token.
A PARTNER can decide to distribute a version without the use of a JWT. In those cases, the liability of the security flow resides completely in the context of the web application, thus Trust1Team can not guarantee the security context where the Trust1Connector is integrated upon.
Trust1Connector support two operating systems for all tokens, Linux (Debian/Ubuntu) for PKCS11 tokens; On request, a Google Chromebook can be supported depending on the deployment or target installer.
MacOS 11.x or higher
X86 architecture
M1/M2/ARM architecture
Windows 810 or higher
Trust1Team support Windows/Mac OSX OS families where lifecycle support is guaranteed from the Vendor of the Operating System. The moment the OS version has been marked as ‘end of life’, Trust1Team can not guarantee the functionality anymore.
When PARTNERS are in need to support an older version or keeping the support running on the level of Trust1Team, no guarantees can be made. Trust1Team can setup a custom project, on demand of the PARTNER. Those requirements, changes or other adaptations needed, are not covered in the Trust1Connector license fee.
2023-10
macOS 14 (Sonoma) has issues at the moment with usblib and CCID. A future patch will fix the card reader issues; Updates will be come avaible when a patch is released
To run in user-space on Windows 8.1 or higher some components have to be set on the operating system
Below you can find a list of all registry keys that will be created for the working of the Trust1Connector, All these keys are added to HKCU
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\SOFTWARE\Trust1Team\Trust1Connector
Since 3.5.x no more cookies are used.
The Trust1Connector is browser agnostic so it does not matter what browser is being used as long as it support HTTP communication (HTTP 1.1) (which should all of them).
Version wise we do recommend to use the latest versions of your browser for security reasons but the versions below is was we accept as a minimum
Chrome >80
Firefox >75
Edge 88 or higher
IE 11 (End of Life is June 15 2022)
Trust1Connector v3 Documentation
The Trust1Connector Javascript SDK is a library that functions as a proxy towards the Trust1Connector API. This Library does not contain any business logic and is a refernce implementation for the Trust1Connector API (HTTP/JSON).
Sample code uses ES6 language features such as arrow functions and promises. For compatibility with IE11, code written with these features must be either transpiled using tools like Babel or refactored accordingly using callbacks which are also available on the Trust1Connector Javascript SDK.
The Trust1Connector is a middleware which interacts with hardware tokens and system certificate stores (where certificates are stored and protected within the operating system).
The ambitions of the Trust1Connector is to:
provide a generic interface to hardware tokens and smart cards
operating system agnostic (works for all operating systems)
browser agnostic (not depending on a browser plugin)
facilitate the onboarding and identity dematrialization
The Trust1Connector after correct initialization has the ability to retrieve the available card readers detected on the system. With these card readers you can continue and execute functionality such as retrieving biometric information, signing data, authentication, ...
Below you can find more information on how to retrieve the available readers. All these functions are available in the Core Service
Returns a list of available card readers. Multiple readers can be connected. Each reader is identified by a unique reader_id.
The response will contains a list of card readers:
When multiple readers are attached to a device, the response will show all connected card readers:
Important to notice:
The response adds a card-element when a card is inserted into the card reader.
The response contains card-reader pin-pad capabilities
As mentioned in the List card-readers, when a smart-card is inserted/detected, the reader will contain the cart-type based on the ATR. The ATR (Anwser To Reset), is the response from any smart-card when powered, and defines the card type.
The Trust1Connector recognized more than 3k smart-card types.
In the response below you notice that this specific card also includes a module and description property.
Both of these are arrays and are also optional. This means that the Trust1Connector recognizes this specific token and knows which module can be used for this token. The Trust1Connector has the possibility to detect that a card can be used by more than 1 module, in that case the module array will display multiple values depicting which modules can be used.
The description is purely metadata.
As mentioned, when a card-reader has pin-pad capabilities, this will be mentioned in the response (notice the pinpadproperty):
The following example is the response for List card-readers on a device with 4 different card-readers attached:
In the above example you notice that 4 card-readers are connected. Each card-reader receives his temporary id which can be used for other functions where a card-reader id is needed.
This method can be requested in order to list all available card-readers, and optional cards-inserted.
Each card-reader has a vendor provided name, which is retrieved from the card-reader itself.
An additional property pinpad, a boolean value, denotes if the card-reader has pin-pad capabilities. A pin-pad is a card-reader, most of the times with its own display and key-pad.
From a security perspective, it's considered best practice to use as much as possible pin-pad capabilities of a pin-pad card-reader.
When a reader has a smart-card inserted (contact interface) or detected (contactless interface), the card type will be resolved by the Trust1Connector in order to respond with a meaningful type.
In the above examples you see that; one card-reader has a Belgian eID card; another card-reader has a MisterCash or VISA Card available for interaction.
Possibility to exclude certain readers based on their name. the input accepts a comma separated list if multiple exclusion terms are needed
This exclude readers will search for the term in the reader names and exclude those that match with the term
Returns a list of available card readers with a smart card inserted. Multiple readers can be connected with multiple smart cards inserted. Each reader is identified by a unique reader_id and contains information about a connected smart card. A smart card is of a certain type. The Trust1Connector detects the type of the smart card and returns this information in the JSON response.
Response:
How the Trust1Connector solves the DNS rebind issue
DNS Rebind automatic resolution is implemented starting from v3.8.4, older version can solve this by following the troubleshooting guide: Connector Connection Issues
The connector is using a DNS (depending on the connector partner), with a default value of:
The given URL is registered with DNSSEC enabled, and resolves to a 'localhost' domain.
Although the connector can run in a different mode (http, localhost, custom domain name, etc.), to solve the above issue, the following causes are probable:
DNS Rebind is enforced from your router or ISP (Internet Service Provider)
The domain name is not whitelisted in your internal network
A local proxy is running and prevents the internal connector communication
An antivirus is blocking the connector communication
The functionality for automatic DNS Rebind resolutation solves the local connectivity issue by adding the DNS used by the connector to the host file of the device.
As the connector is running in user-mode, and thus not have elevated rights, a separate process will be started on the operating system, asking the user to enter the `admin password` only with the purpose of adding the record to the host file of the system.
When a user does not have `administrator` access to his device, and IT administrator can solve the issue (an apply it to all users from that domain).
The following diagram show the logic begin the one-time check. The process runs on startup on a seperate system thread, and when executed succesfully, persists a marker file (.dnsrebind) in the installation directory of the connector.
Starting from from a clean installation, it will go trough the flow above and based on the outcome of the DNS resolving, the process will update the hostfile and create the markerfile
The process will go trough the flow above and when successful, a DNS check is executed which a successful response.
The process will go trough the flow above and when successful, the process will create the marker file without the need of updating the hostfile
The process will go trough the flow above and when `failure`, the process will see the marker file, resulting in a error message that it could not resolve the domain. In this scenario, the markerfile indicates that the hostfile has been updated so the problem must be elsewhere.
The process will go trough the flow above and when `failure`, the process will create the marker file and update the hostfile. When the final DNS check fails and it will return an error message.
Here the markerfile also indicates that the hostfile has been updated so the problem must be elsewhere.
The Trust1Connector core services address communication functionality with local devices. The Trust1Connector core exposes 2 main interfaces:
interface for web/native applications using JavaScrip/Typescript
REST API as a new approach and to incorporate the Trust1Connector as a microservice in the application architecture
In this guide, we target only the use of Trust1Connector's core interface for web/native applications.
The T1C-SDK-JS exposes protected resources for administration and consumer usage.
The JavaScript library must be in order to access the all resource.
Consumer resources are typically used from an application perspective:
Get pub-key certificate
Get version
Get Information (operating system, runtime, user context, variable configuration)
List card-readers (with active card)
Executing these functionality is explained further.
The Trust1Connector functionalities are about secured communication with device hardware.
The document highlights communication with smart card readers - contact and contact-less. Other hardware devices can be enabled or integrated as well in the solution. Some of the already are, for example printer drivers, signature tablet drivers, ...
After you've you can execute the rest of the Trust1Connector's functionality, for example listing the readers and fetching information from a specific smart card.
Returns a list of available card readers. Multiple readers can be connected. Each reader is identified by a unique reader_id.
The response will contains a list of card readers:
When multiple readers are attached to a device, the response will show all connected card readers:
Important to notice:
The response adds a card-element when a card is inserted into the card reader.
The response contains card-reader pin-pad capabilities
As mentioned in the List card-readers, when a smart-card is inserted/detected, the reader will contain the cart-type based on the ATR. The ATR (Anwser To Reset), is the response from any smart-card when powered, and defines the card type.
The Trust1Connector recognized more than 3k smart-card types.
Possibility to exclude certain readers based on their name
This exclude readers will search for the term in the reader names and exclude those that match with the term
As mentioned in the List card-readers, when a card-reader has pin-pad capabilities, this will be mentioned in the response (notice the pinpadproperty):
The following example is the response for List card-readers on a device with 4 different card-readers attached:
In the above example you notice that 4 card-readers are connected. Each card-reader receives his temporary id which can be used for other functions where a card-reader id is needed.
This method can be requested in order to list all available card-readers, and optional cards-inserted.
Each card-reader has a vendor provided name, which is retrieved from the card-reader itself.
An additional property pinpad, a boolean value, denotes if the card-reader has pin-pad capabilities. A pin-pad is a card-reader, most of the times with its own display and key-pad.
From a security perspective, it's considered best practice to use as much as possible pin-pad capabilities of a pin-pad card-reader.
When a reader has a smart-card inserted (contact interface) or detected (contactless interface), the card type will be resolved by the GCL in order to respond with a meaningful type.
In the above examples you see that; one card-reader has a Belgian eID card; another card-reader has a MisterCash or VISA Card available for interaction.
The readers returned, are the card-readers with a card available. The card-readers where no card is presented, are ignored.
Returns a list of available card readers with a smart card inserted. Multiple readers can be connected with multiple smart cards inserted. Each reader is identified by a unique reader_id and contains information about a connected smart card. A smart card is of a certain type. The Trust1Connector detects the type of the smart card and returns this information in the JSON response.
Response:
To retrieve the version of the Javascript SDK you can use the version function available in the CoreService
You can follow the example below to retrieve the version number
The ouput in the log of the code above should look like the following
via the getDevicePublicKey endpoint you're able to fetch the public key information of the device. This requires an authenticated client to be able to access this endpoint.
This endpoint is used in the library to encrypt pin, puk and pace information so that it is not exposed in the network logs of the browser.
Encryption of pin, puk and pace is only possible when the Trust1Connector is registered via a DS and has a valid device key-pair. The SDK will automatically switch to send the pin, puk or pace info in clear text if its not able to encrypt. The Trust1Connector API will also detect if it has no valid device key-pair it will not try to decrypt the incoming pin, puk or pace information.
Via the pushLogs function you can trigger the Trust1Connector to send out the log files towards the Distribution service.