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
Device public key exchange in Distribution Service
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 white/black listing
Container framework for unmanaged installers
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
Generic Credential Interface
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
ATR Management and redistribution
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
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.
White/black listing application access
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
Compressed container downloads
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:
Support for container dependencies
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.
Additional security measurements
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)
Pinpad detection without CCID driver
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: