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.
Introduction
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
Interface
Models
All model information can be found in the
Get Belgian eID container object
Initialise a Trust1Connector client:
Get the Belgian eID container service:
Call a function for the Belgian eID container:
Obtain the Reader-ID
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.
Cardholder Information
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).
Biometric data
Contains all card holder related data, excluding the card holder address and photo.
The service can be called:
An example callback:
Response:
Address
Contains the card holder's address. The service can be called:
Response:
Picture
Contains the card holder's picture stored on the smart card. The service can be called:
Response:
Token info
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 can either be a BaseTokenInfo or a PKCS11TokenInfo object. Depending if its a pkcs11 token or not
Token version
The token version function is a specific function for Belgian eID. It will return the version of the card in the reader.
This can either be 1.7 or 1.8
Certificates
Exposes all the certificates publicly available on the smart card.
Extended certificates
You can also fetch the extended versions of the certificates via the functions
this has the capabilities to return multiple certificates if the token has multiple of this type.
for a single certificate the response looks like:
the allCertsExtended returns the following, with the contents of the certificates as the one you can see above;
Root Certificate
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:
Authentication Certificate
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:
Intermediate Certificate (citizen)
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:
Non-repudiation Certificate
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:
Encryption Certificate (RRN)
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:
Data Filter
Filter Card Holder Data
All data on the smart card can be dumped at once, or using a filter. In order to read all data at once:
Options are; biometric, picture and address
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:
Filter Certificates
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:
Sign Data
Algorithm
As the Beid module incorperates Beid 1.7 and 1.8 there is a difference in the algorithms being used.
In 1.7 we have the following;
md5
sha1
sha256
For beid 1.8 we have;
sha2_256
sha2_384
sha2_512
As we've noticed most integrators use sha256 and to make sure current integrations do not break we have made the Trust1Connector to map sha256 to sha3_256 for beid 1.8. Ofcourse if you want to use a specifc supported algorithm you can still select them.
By default the 1.7 will fall back to sha256 and 1.8 to sha3_256 if an incompatible algorithm is passed to the function.
The tables below explain which algorithm will be used when providing a certain algorithm value in the function;
Belgian EID 1.7
Belgian EID 1.8
Signing
Data can be signed using the Belgian eID smart card. To do so, the T1C 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'.
Signing with a Crelan card reader
When signing with a crelan card reader, it is additionally possible to optionally specify a transaction ID and the language. If the card reader is not a Crelan reader, these values will be ignored. This applies to all signing methods described below.
Crelan card readers only support nl, fr, and de as languages
Sign Hash without 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:
Response of Sign returns a base64 encoded value which is the signature data. For belgian eid 1.8 this uses ECDSA and these signatures are returned in plain format, encoded as a direct concatenation of two byte strings r || s. This is also referred as PLAIN_ECDSA
For more information on this you can visit the
Sign Hash with pin-pad
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 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.
Raw data signing
With the function signRaw you can sign unhashed document data. This means that the Trust1Connector will hash the value itself depending on the provided sign algorithm.
Trust1Connector only supports SHA2 hashing at this point.
SHA3 digest is used for the new Belgian eID cards (v1.8). The Trust1Connector falls back in this situation by using implicitly a SHA2 digest.
Below you can find an example
The function looks the same as a regular sign operation but expects a base64 data object that is unhashed.
Supported hash functions (SHA2) are;
SHA256
SHA384
SHA512
Bulk Signing
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.
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.
Bulk PIN Reset
The PIN set for bulk signing can be reset by calling this method.
Response will look like:
Calculate Hash
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 can use the following online tool to calculate the 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:
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:
Example Hashes
Digest Alg
Digest Example
Verify PIN
Verify PIN without pin-pad
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:
Verify PIN with pin-pad
When the pin entry is done on the pin-pad, the following request is used to verify a given PIN:
Response:
Verify PIN - retries left
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:
Note that, when the user has at least one retry left, entering a correct PIN resets the PIN retry status.
For more information about the error codes you can check the
Authentication
Algorithm
As the Beid module incorperates Beid 1.7 and 1.8 there is a difference in the algorithms being used.
In 1.7 we have the following;
md5
sha1
sha256
For beid 1.8 we have;
sha2_256
sha2_384
sha2_512
As we've noticed most integrators use sha256 and to make sure current integrations do not break we have made the Trust1Connector to map sha256 to sha3_256 for beid 1.8. Ofcourse if you want to use a specifc supported algorithm you can still select them.
By default the 1.7 will fall back to sha256 and 1.8 to sha3_256 if an incompatible algorithm is passed to the function.
The tables below explain which algorithm will be used when providing a certain algorithm value in the function;
Belgian EID 1.7
Belgian EID 1.8
The T1C 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:
Get valid algorithms to use for Sign or Authenticate
Via the Trust1Connector modules you are able to retrieve available algorithms to use for Signing or Authenticate
The response you can expect is a list of algorithms, an example can be found below (the values below are purely examplatory)
sha512
sha3_256
sha3_384
sha3_512
sha3_512
sha256
sha3_256
sha384
sha3_384
sha512
sha3_512
any other value
sha3_256
sha512
sha3_256
sha3_384
sha3_512
sha3_512
sha256
sha3_256
sha384
sha3_384
sha512
sha3_512
any other value
sha3_256
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).
var data = {
"pin":"...",
"algorithm":"sha256",
"data":"E1uHACbPvhLew0gGmBH83lvtKIAKxU2/RezfBOsT6Vs="
}
client.beid(reader_id).signData(data, callback);
var data = {
"pin":"..."
}
client.beid(reader_id).verifyPin(data, callback);
{
"verified": true
}
var data = {}
client.beid(reader_id).verifyPin(data, callback);
{
"verified": true
}
$("#buttonValidate").on('click', function () {
var _body={};
_body.pin = $("#psw").val(); //only when no pin-pad available
var beid = client.beid(reader_id);
beid.verifyPin(_body, validationCallback);
});
var data = {
"pin": "...",
"algorithm": "sha1",
"data":"I2e+u/sgy7fYgh+DWA0p2jzXQ7E="
}
client.beid(reader_id).authenticate(data, callback);
The calculated digest of the hash is prefixed with:
DigestInfo ::= SEQUENCE {
digestAlgorithm AlgorithmIdentifier,
digest OCTET STRING
}
Make sure this has been taken into consideration in order to validate the signature in a backend process.