Prerequisites New Token/Smart Card

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:

1. Minimum of 2 test cards (valid, expired, …) with corresponding access codes

2. Chip/card specifications (interface)/Operating system details (context) f

3. Specifications of the personalisation of the card [Card Perso Documentation containing APDU commands]

4. Interface Information

5. [Optionally - depending on requirements] Card reader used by customer

6. 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)