Applicable Standards Paper

bubblesvoltaireInternet και Εφαρμογές Web

10 Νοε 2013 (πριν από 3 χρόνια και 7 μήνες)

334 εμφανίσεις


-
1
-













Applicable Standards Paper










Report
WP3
-

03

Version
4.0

March

2004

© Londo
n

Connects for the National Smart Card Project

bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013





-
2
-


1.

Abstract


Technical standards and operating rules are necessary to allow local authorities to purchase
cost
-
effectively and with confidence that they will not be locked in to a restricted supply
situation or
implement systems that will become obsolete
.
C
ommon set
s
of standards and
rules are
important
to define and enable interoperability between local authority systems
across the UK where such interoperability is felt to be desirable


Standards are needed as

base level building blocks for the development of products and
services; they are not detailed specifications. This is to encourage competition, diversity of
design and new initiatives among suppliers. The balance between generality and detailed
specifi
cation in standards is one which is difficult to achieve and different standards take
different approaches. Nevertheless, a standard is not normally a specification.


This paper defines those standards that apply to Local Authority smart cards used in
d
ifferent applications. The initial selection of applicable standards are taken from the e
-
GIF
specification produced by the Office of the e
-
Envoy, augmented by additional application
level standards not included in e
-
GIF but seen by LASSeO to be applicabl
e. Other
“standards” may also be included based upon industry generated,
de facto

standards as well
as CEN/ISSS Workshop Agreements.

Unfortunately, at this time all necessary standards
are not defined, which only serves to add to the complications in de
fining baseline standards
and accompanying business rules.


D
eveloping standards in other parts of the world could well have a long term effect upon
standards in the UK and Europe

and are considered.


The paper covers microprocessor cards with contact
interfaces, with proximity contactless
interfaces and cards with both (dual interface cards). It addresses Baseline standards for
cards, Test standards for cards, Relevant consortium and industry
de facto

standards and
specifications, Application level s
tandards and specifications, and, Security standards and
specifications.

These standards are listed with commentary and crucially,

a table is provided
of
de facto

and
de jure

standards that should be reviewed before implement
ing any card
scheme.



It is
to be noted that this paper is just a starting point. Technology does not stand still and
standards continue to develop. Therefore, the recommended list of standards, coupled with
the policies and rules to fill the gaps, will require constant revision an
d such a process needs
to be designed and maintained. It is suggested that LASSeO is the right organisation to
carry out this work, feeding the e
-
GIF with information about newly developed
de facto

and
de jure

standards as they appear.











bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




Table of
Contents


1.

Abstract

................................
................................
................................
.....................

2

2.

Introduction

................................
................................
................................
...............

4

3.

Background

................................
................................
................................
...............

5

3.1

The Role of Standards

................................
................................
...........................

5

3.2

Developing Standards

................................
................................
...........................

6

3.3

Non
-
European Initiatives

................................
................................
.......................

6

3.3.1

Japan

................................
................................
................................
.................

6

3.3.2

USA

................................
................................
................................
...................

6

3.4

Relevant Standards Bodies

................................
................................
...................

7

4.

The Citizen Card Environment

................................
................................
...................

8

4.1

Smart card Applications

................................
................................
.........................

8

4.1.1

Public Sector

................................
................................
................................
.....

8

4.1.2

Private Sector

................................
................................
................................
....

8

4.2

Smart Card Services
................................
................................
..............................

8

5.

Scope of Analysis

................................
................................
................................
....

10

6.

Overarching Issues
................................
................................
................................
..

11

6.1

Legal Issues (EC Directives)

................................
................................
................

11

6.1.1

The Pu
blic Procurement Directive

................................
................................
....

11

6.1.2

The Electronic Signatures Directive

................................
................................
.

12

6.1.3

The Electronic Money Directive

................................
................................
.......

12

6.2

Standards Related Issues

................................
................................
....................

12

6.2.1

ISO 9000 Quality Methodology

................................
................................
........

12

6.2.2

ISO/IEC 177
99 (BS 7799) Policy on Security

................................
...................

12

6.2.3

Implied Standards

................................
................................
............................

12

6.2.4

Reference to Applicable Standards

................................
................................
..

13

6.2.5

Options within Standards

................................
................................
.................

13

6.2.6

Identification and Numbering Roots

................................
................................
.

13

6.2.7

PKI Interoper
ability

................................
................................
..........................

13

6.2.8

Maturity of Standards and Specifications

................................
.........................

14

7.

List of Standards

................................
................................
................................
.....

14

7.1

Baseline Standards Relevant to Smart Cards and the NSCP

..............................

14

7.2

Application Level Standards

................................
................................
................

21

7.3

Security

................................
................................
................................
...............

23

7.4

Terminals

................................
................................
................................
.............

27

8.

Recommended Use of Standards

................................
................................
............

29

9.

Outstanding Issues

................................
................................
................................
..

32

10.

Appendix 1


National Smart Card Project Glossary

................................
................

33


bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013





2.

Introduction


This paper is written as part of the work of the
Standards section of the
National
Sma
rt Card

Project (NS
C
P), which is charged with, amongst other things establishing the technical
standards and operating rules necessary to allow local authorities to purchase cost
-
effectively and with confidence that they will not be locked in to a restrict
ed supply situation
or implement systems that will become obsolete
.

It is also important that

a

common set of
standards and rules are established to define and enable interoperability between local
authority systems across the UK where such interoperabil
ity is felt to be desirable


This paper defines those standards that apply to Local Authority
smart card
s used in
different applications
.
In some cases, specific standards will apply, while in other cases
there will be flexibility in the selection of stan
dards that may be applied, and in yet other
cases there will be no known standards that can be applied at this time.


The initial selection of applicable standards are taken from the e
-
GIF specification produced
by the Office of the e
-
Envoy, augmented by a
dditional application level standards not
included in
e
-
GIF

but seen by LASSeO to be applicable
.
Other “standards” may also be
included based upon industry generated,
de facto

standards as well as CEN/ISSS Workshop
Agreements.


This exercise is not restri
cted to a consideration of the UK, since developing standards in
other parts of the world could well have a long term effect upon standards in the UK and
Europe.























bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




3.

Background

3.1

The Role of Standards

Standards are intended to provide base

level building blocks for the development of products
and services; they are not intended to be detailed specifications
.
The main reason for this is
to encourage and allow competition, diversity of design and new initiatives among suppliers,
else industr
y will never move forward and/or standards will be ignored
.
The balance
between generality and detailed specification in standards is one which is difficult to achieve
and different standards take different approaches
.
Nevertheless, a standard is not nor
mally
a specification
.
One good example is the
smart card

standard ISO/IEC 7816 in all its various
parts, which is as near a specification as one can get in a standard
.
Yet even when they
both comply with ISO/IEC 7816, no two
smart card

types from differ
ent manufacturers are
100% compatible and they are frequently not interchangeable in an

i
nteroperable
environment.


Smart card
s require the definition of standards in a multi
-
layered manner, for example,
dealing with the underlying electrical interfaces, t
he communications protocols, data
organisation and security
.
Indeed, some standards do operate at these discrete levels, for
example the different parts of ISO/IEC 7816
.
However, other standards deal with the
smart
card

and its environment in its entiret
y, for example the industry specified,
de facto

standard
Global Platform
.


Some standards are mutually exclusive with other standards, although both may be relevant
to a specific user community, for example the different standards dealing with the contac
t
and contactless electrical interfaces to
smart card
s
.
As a result, those specifying base
standards for use in given environments will have to be careful in the manner of rule
specification concerning the use of standards.


It is also to be noted that so
me standards depend upon other standards
.
In particular, some
application level standards such as ITSO in the transport
sector

will rely on base level
contactless interface standards
.
Again, great care has to be taken with the specification of
base level

requirements, especially in an open multi
-
application
smart card

environment
.
It
is for this reason that this paper has been written
.
It is necessary to define key base level
standards, the options for use where they are mutually exclusive, the requirem
ents for
additional standards in different application environments, and the various other options
open to scheme implementers which may or may not attract attendant additional standards
requirements.


Finally, reverting back to the premise that standards
are building blocks and not detailed
level specifications, in any given environment desiring interoperability, there will have to be
another layer of specification dealing with the gap between standards and specification
.
This is usually handled through p
olicy and business rules, and in the context of the
National
Smart Card Project
, is the subject of a separate paper

(WP3
-
01)
.







bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




3.2

Developing Standards

Unfortunately, at this time
not
all necessary standards are
defined, which only serves to add
to
the complications in sorting out necessary baseline standards and accompanying
business rules
.
Some examples, but not a complete list, of where work is ongoing are:



CEN TC224 WG11 Standards for transport applications on
smart card
s



CEN TC224 WG15 Standard
s for citizen cards



Electronic signature standards



PKI standards



Standards for healthcare applications on
smart card
s


The result is very much one of working on “shifting sands”
.
The effect will be that while one
can pre
-
judge the results to a large exten
t, there will still have to be a mechanism to allow
new standards to be incorporated into the rules applying to multi
-
application Local Authority
cards.

3.3

Non
-
European Initiatives

It is also necessary to consider non
-
European initiatives which may have long
term effects
upon European standards
.

3.3.1

Japan

A Japanese Government and industry initiative has recently been completed under the name
Next Generation IC Card System Study group (NICSS)
.
This multi
-
million pound study
deployed over 1 million citizen cards

enabling access to local and central government
services in Japan
.
Local deployment of cards was carried out under the control of the local
authorities concerned, but overall control of standards and rules was managed at a central
Government level
.


The
scheme is based upon contactless card technology without a
supporting second contact interface.


As a result of this work, Japan is standardising on its design and rolling out its solution at a
national level
.
Development funding was around £100m with car
ds initially issued to citizens
based upon a central Government subsidy of about £7
.
Clearly this is a serious attempt to
make citizen card
s

happen and Japanese industry is conscious that the volumes involved
will give them a massive platform on which to
build their
smart card

industry
.
With this in
mind, they are negotiating and lobbying both the US and European relevant bodies to
attempt to sway world standards in their direction.

3.3.2

USA

The events of 9/11 and the establishment of the Department for Homela
nd Security has
jump
-
started the US from being nowhere in the field of smart cards to potential leaders as
they begin to insist that all citizens and visitors have smart ID cards
.
At this time, all US
military and all Federal employees are being issued wi
th smart cards, which means that
there are already millions of such cards in circulation in the US
.
The initial thrust in terms of
standards was to gather together industry representatives and work with them to develop a
specification for the Common Acces
s Card (CAC)
-

now in its second version (V2.1).


This work has been picked up and continued by the US standards agency NIST which is
pursuing the development of the standard including interoperability specifications to
encompass multiple card types, and c
ard management schemes
.
NIST is attempting to
work both with Japan and Europe to converge on a common set of standards but of course,
would like this to be in support of their own work which is being driven by the separate
imperative of Homeland Security.

bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013





NIST ha
s

recently submitted
its

work in this area to ISO for adoption as a new work item

and
this has been accepted by

the member countries
.
The CEN TC224 WG15 Citizen Card
group is in close liaison with NIST on this development.



It is to be noted tha
t the USA has also insisted that all long stay visitors arriving after
autumn

2004 must have a visa or passport that is electronically readable and incorporates a
biometric template
.
ICAO has taken on the responsibility of merging their ongoing work on
el
ectronically readable passports with the US decision.


3.4

Relevant Standards Bodies

Two types of standards exist:
de facto

and
de jure
.
The former are produced by informal
bodies, such as industry associations, and they either become standard by virtue of th
eir
market penetration or by the weight of the organisations behind them
.
EMVCo and ITSO
constitute
de facto

standards making bodies
.

By virtue of their importance and widespread
adoption, they are referenced as necessary in this document.


The latter,
de jure
, standards are formal standards and are the product of the work of official
standards bodies
.
Here, the standard follows a highly formalised development, voting and
acceptance process, including lengthy consultations at the national level within e
ach
member country
.


There are three levels of formal standard:



International (e.g
.
ISO and ISO/IEC),



European (e.g. CEN, ETSI and CENELEC),



National (e.g
.
BSI in the UK)
.


De jure

standards typically take about
3

years to finalise
.
Once issued,
they remain stable
and are reviewed for update every 5 years
.


Owing to the rapid pace of change for information technology, CEN in 1997 set up the
CEN/ISSS organisation as a fast track standards process
.
By combining the quality and
assurance achieved
via formal open consensus offered by
de jure

standards with the rapid
process of informal specification offered by
de facto

standards, a hybrid of the best parts of
de facto

and
de jure

standards was forged
.


Unlike formal standards, CEN/ISSS Workshop Ag
reements (CWAs) undergo a much more
rapid consensus and voting procedure, based upon those who choose to join a workshop
.
Workshops are open to everyone and are not restricted to those representing the national
standards bodies, and there is no formal con
sultation period within each member country
.
Hence start to finish times for CWA can be of the order of just one year.


Of the above, certain ISO and ISO/IEC, CEN, CEN/ISSS and ETSI standards are relevant to
smart cards.






bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




4.

The Citizen Card Enviro
nment


In order to set down a list of standards applying to
smart card
s and their usage in a multi
-
application Local Authority environment, it is necessary to scope and bound the likely range
of application and environment uses of such cards
.

4.1

Smart

card

Applications

Smart card

applications on Local Authority cards may be classified into public and private
sector applications, where sometimes, the distinction may be a little grey, for example
transport applications
.
Nevertheless, the classification is va
luable and, in this paper, is taken
from the work of
the
Commercial Applications

section

of the
National Smart Card Project
.

4.1.1

Public Sector

Typical Local Authority applications will be:



Libraries



Leisure



Housing



Benefits



Schools


Typical central Government
applications will be:



Access to services



Healthcare associated



Driving and vehicle associated



(Identity and Entitlement)

4.1.2

Private Sector

The private sector applications listed below in some cases could be considered as public
sector applications
.
In this p
aper the listings used are those assumed by
the
Commercial
Applications

section
, of the
National Smart Card Project
.



Transport



Loyalty




ID



PKI/Authentication



Payment and e
-
purse



Retail Entitlement



Tourism


The extent to which a card may be considered an Id
entity card is up to the individual scheme
concerned and outside the scope of this paper
.
Reference is made to supporting standards
where relevant.



4.2

Smart Card

Services

Supporting the above public and private sector applications will be a number of basic

services which may be offered centrally as part of the card management facility or via
specific public or private service providers
.



Security services (certification, encryption etc.)



Citizen account

bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013






Profiling



Preferences


Security services involve the

use of the capabilities of the card to interface with the
application and system level requirements for security.


Citizen account, profile and preferences involve the management of information supplied by
the cardholder for use openly as needed to adapt
interfaces, adapt application presentation
and supply basic information to applications to avoid unnecessary repetitive entry of data by
the cardholder
.
This group of services may be considered as another application.





































bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




5.

Scope of Analysis


Standards and specifications cover a very wide area, even within the bounds of ICT and the
even narrower bounds of
smart card
s
.
This paper is written for
the Standards section of
the
National Smart Card Project

and as such covers those
areas which are of interest to that
project.


Topics given full coverage in the list of applicable standards and specifications apply to
microprocessor cards with contact interfaces and with proximity contactless interfaces
.
This
includes cards with both
interfaces


known as dual interface cards:



Baseline standards for cards



Test standards for cards



Relevant consortium and industry
de facto

standards and specifications



Application level standards and specifications



Security standards and specifications


E
xcluded topics are:



Memory cards



ETSI standards



CENELEC standards



SIM cards


Subjects which are addressed but not covered in detail are:



Vicinity contactless cards

(contactless cards



Testing and accreditation specifications


Subjects which are addressed i
n a little more detail but require further investigation and
analysis are:



Card readers



Card management



PKI


In addition, some topics can lead into associated but peripheral areas and strict bounds are
placed on these
.
For example JavaCards take us into a

consideration of Java
.
However,
Java language standards themselves are not discussed.


As well as standards and specifications, this paper includes information about a number of
related issues affecting the choice of standards and specifications, for exa
mple Legal
Requirements.











bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




6.

Overarching Issues


The

following

are issues
that
may affect decisions taken but are not seen as specifically
relevant to
smart card
s alone.

6.1

Legal Issues (EC Directives)

6.1.1

The Public Procurement Directive

At first s
ight that this Directive might seem not to apply to mainstream procurement in public
sector ICT including
smart card
s, however, the references to transport and
telecommunications suggest that its procedures should be followed in ICT procurement for
e
-
Gover
nment schemes
.



Technical Specifications and Standards

Article 18



Contracting entities shall include the technical specifications in the general
documents or the contract documents relating to each contract
.

2
.
The technical specificatio
ns shall be defined by reference to European
specifications, where these exist
.

3
.
In the absence of European specifications, the technical specifications should as
far as possible be defined by reference to other standards having currency within the
Co
mmunity
.

4
.
Contracting entities shall define such further requirements as are necessary to
complete European specifications or other standards
.
In so doing, they shall prefer
specifications which indicate performance requirements rather than design or

description characteristics, unless the contracting entity has objective reasons for
considering that such specifications are inadequate for the purposes of the contract
.



Technical specifications which mention goods of a specific make or source or
of a
particular process, and which have the effect of favouring or eliminating
certain undertakings, shall not be used unless such specifications are
indispensable for the subject of the contract
.
In particular, the indication of
trade marks, patents, types, o
f specific origin or production shall be
prohibited; however, such an indication accompanied by the works ‘or
equivalent’ shall be authorized where the subject of the contract cannot
otherwise be described by specifications which are sufficiently precise a
nd
fully intelligible to all concerned
.



Contracting entities may derogate from paragraph 2 if:



it is technically impossible to establish satisfactorily that a product conforms to
the European specifications;

(b) the application of paragraph 2 would pre
judice the application of Council Directive
86/361/EEC of 24 July 1986 on the initial stage of the mutual recognition of type
approval for telecommunications terminal equipment(14) , or of Council Decision
87/95/EEC of 22 December 1986 on standardization i
n the field of information
technology and telecommunications(15) ;


(c)

in the context of adapting existing practice to take account of European
specifications, use of those specifications would oblige the contracting entity to
acquire supplies incompat
ible with equipment already in use or would entail
disproportionate cost or disproportionate technical difficulty
.
Contracting entities
which have recourse to this derogation shall do so only as part of clearly
-
defined and
recorded strategy with a view to

a changeover to European specifications;

bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




(d) the relevant European specification is inappropriate for the particular application
or does not take account of technical developments which have come about since its
adoption
.
Contracting entities which hav
e recourse to this derogation shall inform the
appropriate standardizing organization, or any other body empowered to review the
European specification, of the reasons why they consider the European specification
to be inappropriate and shall request its r
evision;

(e) the project is of a genuinely innovative nature for which use of European
specifications would not be appropriate
.



Notices published pursuant to Article 21 (1) (a) or Article 21 (2) (a) shall
indicate any recourse to the derogations referre
d to in paragraph 6
.

8
.
This Article shall be without prejudice to compulsory technical rules in so far as
these are compatible with Community law
.



6.1.2

The Electronic Signatures Directive

Adopted in July 2003, Directive 2003/511/EC to be reviewed in two
years
.
The directive
states:




List of generally recognised standards for electronic signature products that
Member States shall presume are in compliance with the requirements laid
down in Annex II f to Directive 1999/93/EC



CWA 14167
-
1 (March 2003): secur
ity requirements for trustworthy systems
managing certificates for electronic signatures


Part 1: System Security
Requirements



CWA 14167
-
2 (March 2002): security requirements for trustworthy systems
managing certificates for electronic signatures


Part 2
: cryptographic
module for CSP signing operations


Protection Profile (MCSO
-
PP)

B
.
List of the generally recognised standards for electronic signature products that
Member States shall presume are in compliance with the requirements laid down
in Annex II
I to Directive 1999/93/EC



CWA 14169 (March 2002): secure signature
-
creation devices.



The implication is that CWA 14167 and CWA 14169 apply as mandatory standards.


In addition directive
2000/709/EC sets down minimum criteria to be taken into account when

designating bodies with respect to Directive 1999/93/EC on a framework for electronic
signatures.

6.1.3

The Electronic Money Directive

In the UK, the FSA makes the rules, and its publications should be consulted.

6.2

Standards Related Issues

6.2.1

ISO 9000 Quality Method
ology

While not specifically to do with
smart card
s, it is good practice to follow ISO 9000
.

6.2.2

ISO/IEC 17799 (BS 7799) Policy on Security

This standard is specified as mandatory in most scheme
s related to security or with a
significant dependence upon security
.

6.2.3

Implied Standards

In some cases standards are implied within other standards or usages
.
One example would
be the use of a USB
interface
;

others might include un
-
stated but relevant RF Emission
bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




requirements
.
The scope of this paper precludes addressing all such implied standards and
merely draws attention to their existence; It must be the responsibility of the implementer to
be aware of
and ensure that attention is paid to such implied standards.

6.2.4

Reference to Applicable Standards

In most cases, reference to applicable standards within standards is explicit rather than
implied
.
Examples would be references in various
smart card

standards

to:

ISO 3166:1997 representation of names of countries


ISO 8601:2000 representation of dates and times


ISO 5218:1997 representation of human sexes


ISO 10646 alphabet for multi
-
lingual use


This paper does not follow the referenced standards path throug
h the standards it highlights
and it is left to the implementer to ensure that attention is paid to such standards.

6.2.5

Options within Standards


Some standards offer options with the standard
.
This paper does not recommend one
option over another, however,
i
t may be advantageous
to make such selections to help
guarantee interoperability
.
Relevant examples would be:

ISO 639 representation of names of languages which has 2 and 3 letter code options

ISO 144
43 contactless
smart card
s which has type A and B interface alternatives

6.2.6

Identification and Numbering Roots

Many standards and schemes implemented following standards contain numbers and
hierarchies of numbers which need to be unique, nationally or interna
tionally
.
This is usually
achieved by means of appending unique number parts supplied by a formal registration body
such as ISO or CEN or their assigns
.
In the case of
smart card
s, there are two numbering
schemes which may be applied:



IIN



OID


IIN (Issu
er Identification Number) is standardised through ISO/IEC 7812
.
The purpose of the
numbering system is to uniquely identify a card issuing institution in an international
interchange environment
.
Although the standard states explicitly that the IIN must
be used
only to identify a card issuer, it has come to be used in many other ways.


OID (Object Identifier) is standardised through ISO 8824
.
The purpose is to define
uniqueness in the numbering of objects whatever they may be, including companies,
organi
sations, schemes, standards and specifications.


While both systems are used for
smart card

schemes, at this time the IIN is more common,
but in reality, the OID would be more appropriate
.

Future work

Requirement to determine the use of OID or IIN
.


6.2.7

PKI

Interoperability

PKI is a much discussed but poorly understood concept within the overall subject of security
.
Its aim is to engender trust between entities unknown to one another operating in different
systems
.
This is achieved through a process of cer
tificates of “genuineness” supplied by the
sender and validated by the recipient
.
It is clear therefore that there has to be
bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




interoperability across certification schemes
.
Unfortunately, this is not currently the case,
although standards are beginning to

encroach around the edges
.
In the UK, activity in this
area has been conspicuous by its absence so far
.


The closest we come to standards are a consensus to follow the X.509 certificate
recommendation which seems to have become a
de facto

standard
.
Fo
llowing on from this
will be the uses of these certificates in various forms of digital signature, which again suffer
through lack of standards
.
It is outside the scope of this paper to consider this subject in
detail
(see WP7
-
09)
and make formal recommen
dations
.

6.2.8

Maturity of Standards and Specifications

Many of the base standards and specifications applying to smart card technology are
not
mature, are therefore subject to change, and sometimes clash with each other
.
The clash
may be technical or procedural or both
.
A technical clash may give problems in operation,
although suppliers of cards and equipment are increasingly working to mi
nimise this
.
A
procedural clash is usually because some component is not certified for use by one or other
scheme
.
T
hat scheme will therefore not allow their transactions via that product or
component.


Where interoperability is required, the trend

is to give industry and public
-
private consortium
specifications priority over international standards
.
The consortia (such as EMV and Global
Platform) are working towards migration of core standards and specifications to common
ground, so as to minimise

the restrictions on development and use of multi
-
application card
platforms
.
This migration period is expected to last for at least 5 years.





















7.

List of Standards

7.1

Baseline Standards Relevant to
Smart Card
s and the NSCP


Standard or Specif
ication

Comments

bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




Standard or Specif
ication

Comments

Physical characteristics

ISO/IEC 7810:
2003


Identification cards

=
mhy獩捡c=捨cr慣瑥ai獴i捳
=
qo=敮獵牥=t桡t=t桥y=捡c=扥=r敡d=i渠愠st慮摡r搠
r敡摥rI=慬l=捡r摳⁳桯畬d=扥=i渠na
-
ㄠf潲m慴=慳=
摥fi湥搠楮=t桩s=st慮摡rd
K==
=
e潷ev敲e=捯ct慣tl敳猠to步k
=
t散e湯logy=慰灥慲a=i渠
m慮y=潴桥o=form猬=獵捨=慳⁰敮a慮tsI=慮搠m慹=
獯s渠慰灥慲=i渠nm扥摤e搠form=i渠nr慶敬=
摯捵浥湴猠獵捨=慳=灡獳灯rts
K==
=
bm扯獳sng
=
fpl/fbC=㜸ㄱ
-
ㄺ㈰〲=
=
f摥湴nfi捡ti潮=捡牤猠

=
oe捯牤c湧=te捨ciq略=

=
m慲a=1:=bm扯獳sng
K==
=

To be avoided if pos
sible as the embossing
process risks damaging the integrated circuit, and
in the case of contactless cards, the antenna.

It should also be noted, however, that many smart
card readers cannot accept embossed cards.

Identification of Issuers

ISO/IEC 7812
-
1:
2000

Numbering system

ISO/IEC 7812
-
2:2000

Application &
registration procedures

Identification Cards, Identification of Issuers

Integrated circuit cards with contacts

ISO/IEC 7816

This standard has

thirteen
parts


As a standard, 7816 has many options, an
d thus
use of this standard alone will not guarantee
interoperability
.
It

consists of the following parts,
under the general title Identification cards


=
f湴n杲慴敤=捩r捵ct=捡牤猺
=
m慲a
=
1:= C慲摳= wit栠 捯ct慣a猺= m桹獩捡c=
捨cr慣瑥ri獴i捳
=
m慲a
=
O:= C慲摳a wit栠 捯
湴慣ns:= aim敮獩潮猠 慮d=
l潣oti潮=of=t桥=捯cta捴s
=
m慲a
=
3:=C慲摳awit栠捯湴a捴猺=bl散eri捡c=i湴敲fa捥⁡湤=
tr慮smi獳s潮=灲pt潣ols
=
m慲a
=
4:= lrga湩z慴楯測n 獥捵物瑹= 慮搠捯mm慮摳= f潲o
i湴敲捨cnge
=
m慲a
=
R:=oegistrati潮=of=慰灬i捡瑩c渠灲潶i摥rs
=
m慲a
=
S:=fnt敲楮摵獴ry=摡t
a=敬敭敮e猠f潲=i湴敲捨cn来
=
m慲a
=
T:= C潭m慮摳d f潲= ptr畣瑵r敤= C慲搠 n略r礠
䱡湧畡ge=EpCni)
=
m慲a
=
U:=Comm慮摳df潲=獥捵物瑹=潰敲eti潮s
=
m慲a
=
9:=Comm慮摳df潲=捡r搠m慮ag敭敮t
=
m慲a
=
㄰:= Car摳d wit栠 捯ct慣瑳:= bl散eri捡c= i湴敲fa捥c
f潲=獹湣nr潮潵猠捡r摳
=
m慲a
=
ㄱ:= m敲獯湡e= v
敲楦i捡瑩c渠 t桲潵g栠 扩潭整ri挠
m整桯摳
=
m慲a
=
ㄲ:= C慲摳a wit栠 捯ct慣a猺= rpB= 敬散瑲i捡c=
i湴敲f慣a=慮搠潰敲eti湧=pr潣o摵r敳
=
m慲a
=
ㄵ:=Cry灴潧p慰桩挠inf潲m慴楯渠慰灬i捡瑩cn
=
k潴攠 慬獯s t桡t= 獯m攠 of= t桥= am敮dm敮ts= li獴ed=
桡v攠扥敮=i湣nr灯rat敤=i湴漠t桥=湥w=摲dftsK
=

=
t桩猠tim攬emart猠㌠
-
=
㤠慲攠畮摥rg潩ng=愠捯m灬整攠
r敯rg慮i獡瑩sn
K==
m慲t猠㘬=㠠慮搠㤠慲攠慴afi湡l=扡ll潴o
獴ag攠慮搠will=扥=灵扬is桥搠獨srtlyK=m慲a=㐠慮搠㔠
獨s畬搠do=to=fi湡l=扡ll潴=stag攠楮=j慹=㈰〴K
=
=
bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




Standard or Specif
ication

Comments



ISO/IEC 㜸ㄶ
-
ㄺㄹ㤸 Id敮tifi捡瑩c渠捡r摳
-

I湴n杲慴敤 c
ir捵ct(猩 捡rd猠wit栠捯湴慣ts

=
m慲a=1:=m桹獩捡c=捨cr慣teri獴i捳
=
q桩猠灡rt=獵s灬敭敮ts=fpl/fbC
=
㜸㄰I=獥tting=潵t=
t桥=灡rti捵c慲=灨y獩捡c=捨cr慣瑥ri獴i捳cof=fC=捡牤c=
wit栠捯湴慣tsK
=
araft=Am敮dm敮t==ㄺ=jaxim畭u桥ight=of=捯ct慣ts=
慢潶攠獵ef慣a
=


ISO/IEC 㜸ㄶ
-

ㄹ㤹 Id敮tifi捡瑩c渠捡r摳
-

I湴n杲慴敤 捩r捵ct(猩 捡rd猠wit栠捯湴慣t猠

=
m慲a=O:=aim敮獩潮猠慮d=l潣oti潮=of=t桥=
捯ct慣as
=
araft=Am敮dm敮t=1:=A獳sgnm敮t=of=捯ct慣瑳=C㐠
慮搠䌸=Ef潲=rpB=i湴nrf慣攩
=


ISO/IEC 㜸ㄶ
-
㌺ㄹ㤷 Id敮tifi捡瑩c渠捡r摳
-

I湴n杲慴敤 捩r捵ct(s
) 捡rd猠wit栠捯湴慣t猠

=
m慲a=3:=bl散tr潮ic=獩g湡ls=慮搠
tr慮smi獳s潮=灲pt潣ols
=


Al獯⁁浥湤浥st 1:㈰〲 El散瑲i捡c
捨cr慣瑥ri獴i捳 慮搠捬d獳 i湤i捡瑩c渠for
i湴敧n慴敤 捩r捵ct(s) 捡rd猠潰敲eti湧 慴 㕖,
㍖ 慮搠d.㡖

Am敮摭敮t 1/㈺ ㈰〲
-

El散瑲i捡c 捨cr慣teri獴ic

慮搠捬d獳si湤i捡瑩c渠f潲 i湴ngrat敤 捩r捵ct(s) 捡牤c
潰敲慴ing at 5 V, ㌠3 慮d ㄬ1 V




ISO/IEC 㜸ㄶ
-
㐺ㄹ㤵 Id敮tifi捡瑩c渠捡r摳
-

I湴n杲慴敤 捩r捵ct(猩 捡rd猠wit栠捯湴慣t猠

=
m慲a=4:=fnt敲
-
i湤畳瑲y=捯mm慮摳=f潲=
i湴敲捨cnge
=
=
Al獯⁁浥湤浥st=1:ㄹ㤷=fm灡捴=of
=
獥捵r攠
m敳獡ging=潮=t桥=str畣t畲敳uof=Amar=
獴r畣t畲u猠
=
p整猠潵t=t桥=file=獴r畣u畲u猬=獥捵牥=m敳獡gi湧=for=
fil攠e捣敳cI=捡r搠慰灬i捡瑩潮=獴art
-
異I=慮搠汯gi捡c=
捨c湮敬猠for=畳u=w桥r攠e桥=捡牤=捡c=h慶攠e潲o=
t桡渠潮n=virt畡l=捯cm畮i捡瑩c湳⁣桡湮敬=慣tive
⸠K
=
A
m敮摭敮t=1:ㄹ㤷=
-
=
pe捵牥cm敳獡ging=潮=t桥=
獴r畣t畲u=of=Amar=me獳慧敳=
=
=


ISO/IEC 㜸ㄶ
-
㔺 ㄹ㤴 Id敮tifi捡瑩c渠捡r摳
-

I湴n杲慴敤 捩r捵ct(猩 捡r摳⁷it栠捯湴慣t猠

=
m慲a=R:=kum扥rin朠獹獴em=慮d=registrati潮=
灲潣敤pre=for=慰灬i捡瑩cn=i摥湴nfi敲e
=
=
Al獯⁁浥湤浥st=
1:ㄹ㤶=o敧ist敲敤=
慰灬i捡瑩c渠灲潶i摥r=i摥湴ifi敲e=Eofa猩=
=
A=regi獴er=of=smart=
捡牤=慰灬i捡瑩c渠灲潶i摥r猠
i猠
k数t=批=hqAp=i渠䑥nm慲欠慮搠畳敤=f潲=慰灬i捡瑩c渠
獥s散瑩e渠nhr潵g栠t桥=us攠ef=畮iq略=
i獳略r/慰灬i捡瑩c渠楤敮tifi敲e捯m扩湡ti潮献
=
=


ISO/IEC 㜸ㄶ
-
㘺6
㤹6 Id敮tifi捡瑩c渠捡r摳
-

I湴n杲慴敤 捩r捵ct(猩 捡rd猠wit栠捯湴慣t猠

=
m慲a=S:=fnt敲
-
i湤畳瑲y=摡t愠敬敭敮es
=
=
Am敮摭敮t=1:㈰〰=fC=m慮uf慣瑵r敲=
regi獴rati潮
=
f湴nr
-
industry data elements such as cardholder’s
湡m攬=數灩ry=摡t攠整挮
=
=


ISO/IEC 㜸ㄶ
-
㜺 ㄹ㤹 Id敮t
ifi捡瑩c渠捡r摳
-

I湴n杲慴敤 捩r捵ct(猩 捡r摳⁷it栠捯湴慣t猠

=
m慲a=T:=fnt敲
-
i湤畳瑲y=捯mm慮摳=f潲=
ptr畣t畲敤=C慲搠n略ry=䱡湧畡ge=EpCni)
=
䱩ttl攠畳敤=慮搠湯t=灡rtic畬慲汹=r敬敶慮t=t漠o桥=
乓䍐
=


ISO/IEC 㜸ㄶ
-
㠺 ㄹ㤹 Id敮tifi捡瑩c渠捡r摳
-

I湴n杲慴敤 捩r捵ct(猩

捡r摳⁷it栠捯湴慣t猠

=
m慲a=U:=pe捵物瑹=i湴nr
-
i湤畳瑲y=捯mm慮ds
=
p潭攠of=t桥=敬em敮ts=of=t桩猠v敲獩e渠nf=fpl/fbC=
㜸ㄶ
-
㠠Ur攠摵e=to=扥=su灥r獥s敤=批=a=r敶i獥s=
v敲獩e渠nf=fpl/fbC=㜸ㄶ
-
4
K==
==========================================================
=
bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




Standard or Specif
ication

Comments



ISO/IEC 㜸1
6
-
㤺 :㈰〰 I摥湴nfi捡瑩c渠捡r摳
-

I湴n杲慴敤 捩r捵ct(猩 捡r摳⁷it栠捯湴慣t猠

=
m慲a=9:=A摤iti潮慬=i湴敲
-
i湤畳瑲y=
捯浭慮d猠慮d=獥捵rity=慴ari扵t敳
=
p潭攠of=t桥=敬em敮ts=of=t桩猠v敲獩e渠nf=fpl/fbC=
㜸ㄶ
-
㤠9r攠摵e=to=扥=
su灥r獥s敤=批
=
a=r敶i獥s=
v敲獩e渠nf=fpl/fbC
=
㜸ㄶ
-
4
K==
=


ISO/IEC 㜸ㄶ
-
㄰: ㄹ㤹 I摥湴nfi捡瑩c渠
捡牤猠
-

I湴n杲慴e搠捩牣畩t(猩 捡r摳 wit栠
捯ct慣a猠

=
m慲t=㄰:=bl散er潮i挠獩g湡l猠慮d=
慮獷敲et漠r敳et=for=獹湣nr潮潵猠捡r摳
=
k潴or敬敶慮t=t漠t桥=kpCm
=


ISO/IEC 㜸ㄶ
-


I摥ntifi捡瑩c渠捡r摳d


I湴n杲慴敤 捩r捵ct(
猩 捡rd猠wit栠捯湴慣t猠


P慲a ㄱ: Per獯s慬 v敲efic慴楯渠nhr潵g栠
扩潭整ric met桯摳
.


Passed its final ballot and will be published shortly



ISO/IEC 㜸ㄶ
-
ㄲ I摥ntifi捡瑩c渠捡r摳d


I湴n杲慴敤 捩r捵ct(猩 捡rd猠wit栠捯湴慣t猠


P慲a ㄲ: USB Int敲f慣a

N潴oye
t 扡ll潴敤 慮搠慣d数t敤



ISO/IEC 㜸ㄶ
-


I摥ntifi捡瑩c渠捡r摳d


I湴n杲慴敤 捩r捵ct(猩 捡rd猠wit栠捯湴慣t猠


P慲a ㄵ: Cry灴潧p慰桩挠tok敮 inf潲mati潮
i渠nC 捡r摳d

P畢li獨sd

C潮t慣瑬a獳s Integrat敤 Cir捵ct C慲摳a

=
mr潸imity=C慲摳
=
fpl/fbC=ㄴ㐴3
=
q桩猠獴慮摡r
搠桡d=f潵r=p慲as
=



T桥r攠er攠畮eik敬y t漠扥 慮y furt桥r 灡rts cr敡t敤.

ISO/IEC 㜸ㄶ P慲t猠4
-
9 扥捯浥c慰灬i捡cl攠
扥y潮搠d桥獥⁐慲ts i渠nh攠灲ot潣ol 捯cfigur慴楯n
k湯w渠慳n吽TL



ISO/IEC ㄴ㐴3
-
ㄺ㈰〰 I摥湴nfi捡瑩c渠捡r摳
-

C潮ta捴l敳e i湴ngrat敤 捩r捵ct(s) 捡r

-

Pr潸imity 捡牤猠
-

P慲t 1: P桹獩捡c
捨cr慣瑥ri獴i捳

T桩猠灡rt 獵s灬敭敮ts th攠灨e獩捡c 捨cr慣瑥ri獴i捳
摥fi湥搠楮 ISO/IEC

㜸㄰
.
A獳sm敳 t桡t ID
-
1 捡牤猠
will 扥 畳u搮



ISO/IEC ㄴ㐴3
-
㈺㈰〱 I摥湴nfi捡瑩c渠捡r摳
-

C潮ta捴l敳e i湴ngrat敤 捩r捵ct(s) 捡r摳
-

Pr潸imity 捡牤猠
-

P慲t 2: R慤i漠freq略湣n
灯w敲e慮搠獩d湡l int敲f慣e

T桩猠灡rt 摥fi湥s t桥 r慤i漠freq略湣n i湴敲f慣a, 慮搠
捯ct慩湳ntw漠o畩te 摩ffere湴nm潤畬慴楯渠t散e湩q略s
(Ty灥猠A 慮搠d) f潲 摡ta 捯cm畮i捡瑩cn 扥tw敥渠
捡牤c慮d termi湡l
.



ISO/IEC ㄴ㐴
3
-
㌺㈰〱 I摥湴nfi捡瑩c渠捡r摳
-

C潮ta捴l敳e i湴ngrat敤 捩r捵ct(s) 捡r摳
-

Pr潸imity 捡牤猠
-

P慲t 3: I湩ti慬i獡瑩s渠慮搠
慮ti
-
捯cli獩潮

T桩猠灡rt 捯cti湵敳et桥 呹灥 A 慮搠Ty灥 B
摵潰潬y, 摥fi湩ng c慲a i湩ti慬i獡瑩s測n慮ti
-
捯cli獩潮
灲潣敤pr敳 慮搠扡獩挠捯mmu
湩捡ti潮猠灲潴潣潬s
.



ISO/IEC ㄴ㐴3
-
㐺㈰〱 I摥湴nfi捡瑩c渠捡r摳
-

C潮ta捴l敳e i湴ngrat敤 捩r捵ct(s) 捡r摳
-

Pr潸imity 捡牤猠
-

P慲t 4: Tra湳浩獳n潮
灲潴潣ols

T桩猠捯ct慩湳⁨ng桥r l敶敬 (m敳獡g攠汥v敬) 摡ta
tr慮smi獳s潮 灲pt潣ol inf潲oati潮, eq畩v慬敮t t漠
ISO/IEC 7816’s T=1 protocol, and is a bridge
慣牯獳=to=fpl=㜸ㄶ
-
4
K==
c潲oqy灥=A=捡r摳d潮lyI=
fpl/fbC
=
ㄴ㐴1
-
㐠楮捬畤e猠愠ar潴潣潬=i湩ti慬i獡瑩s渠
灲潣敤pre
K==
=
bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




Standard or Specif
ication

Comments

Contactless Integrated Circuit Cards

=
si捩湩ty=
捡牤c
=
fpl/fbC=ㄵ㘹3
=
q桩猠獴慮摡r搠桡d=thr敥=f潲o慬=p
arts
=
k潴or敬敶慮t=t漠t桥=kpCm=

=
li獴敤=f潲=捯m灬整敮e獳
=


ISO/IEC

ㄵ㘹1
-
ㄺ㈰〰 I摥湴nfi捡瑩c渠捡r摳
-

C潮ta捴l敳e i湴ngrat敤 捩r捵ct(s) 捡r摳
-

Vi捩湩ty 捡牤猠
-

P慲a ㄺ P桹獩捡c
捨cr慣瑥ri獴i捳

T桩猠灡rt 獵s灬敭敮ts th攠灨e獩捡c 捨cr慣瑥ri獴i捳
摥fi湥搠楮 I
SO/IEC

㜸㄰
.
A獳sm敳 t桡t ID
-
1 捡牤猠
will 扥 畳u搮



ISO.IEC

ㄵ㘹1
-
㈺㈰〰 I摥湴nfi捡瑩c渠捡r摳
-

C潮ta捴l敳e i湴ngrat敤 捩r捵ct(s) 捡r摳
-

Vi捩湩ty 捡牤猠
-

P慲a ㈺ Air i湴nrf慣a 慮搠
i湩ti慬i獡瑩sn




ISO/IEC

ㄵ㘹1
-
㌺㈰〱 I摥湴nfi捡瑩c渠捡r摳
-

C潮ta捴l敳e i
湴ngrat敤 捩r捵ct(s) 捡r摳
-

Vi捩湩ty 捡牤猠
-

P慲a ㌺ Pr潴潣潬s




ISO/IEC ㄵ㘹3
-
4

I摥ntifi捡瑩c渠捡r摳d
C潮t慣瑬a獳 i湴ngrat敤 捩r捵ct(s) 捡牤c
-

Vi捩湩ty 捡牤猠
-

P慲a 㐺 R敧i獴r慴楯n of
慰灬i捡瑩c湳⽩獳n敲e.

I渠摥n敬潰m敮t

T敳t m整桯e猠f潲 i摥湴nfi捡瑩c渠
捡r摳

ISO/IEC ㄰㌷3

T桩猠獴慮摡r搠桡d 㜠灡rts




T敳t m整桯e猠req畩r敤 to 敳瑡扬i獨⁣潮f潲m慮捥
wit栠h桥 req畩rem敮t猠of t桥 扡獥 st慮摡r摳 慲a
捯cl散瑥搠toget桥r i渠t桩猠m畬ti
-
灡rt 獴慮摡rd
.

䱩ttl攠e敬敶慮捥⁴o NSCP 慮搠獥t 摯w渠桥ne for
捯浰c整敮敳e



ISO
/IEC ㄰㌷3
-
ㄺㄹ㤸 I摥湴nfi捡瑩c渠捡r摳
-

T敳t m整桯e猠
-

Part ㄺ G敮敲慬
捨cr慣瑥ri獴i捳 t敳ts




ISO/IEC

㄰㌷1
-
㈺ㄹ㤸 I摥湴nfi捡瑩c渠捡r摳
-

T敳t m整桯e猠
-

Part ㈺ C慲摳awit栠
mag湥tic 獴ri灥s




ISO/IEC

㄰㌷1
-
㌺㈰〱 I摥湴nfi捡瑩c渠捡r摳
-

T敳t m整桯e猠
-

Part

㌺ I湴ngrat敤
捩r捵ct(s) 捡r摳 wit栠捯湴慣瑳a慮d r敬at敤
i湴敲f慣a 摥vi捥c




ISO/IEC

㄰㌷1
-
㐠I摥ntifi捡瑩c渠捡r摳d
-

T敳t m整桯e猠
-

C潮t慣瑬敳猠楮te杲慴敤
捩r捵ct(s) 捡r摳
-

P慲a 4: Cl潳o 捯c灬敤
捡牤c

N潴o慶慩l慢le



ISO/IEC

㄰㌷1
-
㔺ㄹ㤸 I摥湴nfi捡瑩c渠捡r

-

T敳t m整桯e猠
-

Part 㔺 O灴楣pl m敭潲o
捡牤c




ISO/IEC

㄰㌷1
-
㘺㈰〱 I摥湴nfi捡瑩c渠捡r摳
-

T敳t m整桯e猠
-

C潮t慣al敳猠楮tegrat敤
捩r捵ct(s) 捡r摳
-

P慲a 6: Pr潸imity 捡牤c


bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




Standard or Specif
ication

Comments



ISO/IEC ㄰㌷3
-
㜺㈰〱 I摥湴nfi捡瑩c渠捡r摳
-

T敳t m整桯e猠
-

C潮t慣al敳猠楮tegra
t敤
捩r捵ct(s) 捡r摳
-

P慲a 6: Vi捩湩ty 捡牤c


CCID: U湩v敲獡e S敲楡l B畳⁄uvi捥⁃c慳猠
S灥捩fi捡ti潮 for USB Chi瀯卭慲t C慲搠
I湴nrf慣a D敶i捥猬cR敶 ㄮ〰1 M慲捨a㈰〱

T桩猠is 愠
de facto

standard from the USB
Implementers Forum

At
www.usb.org

and search on CCID

Global Platform

GP is a mid
-
level set of specifications for
cards and terminals, allowing multiple card
platform types but producing a common
application level environment
.

Global Platform is an industry consortium
drawn
from the
smart card

and financial sectors
. Ma
inly

i
ts mission is to define an open
smart card

infrastructure
.
http://www.globalplatform.org

GP has options, so procurement needs to carefully
specify the
requirement
.
Typically, an implementer
will use JavaCard platforms or Multos platforms

NIST IR 6887

=
㈰〳=Es㈮㄰O=d潶敲em敮t=
pm慲t=C慲a=fnt敲潰er慢ility=p灥捩fi捡瑩cn=s㈮O=
E䩵gy=㈰〳))
=
A捣数t敤=i湴n=t桥=pCㄷ=w潲o=灲p杲gmme
=
=
A=o数潲o=捯ct慩湩ng=a=摲aft=s
灥捩fi捡瑩cn=for=慮=潮
-
捡牤c慰灬i捡瑩c渠t漠桯l搠d敲獯湡e=摡taI=灬畳⁡渠Amf=
wit桩渠n桥=t敲mi湡l=慮搠dr潶i獩潮=for=i湴nr潰敲慢elity=
慣牯獳=獥s敲慬=捡牤=灬慴f潲o=ty灥s
K==
qy灩捡clyI=慮=
im灬敭敮eer=will=畳u=䩡癡C慲搠灬慴f潲m猠or=j畬t潳o
灬慴f潲msK
=
桴hp://獭art捡牤K湩獴Kg潶
=
=
k潴o慬l=潦=t桥=慢潶攠桡v攠摩r散琠r敬敶慮捥ct漠t桥=
k慴楯湡l=pm慲a=C慲a=mr潪散t
K==
q桥=k敹=
r敬敶慮t=r敬慴楯湳ni灳⁡r攠獨潷渠楮=t桥=摩a杲慭=扥low
⸠K
=
=
=
=
Cl敡rly=t桥=敮try=灯i湴nwill=扥=t桥=r敬ev慮t=潶敲慲
捨c湧=i獳略猠摥t慩l敤=i渠獥捴楯渠㔠of=t桩s=
灡灥p
K==
=
Overarching
Standards
Contact
Interface
Contactless
Interface
ISO/IEC 7810
ISO/IEC 7811
ISO/IEC 7816
ISO/IEC 14443
ISO/IEC 7816
Parts 4
-
9
Other
Overarching
Standards
Contact
Interface
Contactless
Interface
ISO/IEC 7810
ISO/IEC 7811
ISO/IEC 7816
ISO/IEC 14443
ISO/IEC 7816
Parts 4
-
9
Other
bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013





In the case of contact cards, the interface may be the standard ISO/IEC 7816
-
3 interface or
the draft ISO/IEC 7816
-
12 and CCID specification USB interface
.
At this time cards
produced with USB interface
s also have 7816
-
3 interfaces
.
There is no conflict among the
contact pads since the USB interface uses the two hitherto unused contact pads (C4, C8).


In the case of contactless cards, the proximity interface specification is assumed in which
case ISO 14
443 applies
.
There are then choices in that either ISO/IEC 7816 Parts 4
-
9 will
apply (the T=CL interface specification) or some other interface specification will apply, such
as Mifare
.
It
would be wise to

adopt

T=CL
but this will be determined by
the implementer.


The Proximity contactless standard offers two considerably different technologies, various
other options
.
This,

coupled with its immaturity and that of the associated test sta
ndard
10373
-
6, make its use in specifying a scheme complex
.

bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




7.2

Application Level Standards

These standards and references are categorised as application level but extend beyond
simple applications and are listed here as a single category due their relevan
ce to
applications.


Category

Sub
-
category

Reference Standards and Commentary

User interface

Best Practice
Manual

eESC 2002 OSCIE Vol 2
-

User Requirements Best Practice
Manual

www.eeurope
-
smartcards.org

RNIB Guidelines

Contact RNIB for advice and documents

Terminals:
special needs
configuration

EN1332 (particularly Part 4): Data specifying required
configuration of user interface of terminal

eURI
-

CWA 13987:2003 Application that acts as carrier f
or
personal information of the type that a card holder would
otherwise type in at a terminal, and also as a carrier of
special needs interface parameters (references EN 1332
-
4)

Supports citizen account, profile and preferences

Transport
ticketing and
rel
ated
ticketing areas

Transport
ticketing and
similar methods
for citizen
services

ITSO specification and related support service specifications
-

requires ISO/IEC 14443 as a prerequisite
.

IOPTA (CEN TC224 WG11): expected standardisation end
2004
.
Car
d application standard for transport underlying an
application specification such as ITSO
.
ITSO convergence
is expected when the standard is completed
.

IFM (CEN TC 278 WG3): Interoperable fare management
(back office), not yet complete, expected 2004
.

Data elements

EN 1545 (successor to ENV 1545): Data elements (CD
drafts only), being followed by ITSO.

Data transfer at
network level: e
-
GIF

e
-
GIF stable part is XML for data transfer between systems
.
For smart cards, e
-
GIF info is likely to remain

preliminary for
at least another year
.

Travel
documents


ICAO Doc 9303 (ISO 7501)
.
Specification for inclusion of
contactless IC in preparation.

(USA Patriot Act requires biometric authentication and
progressive introduction of electronically readable

travel
documents in the period up to 2007
.
ICAO leading
development)

Finance sector

Payment:
debit/credit, and
possibly pre
-
authorised debit
as pseudo e
-
purse

EMV: Basic payment system specifications for credit/debit
using smart cards
.
Includes type ap
proval methods and
specifications.

EMV separates approval of card platforms and approval of
terminal equipment
.
Within terminal equipment, Level 1
approval is for the terminal platform and Level 2 is for the
business application
.
Approvals managed by EMV
Co.

bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




Category

Sub
-
category

Reference Standards and Commentary

e
-
purse


CEPS is banking spec for proposed interoperable accounted
e
-
purse schemes
.

CEPS is managed by CEPSCo, and is derived from EN
1546 (Inter
-
sector electronic purse).

Proton is a private sector, established accounted e
-
purse
method for an e
-
purse interoperable across a single country.

Security

ISO 10202: Financial transaction cards
-

security
architecture of financial transaction systems using ICC

Messages

ISO 9992: Financial transaction cards
-

messages between
card and device

ISO 8583
-
1:2003 Financial transaction cards

=
i湴敲捨慮g攠
m敳獡ge=獰s捩fi捡瑩cn
=
r獥f=Aqjs
=
Ap=㌷㘹:=Aut潭oti挠t敬l敲em慣ai湥猠

=
畳ur=慣捥s猠Elittle=
r敬敶慮捥⁴漠乓Cm)
=
fpl/fbC=㤵㘴=m慲t猠1
-
3=mfk=m慮agem敮t=慮d=獥捵物瑹=for=
潮li湥=t敲mi湡ls
=
f摥湴nfi捡ti潮=of=
fin
慮捩慬=
tr慮獡sti潮=捡r摳
=
fpl/fbC=㜸ㄶ
-
3
=
rh=e
-
d潶
=
a慴愠form慴a=慮搠
獭慲t=捡牤=
req畩r敭敮ts
=
e
-
dfc
=
e
-
df䘠ct慢l攠灡rt=獰s捩fi敳euj䰠ior=摡t愠tr慮sfer=扥tw敥渠
獹獴敭献
=
䙯r=
sm慲t=捡牤
sI=e
-
df䘠cnf漠楳ok敬y=t漠r敭慩n=灲plimi湡ry=for=
慴al敡獴=慮ot桥r=y敡rK
=
啋r
灯li捹
=
-
=
l故=灯li捹=摯捵浥cts
=
-
=
獥捵rity=摯捵m敮ts=潮=l故=w敢=獩te
=
p散erity
=
E獥s=慬獯=
獥s慲慴e=
p散erity=
獥捴楯渠扥n潷)
=
d敮敲慬=灯li捹=i猠
r散emm敮摥d=批=
aqf=扵t=
灲潭畬g慴敤=批=
t桥=C慢i湥t=lffi捥=
=
e
-
df䘠汩獴s=fpl/fbC=㜸ㄶ=i渠n桥=獥捵rity=獥捴楯n=b散e畳u=
㜸T
㘠Six敳⁳散erity=慮搠扡獩挠f畮cti潮慬=mat敲楡lK
=
p敥=Cbpd=灡灥r猠潮=d潶t慬k=獩te=for=獥捵rity=gui摡湣n=
=
p敥=C慢i湥t=lffi捥⁰慰cr猠潮=l故=獩te=re=灯li捹=
=
mr潴散ti潮=
mrofil敳
=
=
=
mr潴散ti潮=mrofil敳=Emm猩:=p灥捩fy=t桥=f畮捴i潮慬=a湤=獥捵rity=
t敳瑳=to=扥=捡cri
敤=潵t=潮=捡牤=灬慴form献
=
Av慩l慢l攠eor=獥s敲慬=捯mm潮=捯cfigur慴楯湳=of=獭慲t=捡牤=
灬慴f潲msI=i湣n畤i湧=wit栠獯ftw慲攠慬r敡摹=l潡摥搮
=
b畲潰敡渠dl潢慬=
f湴nr潰敲慢elity=
䙲慭敷潲k=Edf䘩
=
䙯畮搠慴=故pC=㈰〲=lpCfb=s潬=3
=
A=m潤敬li湧=數敲捩獥=for=愠f畬ly=i湴敲o
灥r慢l攠獥s=of=
慵t桥湴楣nti潮I=敬散tr潮ic=獩g湡t畲u=慮d=潴桥r=獥s畲攠
獥牶i捥猠c桡t=捡c=慣捥pt=捡牤猠from=愠污rge=湵mb敲eof=
獥捵rityK
=
bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




Category

Sub
-
category

Reference Standards and Commentary

Data encoding
and formatting

Natural language
encoding
methods

ISO 10646 (UNICODE)

This general standard allows for encodi
ng of multiple natural
languages, and it is recommended that it is used for
encoding personal data where services are to be provided
across national borders (including registering citizens of
another country for UK services).

Data structure
and data obje
ct
definition

Abstract Syntax Notation One (ASN.1)

ISO/IEC 8824 Specification of ASN.1

ISO/IEC 8825 Specification for Basic Encoding Rules for
ASN.1

Data elements for
surface transport

ENV (and soon EN) 1545

See transport ticketing application section a
bove

Identification of
standard,
specification or
other object

Object Identifier (OID), formatted and coded as defined in
ISO/IEC 8824

European root numbering at CEN

Identification of
organisations

ISO/IEC 6523, Codes for the Identification of Organis
ations
.

Off
-
card
management
systems

Mid
-
level
specifications
between card
platform and
business
application

Global Platform (GP) defines the mid
-
level card platform
methodology, particularly applicable to JavaCard platforms
with the Visa Open Platform m
anagement application, and to
MULTOS platforms (which have management functions
included in the OS).

GP provides a method for detecting card platform type and
version.

Use the
provisions of
Global Platform

By providing support for JavaCards with the Visa

Open
Platform on
-
card manager and for the MULTOS built
-
in on
-
card management functions, GP partly provides a common
methodology for on
-
card application
load/delete/enable/disable, but agreement on security details
is not yet complete.


7.3

Security

The detai
led description included here is thought necessary by way of background
information concerning the following sections, including some insight as to why standards in
this area are still fluid.


There are two main classes of cryptographic techniques used in
smart cards and related
systems:




Symmetric or secret key

Here the same key is used for encryption and decryption
.
The most commonly used
system of this type is DES (Data Encryption Standard), developed by IBM in the 1970s
and a USA Federal Standard (FIPS

46) since 1976
.
DES is widely used for encrypting
information in the financial services sector
.
Now, with increasing computing power
bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




available at low cost, the United States government has approved a better symmetric
system
-

Advanced Encryption System
(AES).




Asymmetric, or public key

This uses two keys: one key to encrypt a message and a different (but related) key to
decrypt the message
.
One key remains secret, while the other is publicly available
.
The
best known and most commonly used techniques a
re in the RSA (Rivest, Shamir and
Adleman) group, but elliptic curve cryptography is gaining prominence in some areas.


The major repository of
de facto
(industry) security standards used in smart cards is at RSA
Laboratories
.
They specialise in asymmetri
c or public key cryptography developed from the
original work by Rivest, Shamir and Adleman in the 1977
.
Their reference documents are
the numbered PKCS (Public
-
Key Cryptography Standards) series
.
These not only underpin
RSA’s own products, but also enco
mpass other techniques, for example elliptic curve
.
However, the major developer of elliptic curve techniques is Certicom Corp, a Canadian
company, and they publish their own documents as well as contributing to the RSA series of
industry standards
.


Of

the PKCS series of specifications produced by RSA Labs, PKCS #11 is the one most
quoted


it is in fact the definition, in the C++ programming language, of an API (Application
Programming Interface), called Cryptoki, for use by an application requiring cr
yptographic
services
.
The API provides a common way for the application to connect to a device that
holds cryptographic information and performs cryptographic functions
.
Typically, an
application within a PC obtains cryptographic services from a smart ca
rd inserted in a
reader/writer connected to the PC, but PKCS #11 is written in a general manner, so that, for
example, the cryptographic service could be provided by a remote server
.
The applicability
of PKCS #11 is more general in another sense: it is no
t just a way to gain access to RSA
functions, but can support numerous other cryptographic techniques.


Having an API within a PC is just the beginning
.
If we decide to have a common method of
holding and using the citizen’s digital signature within one c
ountry or across Europe, we
need common methods for storage of that signature and for using it
.
Here the Americans
have again moved first, and RSA Labs developed PKCS #15; reference must also be made
to ISO 7816
-
8 and

9, and the new 7816
-
15
.
At the mome
nt, 7816
-
15 is awaiting the final
ballot decision, and practitioners are not yet decided on the choice between PKCS#15 and
7816
-
15.


In symmetric techniques, DES, originally developed by IBM, is described in US ANSI X3.92
and NIST/NBS FIPS 46
-
2
.
It uses a

56 bit key
.
Triple
-
DES, as its name implies, is a group
of methods for encrypting three times with the DES algorithm (see ANSI X9.52 and the FAQ
from RSA)
.
FIPS 46 is expected on the one hand soon be replaced by the new AES
(Advanced Encryption System),

but on the other hand is being updated to FIPS 46
-
3 with the
addition of Triple DES.


Elliptic curve cryptography has been adopted by the GSM mobile phone community, but as
yet is not widely used in the financial sector


although that is changing
.
In 19
99 elliptic
curve gained ANSI recognition (X9.62) for digital signature use, and in this mode it has the
ability to provide higher throughput than RSA
.
Therefore elliptic curve is now expected to be
adopted in financial applications as well as for general

user authentication, and tokens in the
form of smart cards are being offered by Certicom ‘to address the business needs for
personal and enterprise wide identification and authentication services’
.

bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013








Two other techniques deserve a mention:



The Digital

Signature Algorithm (DSA) is a public key technique for signatures only



The Diffie
-
Hellman key agreement protocol is a public key technique for distributing
secret keys over an insecure channel


Since a small group of mathematical concepts underpin most o
f the cryptography used in
smart cards and associated message systems, there is considerable overlap between the
contents of standards and specifications issued by various organisations
.



Standard or Specification

Comments

Security Policy

ISO/IEC 17799
:2000 (BS 7799)

Information Technology

=
C潤攠ef=灲p捴i捥=for=
i湦ormati潮=獥捵rity=m慮慧em敮t
=
Bp=㜷㤹=m慲t猠1=慮d=㈠Or攠t桥=pr散er獯r=
of=ㄷ㜹9I=慬t桯ugh=獯me=of=Bp=㜷㤹=
E灡rti捵c慲汹=m慲a=O)=r敭ei湳⁶慬id
=
bv慬畡ti潮=捲it敲楡
=
fpl/fbC=ㄵ㐰U
=
q桩猠獴慮摡r搠d
慳=thr敥=灡rts
=
q桥=獴慮摡r搠扥桩湤=t桥=C潭o潮=Criteri愠
獭慲t=捡牤=獥捵rity=敶慬u慴楯渠net桯搮
=
a潷nl潡摳⁡湤dfurt桥r=inf潲m慴楯渠
慶慩l慢l攠慴=
wwwK捯浭o湣物瑥ni愮arg

=
fpl/fbC=ㄵ㐰U
-
ㄺㄹ㤹=fnf潲m慴楯渠t散e湯logy=

=
p散erity=t散e湩q略猠

=
bv慬畡ti潮=捲iteri愠for=fq=
獥捵rity
-
=
m慲t=ㄺ=fntr潤畣ti潮=慮搠g敮er慬=m潤敬
=
=
fpl/fbC=ㄵ㐰U
-
㈺ㄹ㤹=fnf潲m慴楯渠t散e湯logy=

=
p散erity=t散e湩q略猠

=
bv慬畡ti潮=捲iteri愠for=fq=
獥捵rity
-
=
m慲t=㈺=p散erity=f畮cti潮慬=req畩rem敮ts
=
=
fpl/fb
C=ㄵ㐰U
-
㌺ㄹ㤹=fnf潲m慴楯渠t散e湯logy=

=
p散erity=t散e湩q略猠

=
bv慬畡ti潮=捲iteri愠for=fq=
獥捵rity
-
=
m慲t=㌺=p散erity=慳獵r慮捥creq畩r敭敮ts
=
=
q桥=rp=k慴楯湡l=fn獴itute=for=pt慮摡r摳=慮搠
q散e湯logy=Ekfp吩qi獳略猠rp=f敤er慬=st慮摡rd猺
=
=


䙉偓 㐶
-
2 D慴a E湣特灴
i潮 St慮摡rd (DES)
(
FIPS 46
-
3 in preparation
)



䙉偓 㜴 G畩摥li湥猠(
use with FIPS 81
)



䙉偓 㠱 DES M潤敳f O灥rati潮



䙉偓 ㄱ㌠䍯m灵ter Dat愠䅵瑨敮ti捡瑩c渠



䙉偓 ㄴ0
-
1 S散erity R敱畩r敭敮es f潲
Cry灴潧ra灨i挠M潤畬敳



䙉偓 ㄷㄠ䭥1 m慮ag敭敮t U獩ng ANSI X㤮ㄷ




PS ㄸ0
-
1 S散ere H慳a St慮摡rd



䙉偓 ㄸ6
-
1 Digit慬 Sig湡t畲u St慮摡rd



bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




Standard or Specification

Comments

The American National Standards Institute (ANSI)

The American National Standards Institute
has been very active in this field, with
many security related standards under the
control of
Accredited Standards
Committee X9 : Financial Services.



ANSI X3.㤲

=
ㄹ㠱=a慴a=b湣特灴楯渠䅬gorithm=
Et桥=慬gorithm=f潲=abp)
=


ANSI X3.㄰6

=
ㄹ㠳=jo摥猠of=abA=l灥rati潮
=


ANSI X9.8

=
ㄹ㤵=m敲獯湡l=f摥湴nfi捡ti潮=
k畭扥爠Emfk)=j慮慧敭敮t=慮d=p散erity=
=


ANSI X9.9

=
ㄹ㠶=䙩湡湣n慬=f湳瑩瑵ti潮=j敳獡ge=
A畴桥湴楣uti潮=Eth潬敳el攩eE
based on DES
)



ANSI X9.ㄵ S灥捩fi捡瑩c渠for 䙩湡湣n慬 M敳獡g攠
E捨c湧攠䉥瑷敥渠䍡rd A捣数tor 慮d Acq畩rer



ANSI X9.ㄹ 䙩湡湣n慬 I湳tit畴楯渠剥t慩l M敳獡g攠
A畴桥湴楣uti潮 (
related to X9.9 and t
o ISO 9807
)



ANSI X9.㈴

=
ㄹ㤸=䙩湡湣n慬=p敲ei捥猠co整慩lz=
h敹=j慮慧敭敮e=r獩ng=t桥=abA
=


ANSI X9.㌰

=
ㄹ㤷=m畢li挠h敹=Cry灴潧p慰桹=
r獩湧=frr敶敲獩el攠䅬g潲楴桭猺=m慲t=1=q桥=aigit慬=
pig湡tur攠䅬g潲楴om=EapA);=mart=㈠q桥=p散ere=
e慳a=Algorit桭=EpeA)=
=


ANSI X9.5
2 Tri灬攠䑡ta E湣特灴楯渠䅬g潲ot桭
M潤敳e O灥r慴楯渠(
Triple DES
)



ANSI X9.㘲

=
ㄹ㤸=m畢li挠h敹=Cry灴潧p慰桹=f潲=
t桥=䙩湡湣n慬=p敲ei捥猠cn摵獴ryI=q桥=blli灴楣p
C畲u攠䑩git慬=pig湡t畲u=Alg潲楴om=EbCapA)
=


ANSI X9/呇
-
9 A扳br慣a Sy湴慸 N潴慴i潮 慮搠
E湣n摩湧 R畬
敳ef潲 䙩湡湣n慬 I湤畳ury St慮摡rd猠



ANSI X9.㐲 (K敹 agr敥m敮t 灲pt潣ol 扡獥s 潮
Diffie
-

H敬lm慮)




ANSI X㤮㐴 (K敹 慧r敥m敮t 灲pt潣ol 扡獥s 潮
剓䄩



PKCS S敲楥猠fr潭 RSA 䱡扳b

RSA 䱡扳⁷敢 獩t敳⁰rovi摥 愠睩摥 r慮ge
of 獥捵rity
-
r敬慴敤 inform慴楯渠獵捨

慳a
獰s捩fi捡瑩c湳n 灲潤畣ts, 灲敳猠r敬敡獥猠
慮搠敶敮t informati潮
.
周敩r mi獳s潮
i湣n畤敳†灲潤畣pn朠捡gef畬ly writt敮
摯捵浥湴猠摥獣ri扩湧 th攠獴慮摡r摳⁡湤
獰s捩fi捡瑩c湳nf潲 捲y灴p杲慰桩挠
t散e湩q略猬 慳⁷敬l 慳⁳aftw慲攠灲潤p捴s
t漠業灬em敮t t桯獥 t散
h湩q略s
.
T桥
f潬l潷i湧 li獴 i湣n畤敳e灵扬i獨s搠楮摵獴ry
bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




Standard or Specification

Comments

standards and items under development



PKCS ⌱ RSA Cry灴潧pa灨y St慮摡rd



PKCS ⌳ Diffie
-
H敬lm慮 K敹 Agr敥m敮t
St慮摡rd



PKCS ⌱ㄠ䍲1灴潧p慰桩挠Tok敮 Int敲f慣a
St慮摡rd



PKCS ⌱㌠䕬li灴楣⁃prv攠䍲e灴潧r
a灨y St慮摡rd



PKCS ⌱㐠偳敵摯r慮摯m Num扥r G敮er慴楯n
St慮摡rd



PKCS ⌱㔠䍲5灴潧p慰桩挠Tok敮 Inf潲m慴楯渠
䙯rmat St慮摡rd



CEN/ISSS Wor歳桯瀠p杲敥浥gt猠(CWA)

S潭攠of t桥獥⁨慶攠扥e渠n慤e
m慮摡tory t桲潵gh E畲u灥慮 Dir散瑩e敳e
(獥s 獥捴i潮 5.ㄮ1)



CWA ㄴ㌵㔠
G畩摥li湥猠f潲ot桥 im灬em敮tati潮 of
獥捵r攠獩g湡t畲u
-
Cr敡ti潮 D敶i捥c



CWA ㄴㄷ〠卥捵rity R敱畩rem敮t猠f潲
Sig湡tur攠䍲敡ti潮 Sy獴ems



CWA ㄴㄶ㤠卥捵r攠卩gn慴畲e
-
捲敡ti潮 摥vi捥猬c
v敲獩e渠nEA䰠㐫'



CWA ㄴㄶ㠠卥捵r攠卩gn慴畲e
-
Cr敡ti潮 D敶i捥猬c
v敲獩e渠nEA䰠㐧



CWA ㄴㄶ㜠卥捵rity R敱畩rem敮t猠f潲
Tru獴w潲o桹 Sy獴敭e Ma湡ging Certifi捡t敳ef潲
El散瑲潮i挠Sig湡tur敳

P慲a 1: Sy獴em S散erity R敱畩rem敮ts

P慲a 2: Cry灴潧p慰桩挠M潤畬攠f潲 CSP Sig湩n朠
O灥rati潮猠

=
mrot散瑩e渠mrofil攠ejCpl
-
偐m
=
=
=
7.4

Terminals


Category

Refe
rence to Standard and Comments

PC

eURI and EN 1332
-
4 provide the parameter
definitions that will allow a suitably modified
browser and an eURI on
-
card app to deliver
special needs configuring of PCs used as
network terminals.

bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




API for use in PCs

OCF, PC/
SC, MUSCLE are in current use, but
are not fully supported or fully modular, and do
not easily handle multiple card platform types
.

NIST GSC
-
IS has the best API (including
support of multiple card platform types, within
certain boundaries)

USB tokens

Interface to secure tokens using USB is in a
new part of ISO/IEC 7816 (7816
-
12)

Secure tokens may be in a form of units or
‘blobs’ with a USB connector, or may be ID
-

捡牤猠u獩湧=t桥=獰sr攠捯湴慣ns=i渠t桥=㜸ㄶ=
捯浰ci慮t=捯ct慣t=ar敡=t潧et桥r=wit栠愠灡獳sv

慤慰t敲=to=t桥=rpB=捯cn散瑯e=formatK
=
䙉乒bAa
=
=
CtAs=䙉乒bAa=慮d=bm扥摤敤=cfkobAa=

=
p散er攠t敲mi湡ls
=
C潮獯牴i畭=桡s=扥敮=f潲m敤=E䙉乒bAa=gr潵pI=
pqfm=gr潵pI=dm)=to=摥v敬潰=灲pfili湧=Ef畮捴i潮慬I=
獥捵rity)=f潲=獥捵r攠t敲mi湡l献
=
r獥f=䙉乒bAa/pqfm/dm=met桯d
=
giv敳⁴桥=
灯獳s扩lity=潦=摥v敬潰i湧=v敲e=low=捯獴ctermi湡l=
敱畩灭敮t=獵st慢l攠f潲=u獥⁩s=愠扡a欠灡ym敮t=
敮vir潮m敮t=

=
扵t=bjs=桡猠獴ill=湯t=慰灲潶敤=
獵捨=愠met桯搬=慳⁩t=re煵ir敳e
-
li湥=tr慮獡捴i潮=
灲潣敳獩ngK
=
=
=
=
=
bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




8.

Recommended Use of Standards


The tabl
e below lists various
de facto

and
de jure

standards that should be reviewed before
implementation
.
It is for WP3 to decide upon whether to recommend or mandate their use in
interoperable Local Authority
smart card

schemes.



Standard

Comments

Underlying

Standards

These are generalised standards that will apply in all cases where
relevant

ISO 9000

Underlying quality assurance

e
-
GIF

OeE specification of recommendations
.
XML specification complete
but
smart card

specification of relevant standards as yet

incomplete
.
Nevertheless, it is important that implementers follow its guidelines

ISO 3166:1997

representation of names of countries

ISO 8601:2000

representation of dates and times

ISO 5218:1997

representation of human sexes

ISO 10646

alphabet for mu
lti
-
lingual use

ISO 639

representation of names of languages

ISO/IEC 7810:
2003

Identification cards

=
mhy獩捡c=捨cr慣瑥ai獴i捳I=摥fi湥猠t桥=faㄠ捡rd=
f潲m慴=w桩捨⁩猠慳獵c敤=for=扯t栠捯ht慣t=慮d=捯ct慣瑬a獳=捡牤s
=
故pC=㈰〲=lpCfb=s潬=O
=
r獥爠oeq畩rem敮ts=
B敳e=mr慣ti捥⁍慮畡l=
-
=
=
bkㄳ㌲
-
4
=
p灥捩慬=湥敤猠req畩reme湴猠獰s捩fi捡瑩cn
K==
f湣nrp潲慴敤=i渠ntA=
ㄳ㤸㜺㈰〳=敕of=E獥s=b敬ow)
=
fpl/fbC=㘵㈳
=
C潤敳efor=t桥=f摥湴nfi捡ti潮=of=lrg慮i獡瑩s湳
=
lfa=潲=ffk
=
o潯t=ref敲敮捥cf潲=畮iqu攠湵e扥ri湧=獣桥m敳=Efpl=㠸㈴=潲=fp
l/fbC=
㜸ㄲT
=
Contact Cards


ISO/IEC 7811
-
1:2002

Embossing
.
Not recommended for contactless cards but OK for
contact cards provided damage to the chip is avoided

ISO/IEC 7816 all parts

Some parts not relevant to specific uses

USB CCID , Rev 1.00:2001

On
ly where a USB interface is to be specified

Contactless Cards
-

Proximity


ISO/IEC 14443 all parts

Some argue that conformance with Part 4 is unnecessary
.
It is for
WP3 to decide but it is recommended that conformance with all parts
is specified

ISO/IE
C 7816 Parts 4
-
9

T=CL implementation to provide the maximum flexibility and
standardisation

Off
-
card Management
System


Global Platform

See Global Platform web site for latest versions

Citizen Account, Profile,
Preferences


CWA 13987:2003 eURI

Incorpor
ates EN1332
-
4 for special needs requirements profiling

Transport Ticketing


ITSO Specification all parts

The UK standard
.
It will incorporate new European standards as they
appear including EN1545, CEN TC224 WG11 IOPTA, CEN TC278
WG3 IFD

bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




Travel Documen
ts


ISO 7501 (ICAO Doc 9303)

The work of CEN TC224 WG15 on Citizen cards may incorporate
and/or reference this standard

Finance Sector


EMV specification

See www for latest specification
.
Conflicts with ISO/IEC 7816
resolved to the extent that they nee
d not be considered mutually
exclusive
.

Neither EMV nor ISO consider that there is any conflict.
EMV specifies a subset of 7816 which it is entitled to do, EMV being a
specification and ISO a standard.

ISO 10202

security architecture

-

Likely to be withd
rawn and not used by industry


ISO 9992

messages between card and device

-

Likely to be withdrawn and not
used by industry


Electronic money directive

Embodied in the UK by the FSA

=
慰灬i敳⁡m潮朠潴桥r=t桩湧s=t漠o
-
灵r獥s
=
fpl=㤵㘴=灡rts=1
-
4
=
B慮king=

=
m
敲獯湡e=f摥ntifi捡瑩c渠乵m扥r=Emfk)=m慮ag敭敮t=慮d=
獥捵rity
=
Security

The list below specifies standards to be used only where relevant
(until UK/
e
-
GIF

specifies)

ISO/IEC 17799:2000 (BS
7799)

Security Policy

ISO/IEC 15408 all parts

Evaluation criteria

C
EN/ISSS CWA 14167 all
parts

Managing certificates for electronic signatures

=
fr潭=敬散瑲o湩挠
獩g湡tur敳=摩r散瑩ee
=
Cbk/fppp=CtA=ㄴㄶ9
=
pig湡tur攠er敡ti潮=摥vic敳e

=
from=敬散tr潮ic=獩gn慴畲敳=摩r散tive
=
mhCp=⌱ㄠ
=
Cry灴潧ra灨i挠qok敮=fnt敲f慣a=pt慮摡rd
=
mhCp=⌱R
=
Cry灴潧ra灨i挠qok敮=fnf潲oati潮=䙯rmat=pt慮d慲d
=
=
=
Terminals

The use of terminal standards will clearly depend on the environment
and specific requirements

OCF

PC/SC

MUSCLE

PC support interfaces; OCF is an Open Card Forum Java interface,
PC/S
C is the Microsoft
smart card

reader interface and MUSCLE is
an open source interface designed for use with Linux

NIST GSC
-
IS

A PC support interface API from NIST reckoned to have the most
flexible support for multiple card types


FINREAD

Secure termina
l specification for terminals to be attached to PCs in a
finance sector environment
.
CEN/ISSS CWA

Embedded FINREAD

Secure terminal chipset for embedding into purpose
-
built terminals
.
CEN/ISSS CWA



The above list may be used as a shopping list
by
those wishing to adopt
smart card
s, leaving
it to them to decide upon which standards are relevant to them
.
Alternatively, it may be
decided that further refinement is necessary to support the requirement for interoperabili
ty
across Local Authority issued cards (National
Smart Card

Project WP3)
.
Examples of how
bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




this may be achieved are set down below
.
However, it must be emphasised that these are
just examples and not recommendations
.


Further work:

It is for
the successo
r to the National
Smart Card
Project to

decide upon actual
recommendations, if these are to be made.


Generic recommendations



EMV

being a specification building on the main base
smart card

standards,
although designed for the finance sector, for contact
sm
art card
s
adopting EMV could be a good move
.
It will guarantee interoperability
as well as access to a wide range of terminals in the public
marketplace.



Global Platform

for mid level card platform functionality and management
.
Although the flexibility w
ould allow non
-
interoperable schemes to be
set up, given political will, Global Platform will allow interoperable card
management capability to become a reality
.
The only real alternative
today is that being developed by ETSI (SCP), which is outside the
s
cope of this paper and its consideration, although given the volumes
of ETSI based chips involved, that decision may need to be reviewed.

Global platform are working closely with ANSI and NIST.


On
-
card application level recommendations



ITSO




for transp
ort ticketing



eURI




for accessibility issues



ISO/IEC 7816
-
15 (draft)


for PKI and related issues



CEN/ISSS CWA 14167


for electronic signature

CEN/ISSS CWA 14168

CEN/ISSS CWA 14169

CEN/ISSS CWA 14170

CEN/ISSS CWA 14355


Finally, it should be noted that C
EN TC224 WG15 Citizen Cards has started work and is
likely to complete its work end 2005/early 2006
.
Once this becomes a CEN standard, it will
have a significant effect on the recommendations for standards for use with Local Authority
cards
.
It is assume
d that if the NIST GCS
-
IS specification is adopted by ISO as a new Work
Item, the CEN TC224 WG15 group will work closely with the ISO group to arrive at a
common standard.

bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




9.

Outstanding Issues


From the work detailed in this paper, it is clear that many of
the required standards are not
yet fixed which will lead to uncertainty about how to move forward in an interoperable
manner while obeying standards and enabling new standards to be incorporated as they
arise
.
Indeed, it was for this reason that LASSeO wa
s created.


It is suggested that further work can be carried out as follows:



Formal standards bodies


encouraged to complete their work and, where
necessary, to work to resolve duplicate and conflicting standards
.
The UK to fully
support all relevant sta
ndards work, with resource where necessary.



De facto

standards bodies


encouraged to arrive at open solutions that do not
conflict with formal standards
.



CEN/ISSS


work with them to define and produce new CWAs to meet specifically
identified requiremen
ts and gaps
.
The UK to actively participate and provide
necessary resource requirements.



UK Government


specifically to be encouraged to take an agreed position on long
outstanding standards matters, for example an agreed UK standard for PKI



Office of th
e e
-
Envoy


to complete the e
-
GIF in terms of recommendations for the
use of standards in
smart card
s
.



LASSeO


to fill the gaps between existing standards and standards in development
or required, and the requirement to enable UK
-
wide interoperability w
ith open, multi
-
application
smart card
s in the public sector through the specification of policies and
rules.



Finance sector


to be encouraged to work in a multi
-
player environment
.
Without
payment facilities on multi
-
application local authority
smart ca
rd
s, their value will be
greatly diminished
.
In an open interoperable environment, finance sector supported
means of payment is essential


In addition to the above, it is to be noted that this paper is just a starting point
.
Technology
does not stay stil
l and standards continue to develop
.
Therefore, the recommended list of
standards, coupled with the policies and rules to fill the gaps, will require constant revision
and such a process needs to be designed and set up
.
It is suggested that LASSeO is the

right organisation to carry out this work, feeding the e
-
GIF with information about newly
developed
de facto

and
de jure

standards as they appear.













bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013





-
33
-


10.

Appendix 1


National Smart Card Project
Glossary



This Glossary is intended to help readers
to understand terms used in the National Smart Card Project publications. Its primarily purpose is to be useful in
this context rather than a precise set of definitions.

Numeric


3G
-


Third generation mobile telecommunications technology

A


Act
iveX
-


A loosely defined set of object
-
oriented programming technologies and tools developed by Microsoft. The main technology is the
Component Object Model (COM). ActiveX is Microsoft's answer to the Java technology from Sun Microsystems.

Algorithm
-


A sequence of steps used to perform a mathematical operation

ANSI
-

American National Standards Institute: Standardisation coordination body for the USA

API
-


Application Programming Interface: A set of routines, protocols (q.v.), and tools for buildin
g software applications (q.v.)

Applet
-


A program designed to be executed from within another application (q.v.). Unlike an application, applets cannot be executed d
irectly
from the operating system. On the Web, an applet is a small program that can be s
ent along with a Web page to a user. Java
applets can perform simple tasks without having to send a user request back to the server.

Application
-


A piece of software that performs business functions. It can reside on a smart card (q.v.)

Archiving
-


Copying data onto a backup storage device

ASN.1
-


Abstract Syntax Notation One: A language that defines the way data is sent across dissimilar communication systems

Asymmetric Cryptography
-


Cryptography (q.v.) using a Public Key/Private Key (q.v.) c
ombination

Authentication
-


A security process that verifies that a person seeking to use an application (q.v.) on a smart card (q.v.) is the person who
is entitled
to use it for the purpose intended

B


Biometrics
-


Biological authentication mechanis
m such as a fingerprint, iris, voice, facial dimensions

BIOS
-


Basic Input Output System: Built
-
in software that determines what a computer can do without accessing programmes from a disk

bit
-


Binary digit: The smallest unit of information on a machin
e. A single bit can hold only one of two values: 0 or 1. The term was first
used in 1949

Block
-


Action taken by an issuer to prevent the use of a card, or a particular application on a chip card

Bluetooth
-


A short
-
range radio technology aimed at simp
lifying communications among Internet (q.v.) devices and between devices and the
Internet

BSI
-


British Standards Institute: National Standards body for the UK responsible for facilitating, drafting, publishing and market
ing British
Standards

C


C++
-


One of the most popular high
-
level programming language for graphical applications

CA
-


Certificate Authority

q.v.

bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




Card
-
to
-
card
-


Transaction to transfer something (usually money) from one card to another

CAT
-


Cardholder Activated Terminal: A te
rminal that dispenses a product or service



CCID
-


Chip Card Interface Device: USB (q.v.) devices that interface with or act as interfaces with chip cards and smart cards

CDMA
-


Code Division Multiple Access: A generic term that describes the techno
logy on which a wireless air interface is based

CD
-
ROM
-


Compact Disc
-

Read Only Memory: A type of optical disk capable of storing large amounts of data. Once stamped by the vendor,
they cannot be erased and filled with new data

CEN
-


Comité Europée
n de Normalisation (European Committee for Standardisation): The only recognised European organisation for the
planning, drafting and adoption of European Standards, except for electrotechnology (see CENELEC q.v.) and telecommunications

(see ETSI q.v.)

CE
N/ISSS
-


Information Society Standardisation System: Provides market players with a comprehensive and integrated range of standardisa
tion
services and products, in order to contribute to the success of the Information Society in Europe

CENELEC
-


The Eu
ropean organisation for the planning, drafting and adoption of European Standards for electrotechnology

CEPS
-


Common Electronic Purse Specifications: Define requirements for all components needed by an organisation to implement a globa
lly
interoperable

electronic purse programme, while maintaining full accountability and auditability

Certificate Authority

A certificate authority (CA) is an authority in a network that issues and manages security credentials and public keys for me
ssage
encryption. As par
t of a public key infrastructure (PKI), a CA checks with a registration authority (RA) to verify information provided
by the requestor of a digital certificate. If the RA verifies the requestor's information, the CA can then issue a certificat
e

CESG
-


Co
mmunications
-
Electronics Security Group: The Information Assurance arm of the UK’s Government Communications
Headquarters (GCHQ)

Cipher Text
-


Text that has been encrypted (q.v. encryption)

CIPS
-


Chartered Institute of Purchasing and Supply: Private i
nternational education and qualification body representing purchasing and
supply chain professionals

CMS
-


Card Management System

Contact interface
-


A means for allowing the exchange of data between a smart card and a reader that requires the card to
be in physical contact with
the reader

Contactless interface
-


A means for allowing the exchange of data between a smart card and a reader without any physical contact between the card and

the reader

CRM
-


Customer Relationship Management

Cryptogram
-


Enables chip data exchange in a secure manner

Cryptographic Key
-


Used to encrypt or decrypt a message

Cryptography
-


The relationship between plain text and cipher text (q.v.) that prevents anyone other than the intended recipient from readin
g the

information

CVM
-


Cardholder Verification Method: The means to verify the authenticity of a cardholder

CWA

CEN Workshop Agreement: Published European consensus arising from CEN/ISSS workshops

Cyberspace
-


Networked computers/the Internet (q.v.)



bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




D


Decryption
-


The procedure used in cryptography (q.v.) for converting cipher text (q.v.) to plain text

DES
-


Data Encryption Standard: A popular encryption (q.v.) method developed in 1975 and standardized by ANSI (q.v.) in 1981

DfES
-


(Government
) Department for Education and Science (UK)

Digital Certificate
-


An electronic "credit card" that establishes your credentials when doing business or other transactions on the Internet (q.v.
). It is
issued by a Certificate Authority (q.v.)

Digital ID
-


Another name for a Digital Certificate (q.v.)

Digital Key
-


Strings of unique bits (q.v.) that allow messages to be scrambled and unscrambled

Digital Signature
-


A digital code that can be attached to an electronically transmitted message that uni
quely identifies the sender

DPA
-


Data Protection Act 1998 (UK)

Dual interface card
-


A smart card (q.v.) having both a contact (q.v.) and a contactless (q.v.) interface; see distinction with Hybrid card (q.v.)

E


e
-
cash
-


Electronic cash: Cash sto
red electronically and readily exchanged into monetary value

ECML
-


Electronic Commerce Modelling Language: A universal format for online commerce Web sites that contains customer information
that is used for purchases made online, formatted through the

use of XML (q.v.) tags (q.v.)

e
-
Commerce
-


Electronic commerce: Transactions that are conducted over an electronic network, where the purchaser and merchant are not at
the
same physical location

eESC
-


The eEurope Smart Card initiative: Launched by t
he European Commission in 1999 to accelerate and harmonise the development of
smart cards across Europe

EFTPOS
-


Electronic Fund Transfer at Point Of Sale: Usually a terminal

Electronic Wallet
-


Software that stores information about a cardholders car
ds. Usually supplied by the issuers and appended to the cardholders web
browser

e
-
mail
-


Electronic mail

Emboss
-


Print raised data on a card

EMV
-


Europay, MasterCard and Visa: A collaboration between these three organisations

EMVCo
-


An industr
y association of the collaborators in EMV (q.v.) for the banking and finance industry

Encryption
-


The procedure used in cryptography (q.v.) for converting plain text to cipher text (q.v.)

e
-
purse
-


Electronic purse: A function on a chip card that all
ows e
-
cash (q.v.) value to be stored

e
-
tailing
-


Electronic retail

ETSI
-


European Telecommunications Standardisation Institute: Not for profit organisation whose mission is to produce the
telecommunications standards for Europe (see also CEN q.v.)

eURI
-


Extended User
-
Related Information: Defined in CWA (q.v.) 13987 for Interoperable (q.v.) Citizen Services using Smart Card
(q.v.)Systems





bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




F

FINREAD
-


European specifications for an applet
-
based (q.v.) secure interoperable (q.v.) smart card (q.
v.) reader for online transactions
implying sensitive data transfers

FIPS
-


Federal Information Processing Standards: Standards and guidelines issued by NIST (q.v.)

G


Gateway
-


A node or switch that permits communications between two dissimilar netw
orks

GPRS
-


General Packet Radio Service: A standard for wireless communications which runs at speeds up to 115 kilobits per second,
compared with current GSM (q.v.)

GSC
-
IS
-


Government Smart Card
-
Interoperability Specification: Interoperability (q.v.
) specification for smart cards (q.v.) in the USA developed
by NIST (q.v.)

GSM
-


Global Systems for Mobile Communications: One of the leading digital cellular systems

H


Hash
-


Message digest. A number generated from a string of text

http
-


Hyper
Text Transfer Protocol: The underlying protocol used by the World Wide Web (q.v.)

Hybrid card
-


A smart card (q.v.) that contains two separate and unconnected chips, one with a contact interface (q.v.) and the other with
a
contactless interface (q.v.)

I



ICAO
-


International Civil Aviation Authority: A specialized agency of the United Nations, ICAO is the permanent body charged with t
he
administration of the principles laid out in the Convention on International Civil Aviation, Chicago, 7/12/1944

ICC

-


Integrated Circuit Card, or smart card (q.v.)

ICT
-

Information & Communications Technology

IDeA
-


Improvement and Development Agency (UK): Established by and for local government in April 1999 to support self
-
sustaining
improvement from within loca
l government

IEC
-


International Electrotechnical Commission: Global standards organisation for all electrical, electronic and related technolog
ies

IFM
-


Integrated Formal Methods: The rigorous engineering methodology for system development; a conceptu
al parallel to the industrial
standard UML (q.v.)

IIN
-


Issuer Identification Number: The numbering system that uniquely identifies a card issuing institution in an international in
terchange
environment, specified in ISO/IEC 7812

IKE
-


Internet Key Exc
hange

Integrity
-


Information that is free from error, corruption or alteration

Internet
-


A global collection of interconnected networks, used for the purpose of electronic communication

bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




Interoperability
-


The ability for different systems to wor
k together


Information Law Terms


See WP8
-
04 Appendix 1 for definitions of the following terms in context:

Data


Data Controller


DPA


Data Processor


Data Subject


DCA


E
-
Envoy Identity Guidelines


FOIA


HRA


LCD


Mandatory/Mandatory Smart C
ard
Scheme


Personal Data


Processing


Public Authority


Sensitive Personal Data


Intranet
-


A private network

IOPTA
-


"InterOperable PT Applications" for smart cards: A revision of CEN (q.v.) standard ENV1545 that defines the codification of d
ata

elements used for public transport

IP
-


Internet (q.v.) protocol: Specifies the format of packets, also called datagrams, and the addressing scheme

IR
-


Inland Revenue (UK)

ISO
-


International Standardisation Organisation: Body responsible for devel
opment of international standards covering a huge range of
issues

Issuer
-


A financial institution that establishes an account for a cardholder and issues a payment card

IT
-


Information Technology

ITSO
-


Formerly "Integrated Transport Smartcard Or
ganisation": Public sector membership organisation founded in 1998 to build and
maintain specifications for secure end
-
to
-
end interoperable ticketing operations in the UK


J


bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




Java
-


A high
-
level object
-
oriented programming language developed by Sun Mic
rosystems

Java Card
-


An ISO 7816
-
4 Compliant application (q.v.) environment focused on smart cards (q.v.)

K


Key Escrow
-


Storage of a private key (q.v.) by a neutral third party

Key Management
-


The process by which cryptographic keys (q.v.) and
messages are managed and protected

L


LA
-


Local Authority

LASSeO
-


Local Authority Smartcard Standards e
-
Service Organisation: Created by local government organisations in the UK to define at the
working level the necessary standards, rules and poli
cies needed to provide public services to citizens using smart cards

LDAP
-


Lightweight Directory Access Protocol: A set of protocols (q.v.) for accessing information directories. Because LDAP is an op
en
protocol, applications (q.v.) need not worry about

the type of server hosting the directory

LGOL
-


Local Government Online (UK): Internet (q.v.) portal to local government

Linux
-


A freely
-
distributable open source operating system that runs on a number of hardware platforms

LLPG
-


Local Land and Pr
operty Gaze
t
teer (UK): A definitive, local address list that provides unique identification of properties, conforms to
a British Standard, BS 7666 and feeds the National Land and Property Gazetteer

M


Magnetic Stripe Card
-


A card with a magnetic strip

of recording material on which data can be stored

MIFARE
-


A proprietary standard for contactless (q.v.) and dual interface (q.v.) smart cards (q.v.) produced by Philips Semiconductors

and
extensively deployed worldwide

MIME
-


Multipurpose Internet Mu
ltimedia Extension: An Internet (q.v.) protocol (q.v.) for sending e
-
mail (q.v.) and attachments

Mondex
-


An e
-
cash application for Smart
Cards

that stores value as electronic information on a microchip, rather than as physical notes and
coins enabling
cardholders to carry, store and spend cash



Multos
-


A smart card (q.v.) operating system for multi application cards

MUSCLE
-


Movement for the Use of Smart Cards in a Linux Environment: (q.v. Linux)

N


NBS
-


A global leader in card personalisati
on, payment solutions, and secure processing for financial institutions, healthcare, governments,
entertainment and retail customers

NIC
-


National Insurance Contributions

bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




NIST
-


National Institute of Standards and Technology (USA): Designs standards
and guidelines for Federal computer systems

Not
-
on
-
us
-


Transactions that are carried out in a smart card scheme where one of the parties to the transaction is not a member of the s
cheme

O


OCF
-


Open Card Framework: A Java (q.v.) API (q.v.) for smar
t card (q.v.) access

ODPM
-


Office of the Deputy Prime Minister (UK)

OeE
-


Office of the e
-
Envoy (UK): Part of the Delivery and Reform team based in the Cabinet Office whose purpose is to improve the
delivery of public services and achieve long
-
term co
st savings

OEM
-


Original Equipment Manufacturers: Misleading term for a company that has a special relationship with computer producers. OEMs

buy computers in bulk and customize them for a particular application

OID
-


Operator Identity: An ITSO (q.v.)

term for entities performing specified ITSO roles

Online
-


Jargon for the process of obtaining information through access via a computer or terminal to the source

Open systems
-


Systems whose architecture specifications are public. This includes offic
ially approved standards as well as privately designed
architectures whose specifications are made public by the designers

OS X
-


Computer operating system developed by Apple Computers

P


PC/SC
-


Personal Computer/Smart Card: A standard framework for

smart card (q.v.) access on Windows Platforms

PCMCIA
-


Personal Computer Memory Card International Association: An organisation consisting of some 500 companies that has developed
a standard for smart cards (q.v.). Originally designed for adding memory
to portable computers

PDA
-


Person Digital Assistant: A handheld device that combines computing, telephone/fax, Internet (q.v.) and networking features

PIN
-


Personal Identification Number

PIN Pad
-


A small keypad on which a cardholder keys in his/h
er PIN (q.v.)

PIN Verification
-


The security process that confirms the cardholder's PIN (q.v.)

PKCS
-


Public Key Cryptography Standard: (q.v. "Public Key", "cryptography")

PKI
-


Public Key Infrastructure: A certificate system for obtaining an entity
's Public Key. (q.v. "Private Key/Public Key"); a networked
system that enables organisations and users to exchange information and money safely and securely

PLCC
-


Plastic Leaded Chip Carrier: Method of packaging computer chips together

Protocol
-


An

agreed
-
upon format for transmitting data between two devices

bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




Public Key/Private Key
-



Cryptographic keys (q.v.) used together. Private Keys are used to encrypt/decrypt messages or files that have been encrypted
using
a Public Key. The Private Key is on
ly known to the rightful owner. Public Keys are only used in conjunction with the Private Key and
are freely available to defined users.

Public Procurement Terms

See wp8
-
05 Appendix 1 for definitions of the following terms in context:

BAFO


CCTA


Cons
olidated Directive


Contract Notice


Contracting Authority


ECJ


G
-
Cat


ITN


ITT


OGC


OJ


PFI


PIN

[
Note
: In the procurement context this has a different meaning from that which applies in the technical context]

PPP


Public Procurement Directi
ves


Public Services Directive


Public Supplies Directive


Public Works Directive


S
-
Cat


SPV


R


RA
-


Registration Authority: q.v.

RAM
-


Random Access Memory: A type of computer memory that can be accessed randomly

Registration Authority

A reg
istration authority (RA) is an authority in a network that verifies user requests for a digital certificate and tells the cer
tificate
authority (CA, q.v.) to issue it. RAs are part of a public key infrastructure (PKI, q.v.)

bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




RF
-


Radio Frequency: Any freq
uency within the electromagnetic spectrum associated with radio wave propagation

RNG
-


Random Number Generator

ROM
-


Read Only Memory: Computer memory on which data has been pre
-
recorded. Once data has been written onto a ROM chip, it
cannot be remove
d and can only be read

S


S/MIME
-


Secure/ Multipurpose Internet Mail Extensions: A new version of MIME (q.v.) that supports encrypted (q.v.) messages

SCNF
-

Smart Card Networking Forum: Not
-
for
-
profit organisation consisting of public sector represent
atives with an interest in the use of
smart cards to provide improved services to their customers

SDK
-


Software Development Kit: A programming package that enables a programmer to develop applications for a specific platform

SET
-


Secure Electronic Tr
ansaction: A security standard that defines how to encrypt (q.v. "encryption") transmissions over public networks

SIM
-


Subscriber Identification Module: A card
-
based chip that personalises a mobile phone

Smart card
-


A portable programmable device co
nforming to ISO 7816 dimensions and containing an integrated circuit that stores and processes
information

SMS
-


Short Message Service: A service for sending short text messages to mobile phones

SSL
-


Secure Sockets Layer: A protocol (q.v.) developed
by Netscape for transmitting private documents via the Internet (q.v.). SSL works
by using a private key (q.v.) to encrypt (q.v.) data that is transferred over the SSL connection

STIP
-


Small Terminal Interoperability Platform: The STIP Consortium was fo
unded to develop an interoperable (q.v.) platform specification
for secure transaction devices, including, but not limited to, card accepting devices

T


T=CL
-


Specification of a contactless interface (q.v.) for a smart card (q.v.)

Tag
-


A command in
serted in a document that specifies how the document, or a portion of the document, should be formatted

Track
-


A defined part of a magnetic stripe where data can be written

TTP
-


Trusted Third Party

U


UML
-


Unified Modelling Language: A general
-
purpose notational language for specifying and visualizing complex software, especially
large projects

UMTS
-


Universal Mobile Telecommunication System: A 3G (q.v.) mobile technology that will deliver broadband information at speeds up

to
2Mbits/sec

bubblesvoltaire_64e676d1
-
4755
-
417b
-
a28d
-
fd4ae57480d7.doc

Release

11/11/2013




UN
ICODE
-


A standard for representing characters as integers. Unlike ASCII, which uses 7 bits for each character, Unicode uses 16 bits,

which
means that it can represent more than 65,000 unique characters

UNIX
-


Open source computer operating system, popu
lar for workstations

URL
-


Uniform Resource Locator: Website address

USB
-


Universal Serial Bus: An external bus standard that supports data transfer rates of 12 Mbps. A single USB port can be used to

connect up to 127 peripheral devices. USB also supp
orts Plug
-
and
-
Play installation

USIM
-

Universal Subscriber Identity Module: (q.v. SIM)



V


Visual Basic
-


A popular programming language; sometimes called an event
-
driven language because each object can react to different events
such as a mouse cl
ick

VPN
-


Virtual Private Network: A network that is constructed by using public wires to connect nodes; uses encryption (q.v.) and oth
er
security mechanisms to ensure that only authorized users can access the network and the data it carries

W


WAP
-


Wireless Application Protocol: A secure specification that allows users to access information instantly via handheld wireless

devices
such as mobile phones

WIM
-


Wireless Identity Module

Windows
-


A computer operating system developed by Microsoft

WPKI
-


Wireless Public Key Infrastructure: (q.v. PKI)

WWW
-


World Wide Web: Part of the Internet (q.v.)

X


XML
-


Extensible Markup Language: Designed especially for Web documents, it allows designers to create their own customized tags
(q.v.), ena
bling the definition, transmission, validation, and interpretation of data between applications (q.v.) and between
organizations