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 Belgian eID container facilitates communication with card readers with inserted Belgian eID smart card. The T1C-JS client library provides function to communicate with the smart card and facilitates integration into a web or native application. This document describes the functionality provided by the Belgian eID container on the T1C-GCL (Generic Connector Library).
All model information can be found in the Token typings model page
Initialise a Trust1Connector client:
Get the Belgian eID container service:
Call a function for the Belgian eID container:
The constructor for the Belgian eID expect as the parameter to be a valid reader-ID. A reader-ID can be obtained from the exposed core functionality, for more information see Core services responds with available card-readers, available card in a card-reader, etc. For example: In order to get all connected card-readers, with available cards:
This function call returns:
We notice that a card object is available in the response in the context of a detected reader.
The reader in the example above is Bit4id miniLector
, has no pin-pad capabilities, and there is a card detected with given ATR and description "Belgian eID Card".
An ATR (Answer To Reset) identifies the type of a smart-card.
The reader, has a unique ID, reader_id
; this reader_id
must be used in order to request functionalities for the Belgian eID card.
This must be done upon instantiation of the Belgian eID container:
All methods for beid
will use the selected reader - identified by the reader_id
.
The card holder is the person identified using the Belgian eID card. It's important to note that all data must be validated in your backend. Data validation can be done using the appropriate certificate (public key).
Contains all card holder related data, excluding the card holder address and photo. The service can be called:
An example callback:
Response:
Contains the card holder's address. The service can be called:
Response:
Contains the card holder's picture stored on the smart card. The service can be called:
Response:
The token info contains generic information about the card and it's capabilities. This information includes the serial number, file types for object directory files, algorithms implemented on the card, etc.
Response:
Exposes all the certificates publicly available on the smart card.
Contains the 'root certificate' stored on the smart card. The root certificate is used to sign the 'citizen CA certificate'. When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not. The service can be called:
Response:
Contains the 'authentication certificate' stored on the smart card. The 'authentication certificate' contains the public key corresponding to the private RSA authentication key. The 'authentication certificate' is needed for pin validation and authentication. When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not The service can be called:
Response:
Contains the citizen certificate stored on the smart card. The 'citizen certificate' is used to sign the 'authentication certificate' and the 'non-repudiation certificate'. When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not The service can be called:
Response:
Contains the 'non-repudiation certificate' stored on the smart card. The 'non-repudiation certificate' contains the public key corresponding the private RSA non-repudiation key. When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not The service can be called:
Response:
Contains the 'encryption certificate' stored on the smart card. The 'encryption certificate' corresponds to the private key used to sign the 'biometric' and 'Address' data. When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not The service can be called:
Response:
All data on the smart card can be dumped at once, or using a filter. In order to read all data at once:
Response:
The filter can be used to ask a list of custom data containers. For example, we want to read only the biometric data
Response:
All certificates on the smart card can be dumped at once, or using a filter. In order to read all certificates at once:
Response:
The filter can be used to ask a list of custom data containers. For example, we want to read only the rootCertificate
Response:
Data can be signed using the Belgian eID smart card. To do so, the T1C-GCL facilitates in:
Retrieving the certificate chain (citizen-certificate, root-certificate and non-repudiation certificate)
Perform a sign operation (private key stays on the smart card)
Return the signed hash
To get the certificates necessary for signature validation in your back-end:
Response:
Depending on the connected smart card reader. A sign can be executed in 2 modes:
Using a connected card reader with 'pin-pad' capabilities (keypad and display available)
Using a connected card reader without 'pin-pad' capabilities (no keypad nor display available)
Security consideration: In order to sign a hash, security considerations prefer using a 'pin-pad'.
When the web or native application is responsible for showing the password input, the following request is used to sign a given hash:
Response is a base64 encoded signed hash:
The 'authenticationreference' property can contain the following values: sha1, sha256, sha512, md5.
When the pin entry is done on the pin-pad, the following request is used to sign a given hash:
Response is a base64 encoded signed hash:
The 'algorithm_reference' property can contain the following values: sha1, sha256, sha512, md5.
The core services lists connected readers, and if they have pin-pad capability. You can find more information in the Core Service documentation on how to verify card reader capabilities.
It is possible to bulk sign data without having to re-enter the PIN by adding an optional bulk
parameter set to true
to the request. Subsequent sign requests will not require the PIN to be re-entered until a request with bulk
being set to false
is sent, or the Bulk Sign Reset method is called.
When using bulk signing, great care must be taken to validate that the first signature request was successful prior to sending subsequent requests. Failing to do this will likely result in the card being blocked.
The PIN set for bulk signing can be reset by calling this method.
Response will look like:
In order to calculate a hash from the data to sign, you need to know the algorithm you will use in order to sign.
You might have noticed the algorithm_reference
property provided in the sign
request.
The algorithm_reference
can be one of the values: md5, sha1, sha256, sha512.
For example, we want the following text to be signed using sha256
:
You can use the following online tool to calculate the SHA256: calculate SHA256
Hexadecimal result:
Notice that the length of the SHA256 is always the same. Now we need to convert the hexadecimal string to a base64-encoded string, another online tool can be used for this example: hex to base64 converter
Base64-encoded result:
Now we can sign the data:
Result:
Note: If you want to convert a binary signed hash to HEX (for development) you can use for example an online hexdump tool:
http://www.fileformat.info/tool/hexdump.htm
When the web or native application is responsible for showing the password input, the following request is used to verify a card holder PIN:
Response:
When the pin entry is done on the pin-pad, the following request is used to verify a given PIN:
Response:
In order to inform a user upon the PIN retries left, the Belgian eID doesn't provide a request to retrieve this information. After an unsuccessful PIN verification, the error code indicates the number of retries left. For example, when executing:
The following error message will be returned when PIN is wrong:
After a second wrong PIN verification:
Note that, when the user has at least one retry left, entering a correct PIN resets the PIN retry status
.
The T1C-GCL is able to authenticate a card holder based on a challenge. The challenge can be:
provided by an external service
provided by the smart card An authentication can be interpreted as a signature use case, the challenge is signed data, that can be validated in a back-end process.
External Challenge
An external challenge is provided in the data property of the following example:
Response:
Take notice that the PIN property can be omitted when using a smart card reader with pin-pad capabilities. The 'algorithm_reference' property can contain the following values: sha1, sha256, sha512, md5.
Generated Challenge
A server generated challenge can be provided to the JavaScript library. In order to do so, an additional contract must be provided with the 'OCV API' (Open Certificate Validation API).
The Luxembourg ID container facilitates communication with card readers with inserted Luxembourg ID smart card. The T1C-JS client library provides function to communicate with the smart card and facilitates integration into a web or native application. This document describes the functionality provided by the Luxembourg ID container on the T1C-GCL (Generic Connector Library).
The Abstract Lux eID interface is summarised in the following snippet:
Each interface will be covered on this wiki, accompanied with example code and response objects.
Initialise a Trust1Connector client:
Get the Luxembourg ID container service:
Note that we pass both the reader_id
and pin/can
and specify the pin_type
in this call. Unlike other cards, all communication with the Luxembourg ID card is protected with the PIN or CAN code.
Call a function for the Luxembourg ID container:
For demonstration purpose we will use the aforementioned callback, which only outputs the data and eventual error messages. During integration meaningful functionality should be provided.
The pin should be provided in order to instantiate the container. It's is possible to enforce user PIN entry for each function separately. Providing the PIN at instantiation of the container, means that the PIN will be in the browser session - but not persisted - for the lifetime of the container instance within the browser session.
This function call returns:
We notice that a card object is available in the response in the context of a detected reader.
The reader in the example above is iDentiv CL
, has no pin-pad capabilities, and there is a card detected with given ATR and description "Grand Duchy of Luxembourg...".
An ATR (Answer To Reset) identifies the type of a smart-card.
The reader, has a unique ID, reader_id
; this reader_id
must be used in order to request functionalities for the Luxembourg eID card.
This must be done upon instantiation of the container:
All methods for luxeid
will use the selected reader - identified by the reader_id
.
The card holder is the person identified using the Luxembourg eID card. It's important to note that all data must be validated in your backend. Data validation can be done using the appropriate certificate (public key).
Contains all biometric related data, excluding the card holder address and picture. The service can be called:
An example callback:
Response:
Contains the card holder's address. The service can be called:
Response:
Contains the card holder's picture stored on the smart card. The service can be called:
Response:
Contains an image of the card holder's signature stored on the smart card. The service can be called:
Response:
Exposes all the certificates publicly available on the smart card. The following certificates can be found on the card:
Root certificate
Intermediate certificate
Authentication certificate
Non-repudiation certificate
The root and intermediate certificates are both stored as root certificates.
Contains the 'root certificate' stored on the smart card. The root certificate is used to sign the 'intermediate certificate'. The service can be called:
Response:
There are 2 root certificates on the card, one is the issuer certificate of the intermediate
Contains the 'authentication certificate' stored on the smart card. The 'authentication certificate' contains the public key corresponding to the private RSA authentication key. The 'authentication certificate' is needed for pin validation, authentication and singing. The service can be called:
Response:
Contains the 'non-repudiation certificate' stored on the smart card. The 'non-repudiation certificate' contains the public key corresponding the private RSA non-repudiation key. The service can be called:
Response:
All data on the smart card can be dumped at once, or using a filter. In order to read all data at once:
Response:
The filter can be used to ask a list of custom data containers. For example, we want to read only the 'rn', 'picture' and 'rrn certificate':
Response:
All certificates on the smart card can be dumped at once, or using a filter. In order to read all certificates at once:
Response:
The filter can be used to ask a list of custom data containers. For example, we want to read only the 'root-certificate' and the 'rrn-certificate':
Response:
Data can be signed using the Luxembourg ID smart card. To do so, the T1C-GCL facilitates in:
Retrieving the certificate chain (root, inetermediate and non-repudiation certificate)
Perform a sign operation (private key stays on the smart card)
Return the signed hash
To get the certificates necessary for signature validation in your back-end:
Response:
Depending on the connected smart card reader. A sign can be executed in 2 modes:
Using a connected card reader with 'pin-pad' capabilities (keypad and display available)
Using a connected card reader without 'pin-pad' capabilities (no keypad nor display available)
Security consideration: In order to sign a hash, security considerations prefer using a 'pin-pad'.
When the web or native application is responsible for showing the password input, the following request is used to sign a given hash:
Response is a base64 encoded signed hash:
The 'authentication_reference' property can contain the following values: sha1, sha256, sha512, md5.
Avoid using SHA-1: is deprecated on the interface and will not be available in the future
In order to calculate a hash from the data to sign, you need to know the algorithm you will use in order to sign.
You might have noticed the algorithm_reference
property provided in the sign
request.
The algorithm_reference
can be one of the values: md5, sha1, sha256, sha512.
For example, we want the following text to be signed using sha256
:
Hexadecimal result:
Base64-encoded result:
Now we can sign the data:
Result:
When the web or native application is responsible for showing the password input, the following request is used to verify a card holder PIN:
Response:
In order to inform a user upon the PIN retries left, the Luxembourg eID doesn't provide a request to retrieve this information. After an unsuccessful PIN verification, the error code indicates the number of retries left. For example, when executing:
The following error message will be returned when PIN is wrong:
After a second wrong PIN verification:
Note that, when the user has at least one retry left,entering a correct PIN resets the PIN retry status
.
The T1C-GCL is able to authenticate a card holder based on a challenge. The challenge can be:
provided by an external service
provided by the smart card An authentication can be interpreted as a signature use case, the challenge is signed data, that can be validated in a back-end process.
External Challenge
An external challenge is provided in the data property of the following example:
Response:
Take notice that the PIN property can be omitted when using a smart card reader with pin-pad capabilities. The 'algorithm_reference' property can contain the following values: sha1, sha256, sha512, md5.
Generated Challenge
A server generated challenge can be provided to the JavaScript library. In order to do so, an additional contract must be provided with the 'OCV API' (Open Certificate Validation API).
All model information can be found in the
The constructor for the Luxembourg ID expect as the parameter to be a valid reader-ID. A reader-ID can be obtained from the exposed core functionality, for more information see . Core services responds with available card-readers, available card in a card-reader, etc. For example: In order to get all connected card-readers, with available cards:
T1C-JS will return the raw base64 certificate, optionally it can also return an object representing the certificate as parsed by . To enable parsing, parseCerts
must be set to true
.
You can use the following online tool to calculate the SHA256:
Notice that the length of the SHA256 is always the same. Now we need to convert the hexadecimal string to a base64-encoded string, another online tool can be used for this example:
Code
Description
301
Warning: the user can try twice more to verify his PIN
301
Warning: the user has only 1 retry left, after this the PIN must be reset at the local municipally
301
Error: the PIN is blocked, the PIN must be reset at the local municipally
Code | Description |
| Warning: the user can try twice more to verify his PIN |
| Warning: the user has only 1 retry left, after this the PIN must be reset at the local municipally |
| Error: the PIN is blocked, the PIN must be reset at the local municipally |
Trust1Connector v3 Release Documentation
The Trust1Connector is a technical product that aims to make all hardware tokens, used for authentication and digital signing, interoperable in a web environment. No operating system dependencies to take into account, no browser dependencies, and compatible with smart-card readers, contactless readers and pin-pad readers/terminals.
Our mission is straight forward our focus is to enable secured communication, from a web application, to a desktop device, in the world of person identity, mainly for the following use cases:
Read token information (personal info, ICAO, ...)
Read certificates, certificate chains or certificate information
Verify a known password (PIN, PUK, CAN, ...)
Authenticate using a hash
Digitally sign a hash
Our mission is to add all token profiles we find in B2C and B2B, government, banking, insurance, health, ...
This library is an SDK meant for fast integration in a web application. We promote although the use of the REST API. After installation of the middleware, from an application perspective, you can consume the functionalities as you do with other microservices. The application will need any REST client, in any language to enable all card communication functionalities.
As the connector exists for more than 5 years, Trust1Team decided to enhance the design, security, functionalities, ... and to incorporate all feedback of existing partners into the Trust1Connector v3.
The library has evolved as a technology product for smart card communication to a framework of secured communication from a browser to any hardware device. In our eco-system we have implemented communication to various printers, signature tablets, biometric devices etc.
During the years, the Trust1Connector has evolved from a product to be installed on standalone dekstops to a product which can be used on shared environments such as Citrix, XenApp, ...
In order to guarantee secured communication, former versions needed a user to have administrator rights during the installation. From this release on, the solution runs completely in user space, sandboxed and hardened. No user data is compromised and thus the solution is GDPR compliant.
The following list describes the characteristics of the Trust1Connector:
Browser independent (no impact upon browser update)
No need for browser plugin
Based on official communication standards, security standards and regulations
No additional software needed, the middleware includes it's own dependencies
Recoverability build-in, preventive checks and tamper-proof
Coops with multiple card readers/terminals (contact and contactless)
Coops with multiple card types (we call it card application profiles)
Extendable and secured framework, we are open to add any card the business needs on our platform
Installers for all supported versions of Mac, Windows and Linux
Installers for Citrix, XenApp or other shared environments
Aventra MyEID PKI Card is a cryptographic smart card conforming to common Public Key Infrastructure standards like ISO/IEC-7816 and PKCS#15v1.0 specification. It can be used for various tasks requiring strong cryptography, e. g. logging securely to Windows, encrypting e-mail, authentication, and electronic signatures. The card is also available as a Dual Interface version, compatible with T=CL protocol and also emulating Mifare™. The card is a JavaCard with Aventra MyEID applet that implements the functionality.
The applet implements the FINEID S1 v1.12 specification and it can be configured to include all or any subset of the features specified in FINEID S4-1 or S4-2 specifications. Starting from version 2.2.0 the applet supports both 1024 and 2048 bit RSA keys. From version 3.0.0 (MyEID3) the applet supports keys from 512 bit up to 2048 bit in increments of 64 bits. The applet is fully compatible with JavaCard 2.1.1 and GlobalPlatform 2.0.1 specifications. The new MyEID version 3 (MyEID3) is now released and it uses the new JavaCard 2.2.1 and GlobalPlatform 2.1.1 platform. The new MyEID3 now supports RSA keys from 512 up to 2048 bits in 64 bit increments. MyEID3 supports file sizes up to 32767 bytes and 14 different PIN-codes can be created and used. The number of RSA keys is only limited by the available memory and maximum numbers of files (see PUT DATA: INITIALISE APPLET).
References
The most relevant specifications and standards are:
ISO/IEC 7816-4
ISO/IEC 7816-8
ISO/IEC 7816-9
JavaCard 2.1.1, MyEID3: 2.2.1
GlobalPlatform 2.0.1 ' (Open Platform), MyEID3: GlobalPlatform 2.1.1
FINEID S1 and S4 documentation
This document describes the functionality provided by the Aventra smartcard - which is a PKI container - on the T1C-GCL (Generic Connector Library) implemented version:
MyEID - reference manual v1.7.36
When initialisation is finished you can continue using the aventra object to execute the functions below.
The expected response for this call should be;
The expected response for this call should be;
Exposes all the certificates publicly available on the smart card. The following certificates can be found on the card:
Root certificate
Signing certificate
Authentication certificate
Issuer certificate
Encryption certificate
When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not.
The expected response for this call should be;
This will return information of the Aventra card.
The expected response for this call should be;
When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not.
Contains the 'root certificate' stored on the smart card.
Contains the 'authentication certificate' stored on the smart card. The 'authentication certificate' contains the public key corresponding to the private RSA authentication key. The 'authentication certificate' is needed for pin validation, authentication and signing.
Contains the 'non-repudiation certificate' stored on the smart card. The 'non-repudiation certificate' contains the public key corresponding the private RSA non-repudiation key.
The expected response for these calls should be in the following format;
The expected response for these calls should be in the following format;
When using bulk signing, great care must be taken to validate that the first signature request was successful prior to sending subsequent requests. Failing to do this will likely result in the card being blocked.
The expected response for this call should be;
The PIN set for bulk signing can be reset by calling this method.
Response will look like:
The expected response for this call should be;
The expected response for this call should be;
The expected response for this call should be;
The ID-One Cosmo V7-n is part of the Oberthur family of cryptographic modules called ID-One Cosmo V7. Modules within
this family share the same functionalities and the description of the ID-One Cosmo V7 applies to all versions including the “-n” subject to this validation.
This document describes the functionality provided by the Oberthur ID-One smartcard - which is a PKI container - on the T1C-GCL (Generic Connector Library) implemented version:
ID-One Cosmo V7-n; FIPS 140-2 Security Policy
When initialisation is finished you can continue using the aventra object to execute the functions below.
The expected response for this call should be;
The expected response for this call should be;
Exposes all the certificates publicly available on the smart card. The following certificates can be found on the card:
Root certificate
Signing certificate
Authentication certificate
Issuer certificate
Encryption certificate
When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not.
The expected response for this call should be;
This will return information of the Aventra card.
The expected response for this call should be;
When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not.
Contains the 'root certificate' stored on the smart card. The service can be called:
Contains the 'authentication certificate' stored on the smart card. The 'authentication certificate' contains the public key corresponding to the private RSA authentication key. The 'authentication certificate' is needed for pin validation, authentication and singing. The service can be called:
Contains the 'non-repudiation certificate' stored on the smart card. The 'non-repudiation certificate' contains the public key corresponding the private RSA non-repudiation key. The service can be called:
The expected response for these calls should be in the following format;
The expected response for these calls should be in the following format;
Data can be signed using the smartcard. To do so, the SDK facilitates in:
Retrieving the certificate chain (root, intermediate and non-repudiation certificate)
Perform a sign operation (private key stays on the smart card)
Return the signed has
When using bulk signing, great care must be taken to validate that the first signature request was successful prior to sending subsequent requests. Failing to do this will likely result in the card being blocked.
The expected response for this call should be;
The PIN set for bulk signing can be reset by calling this method.
Response will look like:
The SDK is able to authenticate a card holder based on a challenge. The challenge can be:
provided by an external service
provided by the smart card
An authentication can be interpreted as a signature use case, the challenge is signed data, that can be validated in a back-end process.
The expected response for this call should be;
The expected response for this call should be;
All model information can be found in the
To sign data, an algorithm must be specified in the algorithm
property (see ), and a Base64-encoded string representation of the digest bytes of the same algorithm in the data
property.
Additionally, it is possible to bulk sign data without having to re-enter the PIN by adding an optional bulk
parameter set to true
to the request. Subsequent sign requests will not require the PIN to be re-entered until a request with bulk
being set to false
is sent, or the method is called.
All model information can be found in the
To sign data, an algorithm must be specified in the algorithm
property (see ), and a Base64-encoded string representation of the digest bytes of the same algorithm in the data
property.
Additionally, it is possible to bulk sign data without having to re-enter the PIN by adding an optional bulk
parameter set to true
to the request. Subsequent sign requests will not require the PIN to be re-entered until a request with bulk
being set to false
is sent, or the method is called.
Each lawyer in Belgium registered at the balie is obliged since 1/1/2018 to have an electronic lawyer card. This is declared in atr. 193bis of the Codex Deontologie voor Advocaten:
“De advocaat moet voor zijn identificatie en voor de authenticatie beschikken over de elektronische CCBE-advocatenkaart.”
More info at https://www.diplad.be/en-GB/t/23/elektronische-advocatenkaart.aspx.
All model information can be found in the Token typings model page
Response will look like: