Aventra
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
Interface Summary
The Abstract Aventra smartcard interface is summarized in the following snippet:
Retrieve a connected card reader
In order to start with any use case, we need to select a card reader. The targeted reader will be passed as a parameter to the subsequent methods provided. This is part of the core Trust1Connector functionality. More information about core service functionality can be found on the following page: Core Services.
For demonstration purpose we'll add a simple console output callback, which we'll use throughout the documentation.
Just as an example, we instantiate a new gcl (local client) and ask for all connected smart card readers:
This will returns us all connected readers:
In the example you'll notice that we are using a dual interface uTrust reader, and a card has been inserted.
The reader id '2e49386c82131cc1' can be used as parameter in the next steps in order to select a smartcard reader for the functionality we want to execute.
Applet information
The following call can be done in order to retrieve the Aventra applet information on the card:
Example response:
Certificates
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
T1C-JS will return the raw base64 certificate and the ID of the certificate., optionally it can also return an object representing the certificate as parsed by PKI.js. To enable parsing, parseCerts
must be set to true
. The ID will be required by the signature functions as it indicates which private key linked to the certificate will be used to perform the signing.
Certificate Chain
Root Certificate
Contains the 'root certificate' stored on the smart card. 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, authentication and signing. In the response the whole certificate chain will be returned, with the authentication certificate as the first item. The service can be called:
Response:
Signing 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. In the response the whole certificate chain will be returned, with the signing certificate as the first item. The service can be called:
Response:
Issuer Certificate
The service can be called:
Response:
Encryption Certificate
In the response the whole certificate chain will be returned, with the encryption certificate as the first item.
The service can be called:
Response:
Data Filter
Available Data Filters
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 'root-certificate' and the 'authentication_certificate':
Response:
Verify PIN
Without a pinpad
When the web or native application is responsible for showing the password input, the following request is used to verify a card holder PIN:
The allowed values for private_key_reference
are authenticate
, sign
and encrypt
. These values allow you to indicate which PIN code you want to verify.
Response:
With a pinpad
When the pin entry is done on the pin-pad, the following request is used to verify a card holder PIN:
Response:
Reset PIN
When the web or native application is responsible for showing the password input, the following request is used to reset a PIN using the PUK code when the PIN is blocked:
The allowed values for private_key_reference
are authenticate
, sign
and encrypt
. These values allow you to indicate which PIN code you want to reset.
Response:
The possible "private_key_reference" values can be retrieved calling:
Sign Data
Data can be signed using the Aventra smartcard. To do so, the T1C-GCL 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 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 algorithm references supported by the card
In order to verify which algorithm can be used for a 'sign' operation, you can call the following method:
Example response:
Sign Hash
In the sign data, you'll need to pass the identifier (id) of the signing certificate which is retrieved by the certificate endpoints.
Without a pinpad
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:
With a pinpad
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 and sha512.
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.
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 might have noticed the algorithm_reference
property provided in the sign
request.
The algorithm_reference
can be one of the values: sha1, sha256 and sha512.
For example, we want the following text to be signed using:
You can use the following online tool to calculate the SHA1: http://www.sha1-online.com
Hexadecimal result:
Notice that the length of the SHA1 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:
Authentication
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.
Authentication algorithm references supported by the card
In order to verify which algorithm can be used for a 'sign' operation, you can call the following method:
Example response:
External Challenge
Without a pinpad
An external challenge is provided in the data property of the following example:
Response:
Without a pinpad
An external challenge is provided in the data property of the following example:
Response:
The 'algorithm_reference' property can contain the following values: sha1, sha256 and sha512.
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).
Error Handling
Error Object
The functions specified are asynchronous and always need a callback function. The callback function will reply with a data object in case of success, or with an error object in case of an error. An example callback:
The error object returned:
For the error codes and description, see Status codes.
Last updated