ANDiS CAMS Product Description 1 - 5 V 2.1

ANDiS CAMS
Product Description
ANDiS Card and Application

Management System (CAMS)
Copyright © 2002-2009 - Bell Identification B.V. Product Version 1.5

Document Version: 2.1
Document Released:
[March 2009]
All rights reserved. No part of the content of this document may be reproduced or transmitted in
any form by any means without the written permission of the publisher.
ANDiS™ is a registered trademark of Bell Identification B.V.
Table of Contents
TABLE OF CONTENTS
I. INTRODUCTION .............................................................................................................1
1. EXECUTIVE SUMMARY ..................................................................................................2
2. DOCUMENT INFORMATION.............................................................................................3
2.1. DOCUMENT STRUCTURE .....................................................................................3
2.2. LIST OF FIGURES................................................................................................3
II. CONCEPTUAL VIEW ON THE CAMS...............................................................................1
3. THE CONCEPT OF CAMS ..............................................................................................2

3.1. ANATOMY OF A CAMS .......................................................................................2
3.2. CAMS AS A BUSINESS ENABLER .......................................................................4
3.3. ANDIS CAMS: THE HEART OF A SMART CARD INFRASTRUCTURE ......................5
4. OTHER ANDIS PRODUCTS ...........................................................................................7
4.1. AUTHORISATION CONTROL SYSTEM (ACS).........................................................7
4.2. KEY MANAGEMENT SYSTEM (KMS)....................................................................7
5. INTERNATIONAL STANDARDS ........................................................................................9
5.1. INTRODUCTION ...................................................................................................9
5.2. GLOBALPLATFORM ............................................................................................9
5.3. MULTOS ..........................................................................................................9
5.4. EUROPAY INTERNATIONAL, MASTERCARD VISA (EMV).....................................10
5.5. FEDERAL INFORMATION PROCESSING STANDARDS (FIPS)................................10
5.6. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO) .........................11
III. FUNCTIONAL VIEW ON THE CAMS ..............................................................................12
6. KEY ELEMENTS OF THE CAMS ...................................................................................13

6.1. INTRODUCTION .................................................................................................13
6.2. LIFECYCLES .....................................................................................................13
6.3. MANAGING CARD CONFIGURATION ...................................................................14
6.4. ANDIS WIZARDS .............................................................................................15
7. CAMS BUSINESS PROCESSES ...................................................................................17
7.1. INTRODUCTION .................................................................................................17
7.2. CARD REQUEST ...............................................................................................17
7.3. PHOTO, SIGNATURE AND BIOMETRICS ENROLMENT...........................................17
7.4. CARD REGISTRATION .......................................................................................18
7.5. CARD DISTRIBUTION ........................................................................................18
7.6. CARD AND APPLICATION ADMINISTRATION .......................................................18
7.7. CARD RENEWAL ..............................................................................................18
7.8. CARD STOCK MANAGEMENT ............................................................................18
7.9. PRODUCTION ORDER ADMINISTRATION.............................................................19
7.10. CARD WITHDRAWAL ........................................................................................19
7.11. REPORTING......................................................................................................19
7.12. ADDITIONAL MODULES AND COMPONENTS ........................................................19
Copyright © 2002-2009 Bell Identification B.V. I

Table of Contents
8. CAMS INTERFACES ...................................................................................................21

8.1. INTRODUCTION .................................................................................................21
8.2. SMART CARD PERSONALISATION .....................................................................21
8.3. DATA EXCHANGE .............................................................................................23
9. ADDITIONAL FUNCTIONALITY ......................................................................................26
9.1. DATA PREPARATION ........................................................................................26
9.1.1 EMV............................................................................................................26
9.1.2 FIPS 201/PIV..............................................................................................26
9.2. SECURITY ........................................................................................................27
9.3. PERFORMANCE ................................................................................................28
9.4. SCALABILITY AND AVAILABILITY .......................................................................28
10. ARCHITECTURE......................................................................................................29
10.1. PRODUCT ARCHITECTURE ................................................................................29
10.2. DEPLOYMENT ARCHITECTURE ..........................................................................29
11. CONCLUSION AND CONTACTS ................................................................................32
- II - ANDiS Product Description 1.5 - ANDiS Card and Application Management System (CAMS)
Section I - “Introduction”
I. INTRODUCTION
Copyright © 2002-2009 Bell Identification B.V. -1-

Chapter 1 - “Executive Summary”
1. EXECUTIVE SUMMARY
The potential of multi-application smart cards enables banks, governments and
enterprises to exploit new business opportunities, to reduce fraud, restructure their cost
base, streamline administration or to meet legislative or card scheme mandates.
Intelligent application of mandates can also create revenue or cost saving opportunities,
creating a benefit from a necessity. With industry specific obligations such as EMV,
HSPD-12 and biometric border controls creating additional momentum, smart card
deployments on a significant scale are becoming increasingly common. However, issuers
and service providers planning to migrate to smart cards, or who plan to add new card
types and applications to their card base, must also accept the new challenges created by
this technology.
To begin with, the relationships between cards, data, cardholders and applications
demand more dynamic, flexible and efficient management. Effective management of
these relationships is proving to be a critical success factor in many new deployments.
This also means that the concept of “lifecycles”, traditionally applied to cards in a fairly
simple way, becomes more complex and should include all of the entities in the card
relationship.
These dynamic relationships also mean that the Card and Application Management
System (CAMS) needs to interface with a greater number of internal or external systems.
These could be citizen, employee or cardholder databases, distributed registration
systems, Certification Authorities, risk management systems, access control applications
and so on. Unlike relatively ‘static’ traditional card systems, some of these interfaces may
need to be real-time or interactive.
Another factor is the cost of card replacement; the expense of replacing issued smart
cards is high compared to relatively cheap but ‘static’ and fraud sensitive magnetic stripe
cards. Issuers and service providers therefore need to keep card ‘churn’ to a minimum. A
solution to this is ‘Post-issuance personalisation’, which can also enable new value added
opportunities for the issuer and cardholder population, but which adds another dynamic
aspect to the management of card and application.
It is little wonder that smart card and application management has emerged as such a
fundamental aspect of successful smart card deployments. Experience has proven that a
lack of an appropriate smart card management strategy can undermine the long term
business case and drive up costs, and in the worst case can risk the economic viability of
the smart card deployments.
A successfully implemented CAMS becomes an enabler, creating structure and
interoperability between diverse business processes and technologies and helping issuers
to realise the real potential of their card and cardholder assets.
-2- ANDiS Product Description 1.5 - ANDiS Card and Application Management System (CAMS)
Section I - “Introduction”
2. DOCUMENT INFORMATION
2.1. Document Structure

Main document sections:
Conceptual View
This section describes the high level requirements and attributes of Card and Application
Management Systems, and introduces the role and situation of Bell ID’s ANDiS software
in ‘generic’ smart card infrastructures. This section also introduces the main standards
organisations that help to shape the relevant functional, technical or industry specific
aspects of the smart card industry.
Functional View
This section explains how ANDiS resolves the potentially complex issues of lifecycle and
configuration management, describes how ANDiS maps the resulting requirements into
actual business processes and explains on a functional level how ANDiS interfaces with
other systems. This section also describes how Bell ID addresses typical functional
requirements such as security, availability and reporting.
2.2. List of Figures

Figure 1 Common interactions with CAMS ..........................................................................2
Figure 2 ANDiS CAMS in a typical environment ..................................................................5
Figure 3 Hierarchy in the ACS .............................................................................................7
Figure 4 Sample of National ID card lifecycle ....................................................................15
Copyright © 2002-2009 Bell Identification B.V. -3-

Section II - “Conceptual View on the CAMS”
II. CONCEPTUAL VIEW ON THE CAMS
Copyright © 2002-2009 Bell Identification B.V. - 1-

Chapter 3 - “The concept of CAMS”
3. THE CONCEPT OF CAMS
3.1. Anatomy of a CAMS

EMV payments cards, National ID cards, Corporate ID cards, Health cards and so on may
all have very different uses and applications, but the management of the cards and
applications do share a number of fundamental principles.
For example, lifecycles and processes associated with the cards, applications and
cardholders need to be set up, fulfilled and maintained. This means that a database needs
to be populated, cardholder registration must be performed, data will need to be prepared
and sent to personalisation systems, encryption keys and certificates will need to be
managed, and so on.
The requirement to manage lifecycles of not only the cards themselves, but also the on-
card application(s) and the cardholder(s) associated with them means that the CAMS
must also manage the relationship between each of these entities, throughout the various
events and changes of state in the lifecycle.
The CAMS will often need to receive or send data, commands or notifications relating to
these event or state changes when they occur, meaning that the CAMS will potentially
need to communicate with a diverse range of systems, not all of which are necessarily
under the control of the issuing organisation.
The following figure illustrates just some of the possible interactions:
Enrolment & Cardholder Data
Enrolment
Enrolment
Via LDAP Dbase
Via ANDiS
Other System
Key/Certificate Back Office/
Card & Status Cardholder Data,
Management Authorities Requests, Updates Batch Requests Application Providers
Call Centre
Certificate Status
Certificate
Authority Requests,
Request
Response Updates
Reports, Back
Status Office
Key Certificate Changes Systems
Management Request
Authority Response
Application
Data
Application
Provider(s)
Personalisation Application Add,
Requests/Response Delete, Update
Post
Personalisation Desktop
Issuance
Burea(x) Personalisation
Personalisation
Personalisation, Activation and Post Issuance
Figure 1 Common interactions with CAMS
- 2- Bell ID Product Description 1.5 - ANDiS Card and Application Management System (CAMS)
Managing these relationships, interfaces and processes efficiently and cost effectively
means that a meaningful CAMS should have a number of basic attributes, including:
Process Driven
The lifecycles of the card, cardholder and application(s) define the events and subsequent
changes in state that need to be executed. Some may be initiated manually, some may be
interactive, and others may be scheduled or automated processes, but it is essential to
ensure that these processes are managed securely, efficiently and reliably. As there will
always be new client specific business processes, the system should be adaptable
enough to easily allow changes in the workflow or processes without impacting the rest of
the system.
Flexible Interfacing
Clearly the CAMS may need to communicate with a number of systems, and these
systems are likely to have different technologies and behaviours. For example, importing
an embossing file is typically a batch oriented task sourced from a legacy system,
whereas card requests from a distributed branch environment would typically require an
on-line web service or web enabled interface, and Post-issuance application updates take
place via interactive web sessions. This clearly requires the CAMS to support flexible,
cross-technology interfaces to accommodate the various ‘push’, ‘pull’ and interactive
needs.
Legacy-aware, Open and Platform Independent

A CAMS will often be required to support a combination of ‘legacy’ or proprietary
technologies, and more current open standards technologies. To maintain flexibility and
prevent vendor ‘lock-in’, the CAMS itself should ideally be based on open technologies
such as J2EE, cross-industry standards such as GlobalPlatform 1 and should support
appropriate industry specific standards such as EMV, Multos or FIPS 201 where
applicable.
Adaptable
Business and technology demands can change quickly, and the CAMS should be flexible
enough to adapt to new requirements, whether these are simply additional fields in
cardholder records, or whether it is to support new card types, applications, enrolment and
issuing models et cetera. The option to download or update applications onto the existing
card population also provides added business agility, which can lead to cost savings by
avoiding the need to reissue cards, or potentially provide profitable business opportunities.
Secure
In many cases smart cards are introduced to reduce the risks of fraud, so it follows that
the CAMS must itself be secure and resistant to fraud. This applies to database
information, access to potentially sensitive functions such as card issuing, and to
communications with ‘The outside world’. Comprehensive and secure audit logging is
strongly recommended and is frequently a strong prerequisite in banking and government
applications, as is ‘four eyes principle’ access to sensitive or system management
functions.
1
See Section 5.2

Scalable
Both Issuers and Service providers may need to consider the mid term or long term
growth of their card populations, and in such cases it is necessary for the CAMS to have
the ability to grow with the requirements.
This applies to issues such as capacity, performance and reliability, as well as a possible
future change of system platform. For many issuers, it is wise to consider the possible
consequences of growth in the future.
Clearly, as the application of smart card technology matures, and as card infrastructures
begin to integrate multiple applications, processes, card types and so on, the idea of a
CAMS simply being a ‘black box’ in the personalisation chain is rapidly becoming
obsolete.
This remainder of this paper introduces ANDiS, a flexible, open Card and Application
Management System built on the ‘4 M’ principle: This simply means that a single ANDiS
platform is capable of managing multiple card types, running multiple applications in a
multiple card issuer environment interfacing with multiple card personalisation systems
and bureaux.
3.2. CAMS as a Business Enabler

Bell ID’s CAMS delivers genuinely market leading functionality on a single, open and
interoperable, software platform. Offering highly flexible configuration options, the ANDiS
CAMS is adaptable to many different business concepts and organisational needs,
making it a powerful business enabling tool for issuers and service providers.
ANDiS offers a number of potential business benefits including:
 Reduced time-to-market for new applications – creates business agility,

improves competitive positioning, reduces costs associated with future card and
application deployments
 Post Issuance Personalisation of existing card population – flexible

management of card portfolios reduces card re-issue costs, allows phased
business strategies, creates marketing opportunities, can contribute to higher
level of customer retention, adds value for cardholders
 Optimised management of card base and cardholder relations – efficient

administration, leverages CRM, improves dissemination of security sensitive
information (e.g. card revocation Card issuer retains control of the chip at all
times - reduces liabilities and risks inherent in sharing sensitive data with third
parties, converges management and administration tasks
 Flexible reporting functionality – provides real-time views for portfolio

management and risk analysis, improves incident responses, creates links to
billing systems
 Return on investment – ANDiS reduces re-investment for new cards or

applications, creates options to ‘rent’ application space to third parties on issued
card chips, helps create value added or revenue generating applications.
3.3. ANDiS CAMS: The heart of a Smart Card Infrastructure

The CAMS manages essential card personalisation and lifecycle aspects such as data
preparation, enrolment, encryption key management, and card status management.
Where more sophisticated cards and applications are being issued, or will be in the future,
CAMS is also capable of delivering dynamic application and parameter management and
post issuance personalisation for a varied card and user population. Furthermore the
CAMS offers legacy and web based interfaces between related internal and external
systems.
The following figure shows how the CAMS is positioned in a “typical” generic environment;
more specific implementations are discussed in the appropriate ANDiS CAMS solution
documents for EMV, Corporate ID, and National ID and Health applications.
Enrolment & Cardholder Data
Enrolment
Enrolment
Via LDAP Dbase
Via ANDiS
Other System
Key/Certificate Back Office/
Management Authorities Application Providers
Call Centre
Certificate CWS Dataport CNS
Authority
Data Card Provider

Prep M’gmt Interface Back
Office
Key PKI/ Application Audit/ Systems
Management KMA M’gmt Reporting
Authority
KWS KMS PIP Application

Provider(s)
Perso Web Perso
PWS
Interface Interface
Post
Personalisation Desktop
Issuance
Burea(x) Personalisation
Personalisation
Personalisation, Activation and Post Issuance
Figure 2 ANDiS CAMS in a typical environment
The CAMS is primarily responsible for:

 Card Request Processes
 Card, Cardholder & Application Administration
 Card Configuration Management
 Reporting

Additional components or options manage functional or interface requirements such as:
 Scheduled Data Preparation (mainly in banking/EMV)

 Web based enrolment, administration, photo studio and various other modules
 Import/export of data from and to external systems
 In Branch issuance / Central in-house personalisation
 CAMS User Access and Authorisation Management (ACS)
 Interfacing to registration systems , personalisation bureau or other systems
 Interfacing to application providers
 Interfacing to PKI(s) or KMA
 Key Management Services (KMS)
 Post Issuance Personalisation (PIP)
 A Notification Service (CNS) for publishing change of state notices
Before exploring these components and interfaces in more detail, it is useful to look at
some important card management concepts and how they are applied in ANDiS.
4. OTHER ANDIS PRODUCTS
4.1. Authorisation Control System (ACS)

Access to functionality of ANDiS Management Systems is controlled by means of the
ANDiS Authorisation Control System (ACS), which enables the CAMS administrators to
define rights of access to modules, screens and buttons for each group of ANDiS
operators. When logging onto the central system, through a web browser, operators can
be identified by a combination of username / password, by IP address and / or by an on-
card X.509 certificate. Optionally, identification by means of biometrics is supported.
Additional hardware at workstations is required when biometrics or certificates are utilised.
The ACS database contains all the user, user group and access control data, which can
only be altered according to a predefined hierarchy, enables ANDiS administrator to
define and manage rights of access to all of the ANDiS functionality. The diagram below
shows how this hierarchy works.
Users Groups Roles & Actions
Preparation
Johnson
Card Request
Requesters
Smith Photo/Signature
Card Request Check
Authorisation
McNeal Authorisers Card request check
Authorisation
Administration
Stanford Administrators
Card Administration
Cardholder Administration
Figure 3 Hierarchy in the ACS
4.2. Key Management System (KMS)

The ANDiS Key Management System (KMS) is an extremely powerful tool which is
concerned with the potentially complex process of generation, storage, distribution or
import and lifecycle management of cryptographic keys. The keys may be used for
encryption and decryption of data, or for verification and authorisation of other parties,
such as personalisation bureaus, using digital certificates.
The KMS facilitates import of keys generated by third parties and distribution of keys to
third parties. During the life cycle of keys, the KMS registers all changes in status. In most
cases, for generation of cryptographic keys a so-called Hardware Security Module (HSM)
is required. ANDiS provides interfaces to all major HSM providers (see Error! Reference
source not found. Hardware Security Modules). The KMS can also be implemented
separately, to manage keys and key hierarchies for card or non- card related applications.

Chapter 4 - “Other ANDiS Products”
The KMS functionality is exposed to other ANDiS components or third party applications
(where permitted) using the KMS Web Service interface. Comprehensive information is
available in the KMS/KWS Product White Paper.
5. INTERNATIONAL STANDARDS
5.1. Introduction
ANDiS supports a wide range of generic IT interoperability standards, many of which are
outlined in the Technical View section of this document.
However, there are certain organisations that have a particular influence on vertical
market segments or which guide business and technology strategies on a broader basis
than generic IT standards. The following industry bodies are particularly significant for Bell
ID and for sections of our customer base:
5.2. GlobalPlatform
GlobalPlatform is the leading, international smart card association, responsible for
creating and advancing interoperable technical specifications for smart cards, acceptance
devices and systems infrastructure. It is driven by a cross-industry member base
comprising over 50 organisations.
Since the formation in 1999, the GlobalPlatform Specifications have become recognised
by the world-wide smart card industry as the standard upon which to base smart card
infrastructures, thanks to a finely tuned balance of technical superiority and business
justification.
The specifications offer backwards compatibility and allow adopters the opportunity to
grow revenues by capitalising on either the single or multiple-application smart card
model. By providing these specifications on a royalty-free basis (available for free
download at www.globalplatform.org), GlobalPlatform actively promotes worldwide
acceptance of its standards and encourages a universal approach to the development of
smart card infrastructures. This facilitates deployment, decreases time to market and
accelerates the adoption rate of smart card technology in diverse industries around the
globe.
GlobalPlatform technology is being used across Europe, North America, Asia and
Australia by many bodies, including government departments, issuers, payment card
organisations and telecommunication companies, to implement a range of smart card
programmes. Current programmes range from city/ID/health card projects to enhanced
credit/debit cardholder loyalty schemes which also offer post-issuance download
capabilities.
With over 75 million GlobalPlatform smart cards currently in circulation across the globe,
the stability of the technology has been proven and the standard has now been set.
Operating on a not-for-profit basis, GlobalPlatform funds its on-going technical work and
the marketing efforts of the organisation with funds raised from membership fees.
GlobalPlatform is a fully independent and democratic organisation with its strategic
priorities defined by an elected Board of Directors. Bell ID is an active contributor to the
GlobalPlatform systems specifications in terms of Key Management, Post Issuance
Personalisation, Systems Compliance, Interfacing and Messaging.
5.3. MULTOS
MULTOS is the first, open, high security, multi-application operating system for smart
cards (hence 'MULT-OS').
Prior to the emergence of multi-application smart cards, each software application

representing a product or service on a card was written for a specific operating system,
which in turn was particular to a hardware (chip) or silicon platform supplier.

Chapter 5 - “International Standards”
This forced card issuers to commit to a specific application developer, operating system
and chip for each service the issuer wished to provide to its customer base. The issuer
had almost no flexibility to change any of these components without having to invest funds
into a new software and/or hardware implementation. Early smart cards therefore created
high cost of ownership and yet offered virtually no flexibility. Cardholders were forced to
carry a different card for each service or function they wished to benefit from, and if the
product or service changed in any way, they would receive a replacement card.
The MULTOS high security, multi-application operating system has changed the smart
card proposition for both issuers and cardholders. MULTOS provides increased
convenience and flexibility for users while delivering savings and a wealth of opportunities
for issuers across all business sectors.
Bell ID has a valuable and flourishing working relation with Multos and our systems
support MULTOS based operating systems and card schemes.
5.4. Europay International, MasterCard Visa (EMV)

EMVCo, LLC, was formed in February 1999 by Europay International, MasterCard
International and Visa International to manage, maintain and enhance the EMV Integrated
Circuit Card Specifications for Payment Systems as technology advances and the
implementation of chip card programmes become more prevalent. The formation of
EMVCo ensures that single terminal and card approval processes are developed at a
level that will allow cross payment system interoperability through compliance with the
EMV specifications.
With the acquisition of Europay by MasterCard in 2002 and JCB International joining the
organisation in 2005, EMVCo is currently operated by JCB International, MasterCard
International, and Visa International.
The latest version of the specifications, EMV 2000 version 4.1, was published in June
2004.
The EMV specifications have been integrated into the ANDiS system to serve the financial
industry with a proven solution. Bell ID works closely with Visa and MasterCard to ensure
the latest specification update throughout all ANDiS products and modules.
5.5. Federal Information Processing Standards (FIPS)

FIPS - US Federal Information Processing Standards – cover a wide range of IT
technologies and in theory only apply to US government agencies (and their suppliers,
contractors etc).
As the secure smart card/token and HSM markets have proven, sometimes the wider
market uses FIPS in the absence of any other appropriate standards. For example banks
and many enterprises in all regions now routinely specify that HSMs must be validated to
the relevant FIPS standard (FIPS 140-2).
FIPS has also introduced a standard which is likely to impact Identity Management and
Identity Verifications systems. In August 2004, President George Bush issued his 12th
Homeland Security Presidential Directive (HSPD-12) with the intention to:
 Enhance security
 Increase government efficiency
 Reduce identity fraud
 Protect personal privacy
- 10 - Bell ID Product Description 1.5 - ANDiS Card and Application Management System (CAMS)
HSPD-12 demands that agencies must issue “secure and reliable forms of identification,”
which means that identification:
 Must be issued based on sound criteria for verifying an individual employee’s

identity
 is strongly resistant to identity fraud, tampering, counterfeiting, and terrorist
exploitation
 can be rapidly authenticated electronically
 is issued only by providers whose reliability has been established by an official
accreditation process
FIPS 201 was issued in February 2005 to specify the standards for this directive. FIPS
201 is called Personal Identity Verification of Federal Employees and Contractors, so the
term PIV is frequently used.
ANDiS has been successfully tested for compliance with the appropriate elements of PIV,
and with the expectation that more government and corporate ID card projects will
assume FIPS 201 as ‘de facto’ standards, this is likely to become increasingly important.
5.6. International Organization for Standardization (ISO)

ISO standards for identification cards are developed by the joint technical subcommittee
for cards and personal identification, ISO/IEC JTC1/SC 17. There are various types of
identification cards for the numerous application areas, e.g. ISO/IEC 7816 for Integrated
circuit cards with contacts and ISO/IEC 14443 for Integrated circuit cards without contact.
Standards for application areas

ISO 7813 sets out requirements to be met by financial transaction cards. Whereas,
ISO/IEC 7501 covers machine readable travel documents, such as passports and visas.
Copyright © 2002-2009 Bell Identification B.V. - 11 -

Chapter 5 - “International Standards”
III. FUNCTIONAL VIEW ON THE CAMS
Section III - “Functional View on the CAMS”
6. KEY ELEMENTS OF THE CAMS
6.1. Introduction
Two essential aspects of successful smart card deployment and operations are:
 Management of all of the card and application related processes from a card request
through to the withdrawal or expiry of a card
 Definition and Management of the potentially varied relationships between each of

the card related entities
These issues are clearly fundamental where large or complex smart card deployments are
involved, but should not be underestimated even where apparently straightforward smart
card deployments are concerned. Issuers who neglect or underestimate these essential
aspects of smart card management can find themselves unexpectedly ‘locked in’ to
increasingly unsuitable processes or technologies, and unable to react effectively to future
demands.
ANDiS addresses these two fundamental aspects of smart card deployments providing
comprehensive and powerful tools to manage and maintain lifecycles and card
configurations. Both of these issues are briefly discussed below.
6.2. Lifecycles
The personalisation processes of smart cards tend to be more complex than, for example,
for magnetic stripe cards, and there may also be one or more (potentially dynamic)
applications Card Lifecycle example Application (eg Certificate) Lifecycle example
associated with the New New
card. This means that
Ready for Input
lifecycle management
becomes far more Ready for Authorization
important with smart Ready for Production

cards than with static
In Production Ready for Initialization
magnetic stripe cards.
Ready for Activation Initialized Post Issuance
A lifecycle consists of In Use In Use Ready for Update
‘events’ and ‘states’,
so that an event (such Removed
as ‘card request Blocked
authorised’) leads to a Physically Withdrawn Installed
change of card state

(such as to ‘ready for Logically Withdrawn Terminated
production’). In Synchronized Card and Application Lifecycles

addition, not only the
card, but also the applications and cardholders need to have lifecycle defined, managed
and synchronised.
A simple example of a card and application lifecycle might look like the boxed example
above.
Managing these lifecycles is a particular strength of ANDiS, and the Lifecycle Wizard (see
Wizard Concept below) provides a graphical, ‘drag and drop’ flow chart tool to make the
task as clear and simple as it can be.

Chapter 6 - “Key Elements of the CAMS”
6.3. Managing Card Configuration

ANDiS can support many different sorts of cards, for many different types of issuers,
users and applications. In many cases, multiples types of each might co-exist, for example
issuers may have different employee and visitor ID cards, different categories of health
and health insurance cards, or multiple sorts of bank payment card.
As has been described, ANDiS is capable of supporting many combinations on a single

management platform, but even simple groupings of users or card types need to be
clearly established and managed. ANDiS separates different entities and groups as
follows:
 Issuers: An entity that is responsible for issuing cards. With single-application

cards, the card issuer is usually also the application provider, but this is not always
the case.
 Target Groups: A collection of cardholders, for whom certain card types are
available. For each cardholder, ANDiS can specify to which target group(s) a user
belongs via a membership. As a result, only the card types linked to that target
group will be available for that particular cardholder.
 Membership: Where cardholders could be members of multiple target groups,

‘membership’ indicates which of the target groups a cardholder should belong to.
 Card Type: The card type indicates the type of card, to which card family it belongs,
how the card number is assembledthe type of chip embedded in the card, etc.
 Card Programme: A card programme defines the set of applications which can be
assigned to a card. The card programme can also define which applications are
mandatory and which, if any, are optional.
 Application: In ANDiS
Issuer terminology, an application as
Cardholder
it applies to a smartcard is a
collection of data, commands
and procedures, which can be
loaded onto a smartcard.
Target group Certain applications (for
example Access Control) may
only consist of an identification
number, which will be used by
Card type a (centralised) system to
identify the cardholder. Other
applications may contain
actual programme code (a
Card
Java applet on a Java enabled
Program
card for example).
Application
 Card Family: A card family is
a group of one or more card
types with similar physical
(For example…) Identity Time/ attributes, and can be used to
Attendance identity card with different
personalisation processes.
ANDiS allows highly flexible configuration of all of these elements, which means that card
issuers can use ANDiS map potentially complex hierarchies, groups, chip technologies,
card products and so on in highly relational way.
Figure 4 (above) shows an example of a straightforward set of relationships that might

exist when an issuer has only two user groups, two card types, and two applications of
which one should be available on both card types.
Figure 5 below shows how ANDiS can also be scaled up to manage more complex and
numerous groupings, with support for memberships and organisations to create further
flexibility.
Figure 4 Simple Configuration
Issuer
Cardholder
Membership
Target group
Cardholder
Photo/
Signature/
Biometric
Card type
Organisation
Card Selection
program
Application
(For example…) Identity Time/ Payment Physical Fuel Logical

Attendance Access Control Access Control
Figure 5 Manage Complex Configurations & Relationships
6.4. ANDiS Wizards

Clearly, issuers and service providers planning to implement a smart card infrastructure
are faced with a wide range of possible parameters, variables and configuration choices.
ANDiS is itself a flexible and feature rich system so, to help organisations, administrators
and system operators to navigate their way through the various options, administrators
and operators are provided with a set of ‘Wizards’.

Chapter 6 - “Key Elements of the CAMS”
ANDiS wizards are a set of Graphical User Interfaces with a common look and feel which
have been created to help users set up or operate many of the configuration and operator
tasks.
For example, wizards are available to help establish lifecycles and card configurations, for
administrative functions such as managing cardholders and card requests, for application
management and so on. For both security and ease of use, access to any of this
functionality is controlled by the ANDiS Authorisation Control System, discussed later in
this chapter.
7. CAMS BUSINESS PROCESSES
7.1. Introduction
The ANDiS Card and Application Management System (CAMS) manages the complete
lifecycle of unlimited numbers of multi-application smart cards. The key mission of the
CAMS is to:
 Manage the cardholder data and the status of the card, and the related processes.
 Manage and activate applications, where appropriate from external service
providers. Applications could be EMV debit/credit, e-purse, cardholder identity and
authentication, physical and logical access control, health (insurance) data, and
many others.
The following describes a “default” ID card business process, but clearly the flexible
lifecycle support and extensive interface options offered by ANDiS mean that issuers and
implementers can tailor such processes as appropriate to the circumstances.
7.2. Card Request

There are several ways to enrol a cardholder and register the card in the ANDiS CAMS.
The most common are:
 Via an ANDiS CAMS Web Service (CWS) based on SOAP protocol, for example
where another enrolment infrastructure or ID Management System (IDMS) will be
used. The CWS is described in section 8.3.1.
 Via import of Cardholder data through the ANDiS Import/Export Module, again
described in section 8.3.5.
 Via data input through a web based GUI by an ANDiS operator. This is described
below.
The first step in the lifecycle of a card is the registration of a card in the ANDiS CAMS.
This process is called Card Request and enables the ANDiS Operator to select the proper
card type and the appropriate applications, as defined in the card configuration.
The web based nature of the operator GUI and the ability of the ACS to allow only the
functions that a given operator needs (e.g. card registration for front office operators,
authorisation and card withdrawal for management operators) means that the operator
processes can be both distributed and tailored to the issuer’s preferred workflow.
In some cases, such as for ID cards, a photograph should be printed on the card and
other biometric data such as fingerprints will be stored on the chip.
7.3. Photo, Signature and Biometrics enrolment

ANDiS supports on-card digital images such as photographs or handwritten signatures,
and has a Photo Studio module for capturing and managing photographic images. ANDiS
can integrate with other biometric devices such as fingerprint or retina scanners through
the industry standard BioAPI 2 .
2
The BioAPI Consortium is a group of over 120 companies and organizations that have a common interest in promoting the
growth of the biometrics market. For more information the reader is referred to http://www.bioapi.org/.

Chapter 7 - “CAMS Business Processes”
Note that ANDiS allows issuers and service providers to configure different
enrolment options, so for example when a company is issuing Corporate ID Cards,
payroll staff can be automatically entered into the system via an interface with the
HRM system, but visitors and hired staff might be entered via the operator GUI.
7.4. Card Registration

When cards are personalised by an external Personalisation Bureau, the Card
Registration process may be used to match the result file received from the
Personalisation Bureau, containing information about the produced cards, and the
physical cards themselves. This will guarantee that all requested cards have also been
received physically.
7.5. Card Distribution

Card Distribution involves physical and logical distribution of the card and updating the
states of both the card and the applications linked to that card.
7.6. Card and Application Administration

The ANDiS CAMS manages smart cards and applications throughout their entire lifecycle.
All state transitions are recorded in the database for audit trail purposes.
The lifecycles of each card type can also be configured to match the business needs of an
organisation. For example, certain card types such as short term visitor ID cards might be
issued immediately after they have been printed and should be logically withdrawn after a
short time period, whereas formal employee identity cards must be authorised and
checked before personalisation can take place. By making a selection of pre-defined
events (card request, distribution, personalisation, authorisation, etc.) a card issuer can
compose a lifecycle for a certain card type.
Features:
 Provides GUI for Cardholder Support Services
 Administration of the card, card holder and the applications on the card
 Changing the status of the card (including logical card collection)
7.7. Card Renewal

In some cases, it should be possible to renew cards, offering a potential saving on
physically reissuing expired or suspended cards, and card renewal is supported as an
option by ANDiS. Renewal requires the states of both the card and the applications linked
to that card to be updated. As with any other state changes, application providers with an
interest in a card renewal can be updated through online interfaces, e-mail messages or
offline synchronisation (e.g. XML based export files).
7.8. Card Stock Management

The ANDiS CAMS offers three types of stock administration:
Card Type Independent Stock Administration

This type of stock administration can be used to keep track of “white plastic” stock.
Card Type Dependent Stock Administration

This type is used to keep track of pre-personalised or pre-printed cards. In this case it is
necessary to keep stock for each individual card type, since the basic material is already
linked to a certain card type.
Production Stock Administration

In addition to keeping track of the pre-personalised cards, the chips on these cards are
also administered on an individual basis. The unique serial number of each pre-
personalised card is stored in the ANDiS database. During production, the chip serial
number is read and compared to the database. Only registered chips may be produced,
increasing the security of the production process. Furthermore, if the serial number exists
in the database, but is linked to a different card type, production of this card will be
refused.
7.9. Production Order Administration

Although batch production orders can be launched by the ANDiS job scheduler, there are
environments in which a greater level of manual control should be exercised. ANDiS
provides a comprehensive GUI which gives operators a clear overview of the cards which
are ready for production, and allows them to dictate which cards (of not all) should be sent
in the next production order. Note that the same operator interface provides an overview
of any cards which may have failed the production process, so that they can be resent or
investigated as appropriate.
7.10. Card Withdrawal

Withdrawal is the last stage in the lifecycle of a card. Ideally cards should be physically
destroyed (physical withdrawal) but if this is not possible (e.g. in the case of lost or stolen
cards) the status can be set of ‘logically withdrawn’. The card’s state is changed and all
applications residing on the card are immediately blocked, while the ANDiS CNS
component can notify the involved application providers.
7.11. Reporting
Reporting for Administrative or Billing Purposes

ANDiS uses Jasper Reports to present reports. Reports are selected via the ANDiS User
Interface and the report is showed to the user as a PDF. Jasper Reports also supports
HTML and CSV file formats in addition to PDF, to provide outputs that are most suitable
for the reporting requirement (hard copy, web or file based).
7.12. Additional modules and components
Job Scheduler
ANDiS processes are frequently triggered by external events such as card requests, PIP
requests et cetera. However there are occasions when processes or ‘jobs’ need to be
executed automatically and unattended, but where there is no external ‘trigger’.
This might be to suspend ACS users who have not accessed the system for a certain
period, or to execute regular import or export tasks, which is a typical requirement for
batch oriented data preparation. The ANDiS Job Scheduler offers the possibility to run

Chapter 7 - “CAMS Business Processes”
certain jobs both automatically and unattended on a regular basis (e.g. daily for overnight
runs). Jobs can also be manually started without affecting scheduled jobs.
Email Notifier
It is also possible to configure the job scheduler to initiate a (configurable) e-mail. In
conjunction with the job scheduler, the E-mail Notifier could for example be used to send
confirmations, or e-mail advisories appropriate to the administrative requirements of the
organisation.
8. CAMS INTERFACES
8.1. Introduction
ANDiS CAMS provides functionality to personalise cards and on-card chips in various
ways. Cards can be personalised within the card issuing organisation either on distributed
(“in branch”) or on centralised personalisation equipment. Alternatively, the issuer can
also opt for personalisation services to be provided by a third party, or bureau, who will
then receive electronic personalisation files via secured connections.
ANDiS also offers the capability to mix these options, so that some card types or user
groups can receive cards immediately ‘in branch’, others via a bureau which is capable of
managing larger volumes, takes care of distribution logistics and can provide economies
of scale. This flexibility can put issuers at a considerable business advantage, or reduce
delays in ‘emergency’ or V.I.P. situations where some cards might be required
immediately.
8.2. Smart Card Personalisation
Personalisation Bureau Interface

Where personalisation is carried out by a personalisation bureau, ANDiS CAMS
communicates by means of an XML-file based interface and (where appropriate) EMVCo
personalisation specifications. This interface consists of a “Request File” and a “Response
File”; the Request File contains information about the cards to be personalised; the
Response File contains information about the results of the personalisation process.
The Personalisation Request File contains records of the cards to be personalised

including available fields for batch number, card number, card type, cardholder data,
application data and 'collection station' address. The Personalisation Response file
contains records of the cards correctly personalised, a field with the number of cards
unable to be produced, and a field with the number of cards that were rejected in the
quality check.
The GlobalPlatform personalisation specifications are supported by personalisation

bureaus around the globe.
Web Based Issuance

The ANDiS Web Based Issuance Solution allows issuers to execute local (“in-branch”)
issuance and personalisation. It provides organizations with the opportunity to print and
personalize cards locally, such as within the bank branch, in corporate Human Resources
offices, in government or local governments’ distributed office locations, and so on.
In large scale, national or banking implementations, in-branch personalisation is not

generally a replacement for mass personalisation (centralised personalisation at a bureau,
for example). It is however intended as a means to provide the cardholder with quicker
service for card replacements, VIP or urgent cases and so on. The same technology can
also be used for smaller implementations to take advantage of centralized desktop
printing and personalisation facilities.
Post-Issuance Personalisation (PIP)

The ANDiS Post-Issuance Personalisation (PIP) module facilitates adding, deleting or
changing applications on cards that have already been issued. Typical PIP processes are

Chapter 8 - “CAMS Interfaces”
performed remotely when cardholders present their cards at local card readers or kiosks,
without a need to use the initial, central issuing and personalisation station. Secure
connections between the central CAMS web server and the local card readers or web
browsers are established with HTTPS and SSL.
Cardholders connect to the central web server and request for the additional application to
be downloaded onto their card. The same goes for deleting or changing on-card
applications. Obviously, all changes are registered and managed centrally in ANDiS
CAMS. Updating the cards can be performed either at the central issuing station, at a
kiosk, or at a home PC equipped with web browser and card reader. Definition of the PIP
workflow largely depends on the defined business processes.
PIP enables a card issuer to establish considerable cost savings by eliminating the need
to replace large numbers of cards when new applications are added to the smart card
scheme.
A highly beneficial new feature of PIP is the availability of a Web Service based on the
SOAP protocol to provide greater ease of integration and flexibility for customer specific
requirements.
8.3. Data Exchange
Section 6.3 provides examples of the type of relationships and data exchanges that
ANDiS might be expected to support.
However, the best method of interfacing and exchanging data between ANDiS and other
systems depends on a variety of factors, including the type and volume of data that needs
to be transferred, the type of system with which ANDiS is communicating, requirements
for real time or near real time communication, whether communication needs to be
unidirectional or bi-directional and so on.
ANDiS provides comprehensive interfacing options to support existing and potential future
interface requirements for various systems, applications and databases.
This approach also enables ANDiS to effectively integrate with and conform to the diverse
demands of each customer’s own IT strategies, architectures and processes, which is an
increasingly important aspect of IT planning.
ANDiS is able to interface to external systems through:

 Web Services
 Web Enabling
 Batch File Exchange (DataPort)
 Directory Services (LDAP)
 Messaging Middleware
This section provides a brief functional description of each method.
8.3.1 CAMS Web Service (CWS)

Depending on the appropriate solution architecture, ANDiS may need to integrate with
one or more systems such as HRM, Call Centres, IDMS or other systems and may require
an on-line interface in near real time. “Web Services”, defined by W3C 3 as a “system
designed to support interoperable machine-to-machine interaction over a network”, makes
integration between different systems and platforms easier, more flexible and is frequently
in line with contemporary IT architecture strategies.
3
Worldwide Web Consortium, www.w3.org

Chapter 8 - “CAMS Interfaces”
ANDiS CAMS Web Services (CWS) opens the services of ANDiS to other enterprise
systems – while still maintaining security and authorisation controls – using state of the art
web technologies.
ANDiS makes extensive use of these web services technologies for data exchange with
the CAMS itself, with the KMS, and with PIP.
8.3.2 LDAP
Users or cardholder information required by ANDiS is sometimes already present in
external X.500 Directory Services such as Microsoft Active Directory, Netscape Directory
or SunONE Identity Server. These are particularly common in the large Corporate ID
market segment. Such Directory Services are often considered to be the “leading”
authority for Identity and Authorisation information.
ANDiS integrates with a directory server using the LDAP protocol for communication,
reducing the need for entering duplicate user and cardholder data and facilitating the
reuse of existing systems and data.
8.3.3 CAMS Notification Service (CNS)

There are many occasions when it may be useful (or essential) for other systems to be
notified of changes to cards, applications et cetera. The ANDiS Notification Service is a
tool that can be used to inform external applications on life cycle state changes of entities
in the ANDiS CAMS. The entities for which a notification can be sent include cardholders,
cards, applications and organisations. This can be particularly useful when one part of an
organisation or an external agency needs to be kept informed of changes, such as if a
card is issued, if an application is blocked, et cetera.
8.3.4 Public Key Infrastructure (PKI)

Many smart card applications, especially in the Identity Management field, make use of
Public Key Infrastructure (PKI) as a means of authentication. ANDiS has the capability to
manage public key certificates in the same way as other on-card applications, thus
ensuring that certificates also benefit from fully integrated card, cardholder and certificate
lifecycle management.
ANDiS itself does not generate or issue certificates, but does have the ability to integrate
with a range of PKI systems, but each PKI vendor has a different approach to interfacing
with external systems. The following is a typical ‘generic’ process that ANDiS will need to
follow to generate certificates for cards:
 Generate key pair on-card or in an HSM (usually on-card generation will be for low
volume or post
issuance certificate requests, HSMs will be used for mass issuance)
 Make certificate request
 Create PKI Connector from request
 Ask PKI connector for certificate request hash
 Sign the hash on the card or in the HSM
 Give the signature to the PKI connector
 Get the certificate from the PKI connector
ANDiS is currently capable of providing support for Verisign On-Site, Microsoft Certificate
Service, RSA Keon, Entrust and Cybertrust CAs.
8.3.5 DataPort Module

• The DataPort Module is generally used where data is transferred in batch and/or
offline
scenarios. DataPort is capable of handling high volumes of data, such as an

import of existing cardholder database information. Transfer of batch data can take
place on a regularly scheduled basis, and/or on manual request as required.
ANDiS DataPort is designed to easy importing and exporting information
• A special DataPort Template is used is used to specify the fields in an import or
export file as well
as the mapping to the corresponding database fields
• The main focus of DataPort is fast performance for the import and export of large
amounts of
data
• Relatively straightforward imports and exports can be built without the need to do
any additional
programming
• It is flexible enough to alter the default behaviour by implementing custom classes.
8.3.6 Application Provider Interface

ANDiS CAMS caters for a true multi-application smart card scheme by means of a varied
and extensive range of interfaces with third party application providers. Most of the
interfaces comply with industrial standards (particularly GlobalPlatform), and several
proprietary applications are also supported. The interfaces enable secure data
communication (either online / real-time or in batch mode) between the CAMS and all of
the external application providers.

Chapter 9 - “Additional Functionality”
9. ADDITIONAL FUNCTIONALITY
9.1. Data Preparation
9.1.1 EMV
Issuers looking for either an integrated or stand-alone high performance data preparation
system will find that ANDiS caters for both requirements. The ANDiS data preparation
Module provides a variety of benefits such as:
 Fast data preparation

 Database population for future re-issuance
 HSM independence
 Single Issuance and post-Issuance platform
 User-friendly interface
 Integration with common EMV test tools
The data preparation component is an integral part of the ANDiS4EMV solution, which is
specifically tailored for EMV application schemes such as VSDC (Visa) and M/Chip
(MasterCard) and AEIPS (American Express). The relevant scheme data and cardholder
data can be input through either an embossing file, soap service or via the web based
interface.
The data preparation component is a scheduled process which is to run at intervals

specified within a configuration file. The output from this process is the enrichment of
embossing or cardholder data with EMV and security data which are used in generating
an output file which can be sent to a personalisation bureau or used as input into a
personalisation manager application.
ANDiS4EMV that also caters for:
 Management of EMV Templates

 EMV Variable settings
 EMV Cryptographic Key Management
 EMV Issuer Scripting Support
 VISA and MasterCard Support
 EMV and Loyalty Application
9.1.2 FIPS 201/PIV

Data Preparation for FIPS 201 also has very specific attributes, which are supported by
the ANDiS FIPS 201 solution.
A FIPS 201 PIV card is itself highly complex. Each card contains a PIV applet, divided into
up to ten containers, each of which will be populated by different data elements.
This also means that each of the containers are populated by different data elements, the
life-cycle of which must be managed separately. During data preparation, ANDiS prepares
the card holder information so that it can be loaded to the appropriate container during
personalisation.
The ANDiS Data Preparation process creates the necessary content, including required
Cardholder Unique Identifiers (CHUID) and Federal Agency Smart Credential Numbers
(FASC-N), the cardholder fingerprints, any optional printed data and cardholder facial data
and so on.
ANDiS also manages the container signing and update services required for Activation
and Post Issuance Personalisation, manages the state changes and fires appropriate
notification to IDMS (enrolment system).
More details on the ANDiS solution for FIPS 201/PIV is available on request.
9.2. Security
As Card and Application Management Systems often deal with privacy or fraud sensitive
data, security is an essential component of ANDiS design and implementation
methodology. ANDiS is capable of complying with industry or region specific mandates
and policies, and the following is a short overview of common functional security
requirements that ANDiS must support.
Access Control to the Card Management System

The access security of ANDiS is handled by the ANDiS Authorization Control System
(ACS). ACS is a powerful tool which provides fine grained access and authorization
control for both ANDiS users and applications interfacing to ANDiS, and is described in
greater detail in section 4.1.
ANDiS Database Security

The ANDiS system can be protected on several levels:
 In addition to the ACS, access to the CAMS database can be protected using Oracle
security mechanisms, e.g. Oracle role based authentication.
 All sensitive information in the database (sometimes referred to as ‘Data at Rest’)
can be stored in encrypted form, with encryption keys and processing handled in the
secure and tamper resistant environment of a Hardware Security Module (HSM).
 It is generally good practice to ensure that the ANDiS server platform and HSMs are
placed in a physically secure environment.
Secure Communication
ANDiS supports secure communication using HTTPS, SSLv3.
The contents of files exchanged with external systems can be encrypted with
DES/3DES/RSA using HSMs, SAMs or software keys. For data encryption an HSM
(Hardware Security Module) can be accessed via any ANDiS product. Encryption
functionality can be used from ANDiS Card, Application or Key management System. (e.g.
encrypted storage of cardholder data in the central CAMS database).
Message Authentication Codes (MACs) or digital signatures are widely used to ensure the
integrity of data transfer between ANDiS and 3rd party systems.
Auditing for Security Purposes

The ANDiS CAMS supports configurable logging using Log4j, a library that is integrated
directly with the application which requires logging. This might be whenever an operator
changes a smart card’s state, creates or authorises card requests, et cetera. Digital
signing of audit logs is fully supported. Signed records contain information on date/time of
the change, the operator who made the change, the contents of the old record, etc.
Signing trail records makes certain user changes irrefutable, which can be important for
companies who have high legal requirements.
ANDiS Key Management System

The ANDiS KMS integrates seamlessly with the ANDiS Card Management and
Application Management System. The ANDiS Key Management System (KMS) is

Chapter 9 - “Additional Functionality”
concerned with the implementation of security concepts based on the generation and the
secure storage, export and distribution of all sorts of cryptographic keys (DES, triple DES,
RSA/PKI, Mifare keys. Electronic keys can be used for encryption and decryption of data
and for verification and authorization of trusted parties (using digital certificates). The
ANDiS KMS supports the management of all Global Platform keys. Please refer to ANDiS
KMS Whitepaper for more information.
9.3. Performance
The performance of ANDiS depends on a variety of factors, such as the level of data
preparation required, the type, number and method of keys that may need to be
generated for each card, the hardware platform being used, and so on. The performance
requirements must therefore be addressed according to the requirements of a given
implementation.
In a real test of ANDiS’ performance capabilities, a major credit card issuer deploying
several millions of chip based credit cards has deployed ANDiS on a single hardware
platform, and has generated in excess of 50.000 cards per hour, or over 1.2 million cards
per day.
9.4. Scalability and Availability

ANDiS is a fully J2EE compliant product, and the software supports scaling to many
millions of cards. Ultimately the scalability and availability of ANDiS depends on an
intelligent and appropriate choice of system architecture and hardware. ANDiS has proven
itself capable of scaling up to meet the requirements of nationally deployed large scale
credit card issuers, national identity card and health card schemes, multinational
corporate card and ministry of defence identity card schemes. This demonstrates a
proven track record of managing issuers with requirements to issue many millions of
cards.
System availability again depends on customer requirements and an intelligent choice of

hardware and network architecture. Where high availability is required, ANDiS has been
deployed in environments which use techniques such as load balancing and system
mirroring to provide a robust and fault tolerant platform, and the Oracle database used by
ANDiS has tools available to support fault tolerant data storage. See also SECTION 10,
ARCHITECTURE.
10. ARCHITECTURE
10.1. Product Architecture

Developed on a fully J2EE compliant platform to maximise flexibility, ANDiS has been
designed and implemented following a ‘Three tier architecture’ model which separates the
database, business logic and presentation layers from the client applications, as illustrated
below.
Client Presentation Business Database
SOAP Client/ CAMS
Adapters SOAP J2EE
ACS
Events
Browser PIP
Web
JSP
Server Reports
ActiveX
Perso Gen’r
Wizard Data prep
Messaging
Pages etc…
Listeners
Multi Platform (MS, SUN, IBM, HP, Linux)
Apache, IIS Oracle

TomCat, WebLogic, SunOne, WebSphere …
Figure 6 ANDiS J2EE Multi Tier Product Architecture
10.2. Deployment Architecture
The flexibility of ANDiS J2EE based product architecture means that many different
deployment architectures and concepts can be met by a single instance of ANDiS. The
ultimate deployment architecture depends on the functional, performance, scalability and
availability requirements of the issuer, and also of the IT architecture policies of the
organisation deploying the system.
For example, simple requirements can be met by installing ANDIS and the Oracle
Database on a single server, perhaps to issue cards from a desktop printing system (as
shown below).

Chapter 10 - “Architecture”
Desktop Printer
ANDiS System
ANDiS Operator
Figure 7 Simple ANDiS configuration: Presentation, Business and Database Logic on one
server
However, the ANDiS’ flexible J2EE design means that ANDiS ‘tiers’ can also be physically
distributed across multiple systems, offering options to meet very high performance and
availability criteria, as might be required in a nationally scaled and mission critical system.
In very large implementations, ANDiS is typically deployed across several systems, with
physically and logically separate server systems running the database, the business logic
(effectively, the core ANDiS applications), and the ‘client facing’ web functions such as
enrolment, online card activation and/or post issuance personalisation (PIP) requirements.
The web based nature of the operator component lends itself ideally to a distributed
organisational structure. As an example, the following illustrates how ANDiS might be
deployed in a high performance, high availability environment taking advantage of
clustering techniques and technologies to further improve the predictability and resilience
of business–critical applications.
Personalisation Systems
Enterprise Directory
ANDiS CAMS ANDiS Database
Servers Servers
Identity Manager
ANDiS
Web Servers
Enterprise Portal Certificate Authority
Archiving
and Storage
ANDiS Operators
Application Providers
Figure 8 Example of ANDiS in a complex deployment: Clustered, physically separated

tiers

Chapter 11 - “Conclusion and Contacts”
11. CONCLUSION AND CONTACTS

Issuing chip based cards to meet immediate and future business and legislative
requirements in a technically and operationally efficient way can be a complex matter.
In particular, managing data related to lifecycles, processes and encryption keys, which
are likely to be linked to multiple cards, cardholders, and applications is an extremely
challenging task, especially when there are so many potential sources of data and
potentially many different formats, standards and protocols to support.
The solution is to focus the data and processes management onto a single, central Card
and Application Management System, which becomes the point at which many technical,
business and operational requirements can be structurally and systematically addressed.
ANDiS provides the proven, web-enabled software platform on which this strategy can be
realised.
ANDiS effectively consolidates and coordinates card related systems and processes
including enrolment, biometrics, key management, certificate issuing, personalisation and
post issuance personalisation, card(holder) and application administration, and data
exchange with back office systems. In addition, ANDiS provides the tools to define and
manage the appropriate and related lifecycles, most notably for different types of cards
and applications.
The intelligent and proven design of ANDiS also means that this comprehensive
functionality also provides a flexible, secure and scalable issuing platform.
Ultimately, ANDiS gives issuing organisations the opportunity to meet business,

technology and operations requirements in a way that benefits all of the stakeholders in a
card issuing business or project.
Bell ID would be pleased to help you learn more about how Bell ID’s ANDiS Card and
Application Management solutions can help you and your organisation, or to discuss your
own situation and requirements in more detail.
If you have any questions or remarks, please feel free to contact us:
Bell Identification B.V.
VISITING ADDRESS: Stationsplein 45

Entrance A, 6th floor
3013 AK Rotterdam
The Netherlands
POSTAL ADDRESS: P.O. Box 29141
3001 GC Rotterdam
The Netherlands
PHONE:  +31 (0) 10 885 1010
FAX:  +31 (0) 10 885 1011
E-MAIL (GENERIC):  info@bellid.com
E-MAIL (SALES):  sales@bellid.com
INTERNET:  www.bellid.com
For other Bell ID worldwide locations and an up to date list of our worldwide strategic
partners please visit the corporate website.

ANDiS CAMS Product Description 1 - 5 V 2.1

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ANDiS CAMS Product Description 1 - 5 V 2.1

Uploaded by

Copyright:

Available Formats

ANDiS CAMS

ANDiS Card and Application

Copyright © 2002-2009 - Bell Identification B.V. Product Version 1.5

1. EXECUTIVE SUMMARY ..................................................................................................2

3. THE CONCEPT OF CAMS ..............................................................................................2

6. KEY ELEMENTS OF THE CAMS ...................................................................................13

Copyright © 2002-2009 Bell Identification B.V. I

8. CAMS INTERFACES ...................................................................................................21

Copyright © 2002-2009 Bell Identification B.V. -1-

2.1. Document Structure

2.2. List of Figures

Copyright © 2002-2009 Bell Identification B.V. -3-

II. CONCEPTUAL VIEW ON THE CAMS

Copyright © 2002-2009 Bell Identification B.V. - 1-

3. THE CONCEPT OF CAMS

3.1. Anatomy of a CAMS

The following figure illustrates just some of the possible interactions:

Figure 1 Common interactions with CAMS

Legacy-aware, Open and Platform Independent

Copyright © 2002-2009 Bell Identification B.V. - 3-

3.2. CAMS as a Business Enabler

ANDiS offers a number of potential business benefits including:

 Reduced time-to-market for new applications – creates business agility,

 Post Issuance Personalisation of existing card population – flexible

 Optimised management of card base and cardholder relations – efficient

 Flexible reporting functionality – provides real-time views for portfolio

 Return on investment – ANDiS reduces re-investment for new cards or

3.3. ANDiS CAMS: The heart of a Smart Card Infrastructure

Data Card Provider

KWS KMS PIP Application

Figure 2 ANDiS CAMS in a typical environment

The CAMS is primarily responsible for:

Copyright © 2002-2009 Bell Identification B.V. - 5-

Additional components or options manage functional or interface requirements such as:

 Scheduled Data Preparation (mainly in banking/EMV)

4. OTHER ANDIS PRODUCTS

4.1. Authorisation Control System (ACS)

Card Request Check

McNeal Authorisers Card request check

Figure 3 Hierarchy in the ACS

4.2. Key Management System (KMS)

Copyright © 2002-2009 Bell Identification B.V. - 7-

Prior to the emergence of multi-application smart cards, each software application

Copyright © 2002-2009 Bell Identification B.V. - 9-

5.4. Europay International, MasterCard Visa (EMV)

5.5. Federal Information Processing Standards (FIPS)

 Must be issued based on sound criteria for verifying an individual employee’s

5.6. International Organization for Standardization (ISO)

Standards for application areas

Copyright © 2002-2009 Bell Identification B.V. - 11 -

III. FUNCTIONAL VIEW ON THE CAMS

6. KEY ELEMENTS OF THE CAMS

 Definition and Management of the potentially varied relationships between each of

important with smart Ready for Production

authorised’) leads to a Physically Withdrawn Installed

change of card state

production’). In Synchronized Card and Application Lifecycles

Copyright © 2002-2009 Bell Identification B.V. - 13 -

6.3. Managing Card Configuration

As has been described, ANDiS is capable of supporting many combinations on a single

 Issuers: An entity that is responsible for issuing cards. With single-application

 Membership: Where cardholders could be members of multiple target groups,