The BlueX digital ID management system was designed as a flexible system to perform all tasks related to Digital ID management. It works with cryptographic tokens (smart cards and USB tokens) as carriers of Digital Identities / certificates and their corresponding keys.

The BlueX System is a distributed system. A functional instance of BlueX consists of the BlueX Core and a BlueX Flow.

A BlueX Flow is a model of a company workflow. It is installed on the same server as the BlueX Core. BlueX workflows are configured manually, according to the customer’s specifications. This configuration can be done locally, after installing BlueX Core, or it can be done in advance. Some standard templates are included.

The BlueX Application Server is the heart of the BlueX environment. All other components in the BlueX environment communicate with it to perform their functions. The BlueX Application Server runs on a server, and is the switchboard for the other BlueX components.

The BlueX database runs on a server. It is used to keep records of all actions performed by BlueX. In most BlueX environments, BlueX must keep record of the managed cards, requests and certificates. Currently BlueX supports three databases, Postgres, MS SQL Server and Oracle.

BlueX Crypt Service is responsible for handling hardware based encryption of sensitive data that must be stored and protected by BlueX. The Crypt Service uses encryption key(s) in hardware. Encryption can take place on a token or on a HSM.

The BlueX Scheduler component handles all Scheduled Actions in the BlueX workflow.

The BlueX Logger handles the writing of all log information to the Secure Audit Log.

The BlueX Self Service Portal allows a cardholder to unlock a blocked PIN without the involvement of a BlueX Operator.

The BlueX LRA (Local RemoteComponent Authentication) Server is used to link a remote component to a roaming operator. It is used where operators use different workstations, and require remote component functionality to ‘follow’.

The Remote Personalisation Component executes all digital token personalisation tasks, which are performed on the chip of the token, such as initializing, setting PIN and PUK codes, generating keys, writing certificates etc. A BlueX environment may contain any number of Remote Personalisation components. Each client machine on which token personalisation will be performed must have at least one Remote Personalisation component installed.

The Remote Printing Component is used to perform all printing tasks for BlueX, like smartcard printing and printing of secure PIN-letters. Remote Printing also controls the movement of smartcards (or “tracking”) inside smartcard printers, with or without integrated smartcard readers. Printing and tracking of a smartcard is usually done from the same client machine as the digital personalisation of the card. For this purpose the Remote Printing Component and the Remote Personalisation Component are often installed on one machine.

The Remote Capture Component is used to interact with image devices, like a camera, to capture a picture of the cardholder. The remote capture is installed with specific third-party image software, to capture, enhance, edit and check images. This software supports capturing images from (live) cameras, webcams, scanners and other TWAIN devices, as well as loading images from file.

Sometimes the Remote Capture Component is installed on the personalisation client machine, to facilitate a one-step production process, in which the cardholder has his picture taken and receives his personalised smartcard in a single process. In most cases however, the photo capture process is executed at a different point in the workflow and card-distribution is performed at a different location, for example a reception desk.

The Remote Card Reader Component is responsible for interaction with a contactless chip embedded in a smartcard. In the current version of BlueX interaction is limited to reading, and only Legic contactless chips are supported.

A BlueX environment may contain any number of Remote Card Reader components. Each client machine on which reading Legic data should be performed must have at least one Remote Card Reader Component. This will usually be the client system(s) used for personalisation and/or printing of tokens.

To communicate with Certificate Authorities supporting the CMP protocol, the Remote CMP Component is used to handling certificate requests and responses, and also revocation requests and responses. Certificate Authorities supporting CMP include the RSA (Keon) CA and the EJB (opensource) CA.

The Remote CVCA Component was created to communicate with a CryptoVision CA, to handle certificate requests and responses, and revocation requests and responses. More about the CA can be found at www.cryptovision.com.

If a BlueX workflow requires the use of a MS Enterprise Certificate Authority, the Remote MSCA Component is needed to handle the communication between BlueX and this Certificate Authority. Communication in this case mostly means handling certificate requests and responses, and revocation requests and responses.

The BlueX Remote Signing Component is used to handle the digital signing of certificate request data by BlueX operators. It will receive the request data that must be signed, and will show this data in a dedicated signing dialog to the operator, allowing the operator to verify the integrity of the request data before signing. Once signed, BlueX can verify the request data and the digital signature at any moment, to prove the request data is still exactly the same as when signed by the operator.

The BlueX Remote Key Manager Component is used for two different purposes, both related to protected storage and protected transport of sensitive key material. It is used in the process to prepare tokens for use of “SafeSign IC Secure Offline PIN Unlock”, and it is used for handling key material in environments where Key-Backup and/or Key-Recovery are used.

In cases where the workflow requires an external third-party application to be called, the BlueX Remote Execution component can be used to call this application anywhere in the BlueX environment. This may be the case for example if data from the BlueX environment are going to be published to a third-party application, or if such an application should perform some part of the card personalisation process, and in many other scenarios.

The Remote Execution Component calls an executable, and provides the parameters and/or data required. These parameters and/or data can be forwarded from the BlueX server as part of a workflow action.