What's new in v2
New features in T1C-JS (v2)
Some browsers are beginning to block self signed certificates. Blocking the v2 web API. For now the V2 should be fine as the certificate is stored in the Windows or MacOS certificate store and is thus automatically trusted.
Upon installation, a new device certificate is generate in order to communicate through HTTPS. The certificate validation is added upon instantiation of a communication channel:
Certificate is valid, the certificate’s public key is synced on the central distribution system-Certificate is invalid (expired or revoked), a new certificate will be generated on the device and public key will be exchanged with the central distribution system
The distribution service has a key exchange algorithm to:-Provide an T1C instance with the public key of a Distribution Service-Provide the Distribution Service with the public key of a device-
Device public keys are managed in the central Distribution Service and are part of the device management. Device management supports:
- Device registration
- Device activation
- Device synchronization
- Device white/black listing
- Managed T1C is a pre-compile and pre-packages installer without the notion of a central distribution service and mainly used in an closed network
- Unmanaged T1C is white labeled, core compilation and packaging, with minimal footprint, which can be activated only in the context of an application using a Distribution Service
A container is sandboxed, logical implementation of a pluggable credential.
The container framework is applicable for unmanaged installers, and provides the following functionality:
- Dynamic Container delivery
- Automatic distribution of new container versions
- Validation of consistency and integrity of containers during transport
- Validation of consistency and integrity of containers upon instantiation
- Container state machine-Container CORS management
Provide a generic container interface towards applications.
In T1C-Core v1:
- For each credential (Lux ID, keystore, token, …) an instance of the specific container had to be created
In T1C-Core v2:
- A generic interface is available for the following use cases-Retrieve data-Retrieve certificates-Digitally sign-Authenticate-Verify PIN
Through the distribution service, an ATR list is maintained for all known smart cards.
In T1C Core v1:
- ATR list was prepackaged in the T1C-GCL.
In T1C Core v2:
- a central ATR list is managed at the T1C-Distribution server, and the ATR list is synchronized for all T1C-GCL upon initiation and only when changes have occurred.
Remote Loading Protocol is a communication channel provided in the T1C for APDU generation server-side.
This prevents the actual logic to reside on a device, and provides a way to safely sign APDU commands when needed (ex. Personalization use cases).
Typically when ‘writes’ are done on a credential, transactions are additionally signed using a HSM, SAM, … Remote loading provide a way to keep your security hardware central in order to fulfill those use cases.
Remote loading acts as if a local smart card is virtually attached to a central server.
In order to prevent applications to access a local T1C instance, additional measure are taken in place, depending additionally on CORS (Cross-origin resource sharing) specification (residing in the browser context).
This means that the access to a T1C instance is limited to a specified list of domains, which must be know up front.
In T1C Core v1:
- in order to access the admin interface, a signed JWT was needed. But containers could be accessed by 3rd P applications as well.
In T1C Core v2:
- application that can request services from T1C instances are limited to applications (application domains) having:-Valid apikey/JWT-Provided in the CORS list on container level
In Core v1:
- A container configuration was a pre-compiled file, with an OS dependency (dlib for mac, dll for win, …)
In Core v2:
- A container is always a compressed file (zip) which contains:
- Manifest file
- Configuration file
- Container library
- Depending libraries
Container can depend on each other, dependencies are automatically resolved in the Distribution server, and the application doesn’t need to deal with container dependencies.
Logging information for a local device is made available through the API.
In Core v1:
- Device logging – anonymized - can be found on the local drive of the user. In order to retrieve this file, a user must be guided to the file location which is different depending on the underlying operating system.
In Core v2:
- Log files are available through the JS/Java libraries and can be requested for support or debugging purposes.
- Pin encryption in the browser context for pin dialogs in application context
- Provide additional ability to enter pin on OS level (besides application PIN entry and smart card reader pin pad PIN entry)
- Optional user consent mechanism for reader or file system communication
- DS key exchange and support multiple DSs
- JS/Java lib can be instantiated using signed JWT (in addition to api-key)
On some systems the CCID (chip card interface device) driver is not installed. This driver is used for the pinpad detection of connected readers. We've added support to detect some pinpad readers when the CCID driver is not installed. Currently supported readers:
- VASCO DIGIPASS 870
- VASCO DIGIPASS 875
- VASCO DIGIPASS 920
- VASCO DIGIPASS 840
- VASCO DIGIPASS 876
- Gemalto ING Shield Pro