Prerequisites New Token/Smart Card
Guidlines new Partner token/smart-card or other hardware device
Introduction
For a new hardware token to be added to the Trust1Connector framework, we have to take into consideration some necessary prerequisites to assure the development process.
This article presents an explanatory list for all necessities which are needed before development can start. Please take into consideration especially during pre-sales/sales.
The artefacts are explained briefly and listed. In order to support and guarantee operations, Trust1Team will need to have all mentioned artefacts at all times.
Instructions
The following artefacts are needed to reassure development of a new hardware token:
Minimum of 2 test cards (valid, expired, …) with corresponding access codes
Chip/card specifications (interface)/Operating system details (context) f
Specifications of the personalisation of the card [Card Perso Documentation containing APDU commands]
Interface Information
[Optionally - depending on requirements] Card reader used by customer
Operating Systems
1. Test Cards
Test cards are need to:
use the test cards during development, and especially for:
card communication development
card application development
card security layer development
use the test cards during integration testing:
Level 1: APDU Tracing/Testing
Level 2: Sandboxed service layer testing
Level 3: Local Service Integration testing
Level 4: Web Integration testing
A test card guarantees the solution is developed correctly and tested before releasing the artefact in production.
Artefact: physical test cards/hardware tokens in different variations delivered to T1T
2. Chip/Card specifications
Smart-cards or hardware tokens are typically issued by a CA (Certificate Authority), using chips from industrial chip manufacturers. The chip manufacturers are issuing chips with global specifications. Issued chips can have one or more interfaces, sometimes on one single chip on or 2 chips. Typically a combination between contact and/or contactless interfaces.
The global specifications gives information about the following topics:
The operating system used on the chip
The security information needed to access the card context
The security information needed to access the card applications
The security algorithms for key exchange
…
Artefact: a digital document shared with T1T with information on the chip/card specifications. They typically contains APDU statements and sequence diagrams
3. Personalisation Specifications
Personalisation is the process done when issuing a smart-card for production. This is, the hardware is initialised for a specific user, following a template depending on the business context.
The personalisation phase is the phase where custom/specific data/certificates or other data is persisted on the card. Besides the data persistence, the state of the card is set and interfaces are secured.
The personalisation specifications, explain what and how data is stored on the card, the state of the card, and the way that it impacts the interfacing.
In short, the chip/card specifications in step 2, along with the personalisation specifications mentioned above, define the bleu-print of a personalised production card.
Artefact: Personalisation Specifications, a document that states typically how a card has been initialised for production
4. Interface Information
All available information on the interface with the card/chip. The following questions should be answered:
Is there a PKCS 11 interface?
Is there a need for integration with MSCAPI, CNG, ..
Is there a custom defined interface?
Do we need to use a custom external libraries (.dll’s for example) for the integration?
When one of the above questions results in ‘yes’:
deliver the external library with its interface (when cpp: dll and header files)
Artefact: General information optionally enriched with external libraries (including their interfaces)
5. [Depending on Customer Requirements] Card Reader
Depending on the requirements of the customer, it’s possible that the business context demands a specific card reader. This is for example the case in the financial domain. Card readers can have additional security keys, which prevents hardware tokens to be used elsewhere (read::on other card readers).
When this is the case, it is necessary to have a card reader in order to develop and test.
Artefact: Optional card reader for development and testing
6. Operating Systems
Customer requirements for the operating system used in customer base:
Linux (Debian, Ubuntu, CentOS, …)
Windows (only officially supported and NOT EOL)
Mac (NOT EOL)
Last updated