Priloga 8:
ZZZS – KZZ - Processes
Functional specification of HIC&HPC life-cycle involved processes
Purpose:
Document version:
Date:
Prepared by:
Functional specification of processes involved in
HIC&HPC card lifecycle
1.0
12/7/2010
Crea d.o.o., Blaž Zadel
Revised by:
Document owned by:
© ZZZS, all rights reserved.
STRICTLY CONFIDENTIAL
Table of Contents
1
INTRODUCTION ................................................................................... 4
1.1 ABOUT THE DOCUMENT .................................................................................. 4
VOCABULARY ................................................................................................... 5
1.2 NORMATIVE REFERENCES ..............................................................................11
1.3 ABBREVIATIONS .........................................................................................12
2
ENTITY RELATIONS, REQUIREMENTS AND RESPONSIBILITIES ........... 13
2.1 RELATIONS ...............................................................................................13
2.2 REQUIREMENTS..........................................................................................13
2.2.1
2.2.1.1
2.2.1.2
2.2.1.3
2.2.1.3.1
2.2.1.3.2
List of deliverables .................................................................................. 13
Documentation........................................................................................13
Services .................................................................................................14
Products .................................................................................................15
Software ................................................................................................15
Hardware and accessories ........................................................................15
2.3 RESPONSIBILITIES ......................................................................................15
3
PROPOSED CARD PERSONALIZATION PROCESS .................................. 17
3.1 ASSIGNING ACTOR ROLES AND RESPONSIBILITIES .................................................17
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
Card Manufacturer(s) .............................................................................. 17
Application Developer(s) ......................................................................... 18
Card Issuer ............................................................................................ 18
Personalization Bureau(s) ........................................................................ 19
Certificate Agency .................................................................................. 20
3.2 CARD CONTENT ..........................................................................................20
3.2.1
3.2.2
3.2.3
HIC....................................................................................................... 20
HPC without qualified certificate ............................................................... 21
HPC with qualified certificate .................................................................... 22
3.3 CARD CUSTOMIZATION .................................................................................22
3.3.1
3.3.1.1
3.3.1.1.1
3.3.1.1.2
3.3.1.2
3.3.1.3
3.3.1.4
3.3.1.4.1
3.3.1.4.1.1
3.3.1.4.1.2
3.3.1.4.2
3.3.1.4.3
3.3.1.4.4
3.3.1.4.4.1
3.3.1.4.4.2
3.3.1.5
3.3.1.5.1
3.3.1.5.2
3.3.1.5.3
3.3.1.5.4
3.3.1.5.5
3.3.1.6
3.3.1.7
3.3.1.7.1
3.3.1.8
3.3.2
3.3.2.1
3.3.2.1.1
3.3.2.1.2
Pre-personalization tasks ......................................................................... 23
Key Management.....................................................................................23
Naming conventions for keys ....................................................................23
Exchange of keys ....................................................................................24
Card ordering and shipment......................................................................24
Auditing .................................................................................................24
Personalization data preparation ...............................................................25
Cardholder data ......................................................................................25
Electrical personalization data ................................................................25
Optical personalization data ...................................................................25
Card serial number ..................................................................................25
Secret keys derivation..............................................................................25
Digital certificates ....................................................................................25
Qualified digital certificates ....................................................................25
Non-qualified digital certificates .............................................................26
Personalization process ............................................................................26
Application Load Server authentication .......................................................26
Personalization (electrical personalization) ..................................................26
Optical personalization .............................................................................26
Card Manager configuration ......................................................................26
SCM Environment Updates .......................................................................27
Personalization verification .......................................................................27
Delivery to the Cardholder ........................................................................27
Secure PIN Delivery .................................................................................27
Card Production Completion ......................................................................27
Post-personalization issues ...................................................................... 27
Post-issuance updates..............................................................................28
Application data updates ..........................................................................28
Card and applet updates ..........................................................................28
www.zzzs.si
Page 2 of 34
STRICTLY CONFIDENTIAL
3.3.2.1.3
3.3.2.1.3.1
3.3.2.1.3.2
3.3.2.2
3.3.2.3
3.3.2.4
3.3.2.4.1
3.3.2.4.2
4
Certificates .............................................................................................28
User certificate .....................................................................................28
Qualified and non-qualified certificates ....................................................28
Issuance of HIC PIN .................................................................................28
Unlocking the PIN ....................................................................................28
Card reissuance ......................................................................................28
Card termination .....................................................................................29
Digital certificate revocation......................................................................29
OTHER PROCESSES AFFECTING PERSONALIZATION ............................ 30
4.1 PERSONALIZATION BUREAU ROLE TRANSFER ........................................................30
4.2 CARD PRODUCT REPLACEMENT (SAME CARD MANUFACTURER) ...................................30
4.3 CARD MANUFACTURER ROLE TRANSFER ..............................................................30
ANNEX A: DIGITAL CERTIFICATE ISSUANCE ...............................................................31
ANNEX B: EXISTING CARD PERSONALIZATION PROCESS................................................33
www.zzzs.si
Page 3 of 34
STRICTLY CONFIDENTIAL
1
Introduction
1.1 About the document
For the purpose of the card renewal process initiated by the Health Insurance Institute
the simplified Card and Application Management System Business Architecture
proposed by GlobalPlatform specifications will be discussed in this document. The
simplifications are mainly due to several requirements:
- minimum number of entries must be involved in the card personalization
process:
o Card Manufacturer (has the role of Card Manufacturer, Card Enabler
and Platform KMA),
o Application Developer (this role can be acted by Card Manufacturer),
o Card Issuer (has the role of Card Issuer, Application Provider and
Application Owner),
o Personalization Bureau (has the role of Personalization Bureau,
Application Loader and Application KMA),
o Cardholder.
- The Card Issuer (the Health Insurance Institute) shall issue and manage the
smart cards to it’s customers through the delegated Personalization Bureau.
The later is required to provide the GlobalPlatform compliant SCMS or SCM
Environment.
- The card will only contain applications provided by the Card Issuer. The Issuer
Security Domain (Card Manager) shall be used to manage the application for
the Card Issuer, no additional Security Domains shall be installed on the card.
- A generic Key Management System (KMS) provided by the manufacturer will be
used for the card enablement.
www.zzzs.si
Page 4 of 34
STRICTLY CONFIDENTIAL
Vocabulary
 (Application) Install
The process of allocating persistent memory (e.g.
EEPROM) for application data and populating
persistent memory with specific set-up data. For a
Java Card, an instance of the applet is created and
applet objects are instantiated.
 (Application) Load
The process of populating persistent memory (e.g.,
EEPROM) with application software and “linking” it to
the on-card infrastructure.
 (Smart) Card
Manufacturer
Role that is responsible for producing (smart) cards
on behalf of a Card Issuer. What services are
performed depend on its contractual relationship with
the Card Issuer and may include part or all of the card
production process.
 Actor
Unique entity participating in a Global Platform
compliant smart card environment. These entities can
take forms such as card issuers, application
developers, and personalization bureaus.
 Applet
Java Card term for Java chip application.
 Application
Developer
Actor responsible for the development of Smart Card
applications.
 Application
Identifier
Uniquely identifies an application in a smart card
according to ISO 7816-5.
 Application Instance
Instance of an Executable Module after it has been
installed and made selectable.
 Application Owner
The Application Owner owns the application IPR and
specification.
 Application Profile
The Application Profile describes a smart card
application, independent of any particular smart card.
It acts as a template for creating the actual
application.
 Application Protocol
Data Unit (APDU)
Standard communication messaging protocol between
a card accepting device and a smart card.
 Application Provider
Entity that owns an application and is responsible for
the application's behavior.
 Application State
The current lifecycle state of an application on a
Global Platform smart card.
 Asymmetric
Cryptography
A cryptographic technique that uses two related
transformations, a public transformation (defined by
the
Public
Key
component)
and
a
private
transformation
(defined
by
the
Private
Key
component); these two key components have a
property so that it is computationally infeasible to
discover the Private Key, even if given the Public Key.
 CAP File
A specific data file format defined by Sun
Microsystems for loading Java Card applets onto Java
Card chip-cards.
www.zzzs.si
Page 5 of 34
STRICTLY CONFIDENTIAL
 Card Content
Code and Application information (but not Application
data) contained in the card that is under the
responsibility of the OPEN (e.g., Executable Load
Files, Application instances, etc.).
 Card Customization
Card customization includes loading applets, installing
applets, data preparation, card issuance or preissuance
personalization,
post-issuance
personalization, as well as verifying whether cards
have been personalized correctly.
 Card
Enabler/Initializer
The entity that prepares the platform for subsequent
application loading and places the GlobalPlatform card
under the cryptographic control of the Issuer.
 Card Image Number
(CIN)
An identifier for a specific GlobalPlatform card.
 Card Issuer
Entity that owns the card and is ultimately responsible
for the behavior of the card.
 Card Manager
Generic term for the three card management entities
of an GlobalPlatform card (i.e., the GlobalPlatform
Environment, Issuer Security Domain and the
Cardholder Verification Method Services provider).
 Card Personalization
Card personalization is defined in this document as
the process of producing a card customized to a
specific cardholder and eventually modifying its
contents after issuance to add and delete
functionality.
In
that
broad
sense,
Card
Personalization starts as early as application software
is loaded onto a chip, ends temporarily with card
issuance, and is re-enacted as soon as a new
application is added (or deleted) or when some oncard data is updated post-issuance.
 Card Product
Products are provided by card manufacturers. A
product is an implementation of an operating system
on a chip; it is a card ‘model.’ Some application
instances may exist on a product (pre-loaded
applications).
 Card Profile
The Card Profile describes a smart card. This card
could be a singularly unique card or a card that shares
common characteristics, as defined in the Card Profile,
with other cards. Depending on how it is used, it
either acts as a base template for a smart card or
represents a single smart card by itself.
 Card Recognition
Data
Information that tells an external system how to work
with the card (including indicating that this is a
GlobalPlatform card).
 Card Reference
Number (CRN)
An unique logical number used by the Issuer of the
card to create a common link between the
applications on a particular cardholder’s multiapplication card. The CRN persists through reissuance of the card and there is no requirement for it
to be written to the card; that way the CRN remains
the same across all Application Providers and systems
when a card is replaced.
www.zzzs.si
Page 6 of 34
STRICTLY CONFIDENTIAL
 Card State
The lifecycle status of a GlobalPlatform chip card.
 Card Unique Data
Data that uniquely identifies a card being the
concatenation of the Issuer Identification Number and
Card Image Number.
 Cardholder
The end user of a card.
 Cardholder
The user of the card and the services provided by the
card.
 Certificate Authority
(CA)
A trusted third party that establishes a proof that links
a public key and other relevant information to its
owner.
 Command
A message sent by the host to the smart card that
initiates an action and solicits a response from the
smart card.
 Data Encryption
Standard (DES)
A symmetric cryptographic algorithm.
 Data Preparation
The process of gathering and preparing the necessary
application data and keys for input into the
personalization device. The process can be driven by
the Data Preparation Scripts provided in the
Application Profile.
 Decryption
The reversal of the corresponding encryption. A
reversible transformation of a cryptogram by
cryptographic algorithm to retrieve the original plain
text data.
 Device
Physical
piece
of
hardware
used
in
card
personalization, both pre-issuance and post-issuance
or card acceptance scenarios.
 Digital Signature
An asymmetric cryptographic transformation of data
that allows the recipient of the data to prove the
origin and integrity of the data; it protects the sender
and the recipient of the data against forgery by third
parties; it also protects the sender against forgery by
the recipient
 Enablement
Enablement is defined as the process of loading the
Initial Card Manager data and keys together with the
Issuer Public Key component as well as installing the
Security Domains and loading the Initial Security
Domain keys.
 Encryption
The reversible transformation of data by cryptographic
algorithm to produce a cryptogram.
 Executable Load File
Actual on-card container of one or more application’s
executable code (Executable Modules). It may reside
in immutable persistent memory or may be created in
mutable persistent memory as the resulting image of
a Load File Data Block.
 Executable Module
Contains the on-card executable code of a single
application present within an Executable Load File.
 global PIN
Global PIN is provided as a shared object between the
applets which can used it to restrict access or usage
www.zzzs.si
Page 7 of 34
STRICTLY CONFIDENTIAL
of applet provided resources.
 Global PIN
The GlobalPlatform Card Manager provides optional
access restriction to all managed applets through the
Global PIN. Only one Global PIN can be set, ulock
capability is not provided.
 GlobalPlatform
Environment
The central on-card administrator that owns the
GlobalPlatform Registry.
 GlobalPlatform
Registry
A container of information related to Card Content
management.
 Host
A logical term used to represent the backend systems
that support the GlobalPlatform system; hosts
perform functions such as authorization and
authentication,
administration,
post-issuance
application code and data downloading, and
transactional processing.
 Initialization
The process of populating persistent memory (e.g.
EEPROM) with data that is common to a large number
of cards while also including a minimal amount of card
unique items (e.g., ICC serial number and
Personalization keys).
 Issuer Identification
Number (IIN)
The Issuer unique Identifier as defined in ISO 7812.
 Issuer Security
Domain
On-card entity providing support for the control,
security, and communication requirements of the card
issuer.
 Java
An object oriented programming language.
 Key
A sequence of bits that controls the operation of
cryptographic transformation. Keys are used in
symmetric algorithms (secret keys like in DES) and
asymmetric algorithms (public key and private key
pair like in RSA).
 Key Encrypting Key
(KEK)
Key used to encrypt another key type (usually a data
key) most commonly for key distribution purposes.
 Key Management
System
A distinct component of a Smart Card Management
system required to generate store and manage the
cryptographic keys associated with a multi application
smart card.
 Key Profile
The Key Profile describes a cryptographic key,
independent of any particular instance of the key. It
acts as a template for creating the actual key.
 Lifecycle
The existence of Card Content on an GlobalPlatform
card and the various stages of this existence where
applicable.
 Lifecycle State
A specific state within the Lifecycle of the card or of
Card Content.
 Load File
A file transferred to an GlobalPlatform card that
contains a Load File Data Block and possibly one or
more DAP Blocks.
 Load File Data Block
Part of the Load File that contains one or more
www.zzzs.si
Page 8 of 34
STRICTLY CONFIDENTIAL
application(s) and libraries or support information for
the application(s) as required by the specific platform.
 Loader
The Loader loads cards with applications and/or
personalization/customization data according to the
instructions of the Application Provider, while
complying with the security policies of the Card
Issuer.
 Local PIN
A PIN that is local to the applet and provides access
restriction only for the addhering applet.
 Masking
The process of writing into the immutable memory
(ROM) of a chip, the OS, VM, APIs, and, optionally,
applications.
 OS Platform
A smart card operating system or run-time
environment that provides a consistent and hardware
neutral execution environment for applications,
ensuring
inter-operability
and
portability
of
applications across products compliant to the same
platform specification, independent of the product
supplier.
 Personalization
The process of populating persistent memory (e.g.
EEPROM) with cardholder unique data. Not to be
confused with the terms card customization or card
personalization, which may include load, install, data
preparation, and personalization.
 Personalization
Bureau
A corporation delegated by a card issuer the
responsibility to manage and customize smart cards
for that card issuer.
 Personalization
Script
Scripts that are created by the application developer,
packaged in the Application Profile, and used for the
Card Personalization process.
 Post-Issuance
Phase following
cardholder.
 Post-Issuance Load
Server
A secured device controlled by the Card Issuer for the
post issuance distribution of chip applications onto
chip-cards.
 Post-Issuance
Load/Install
The process of downloading applications and data to
the card after the card has been issued to the
cardholder. This process requires establishing a
secure channel between the Application Load Server
and the chip-card.
 Pre-Issuance
Phase prior to the card being issued to the cardholder.
 Private Key
The private component of the asymmetric key pair.
 Product Profile
Combination of a set of applications selected by an
card issuer with a selected smart card platform. The
product Profile is represented by a combination of
Application Profiles (an application portfolio) and a
Card Profile. A product Profile will, at a minimum,
contain Application Profile(s) and a Card Profile.
Profile Information in an XML document describing
smart card, application, load file, and key
components.
www.zzzs.si
Page 9 of 34
the
card
being
issued
to
the
STRICTLY CONFIDENTIAL
 Public Key
The public component of the asymmetric key pair.
 Public Key
Certificate
An asymmetric transformation of the public key by a
certification authority intended to prove to the public
key’s recipient the origin and integrity of the public
key. It also contains information about the owner of
the key.
 SCM environment
Interface
Interfaces between a smart card management
environment and systems/applications resident at the
same actor or at different actors. The interfaces will
be used to transport Profile data.
 Secure Channel
A communication mechanism between an off-card
entity and a card that provides a level of assurance,
to one or both entities.
 Secure Channel
Session
A session, during an application session, starting with
the Secure Channel Initiation and ending with a
Secure Channel Termination or termination of either
the application session or card session.
 Security Domain
On-card entity providing support for the control,
security, and communication requirements of the
application provider.
 Server
Logical term used in this document to represent the
local or remote back-end systems that are supporting
GlobalPlatform chip-cards. Servers perform functions
such as authentication, administration, initialization,
personalization, post-issuance application and data
loading. Depending on the specific function, Servers
may also be referred to as personalization systems
and application load servers.
 Smart Card
Management
Environment (SCM
Environment)
Functionality which may be resident in an singular
application or incorporated into existing card
management systems that provides facilities for
supporting the administration, personalization, and
issuance of smart cards. A SCM environment may
consist of a single Smart Card Management System
(SCMS).
 Smart Card
Management System
(SCMS)
Functionality of all or part of a SCM environment
resident in a single integrated system.
 Symmetric
Cryptography
A cryptographic technique that uses the same secret
key for both the originator's and the recipient's
transformation.
 Updated Card Profile
Either in a Card Profile or a Card Profile format which
contains information regarding specific applications for
a cardholder or set of cardholders. The updated Card
Profile is a concept used to represent smart cards that
have been issued. Updated Card Profiles may need to
be managed on an individual cardholder basis
depending on the extent to which personalized cards
are unique.
 XML document
A file containing XML-formatted information.
www.zzzs.si
Page 10 of 34
STRICTLY CONFIDENTIAL
1.2 Normative References
The following referenced documents are indispensable for the application of this
document. For versioned or dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any
amendments) applies.
[GP_CARD_CS]
GlobalPlatform Card Specification.
[GP_SYS_PRF]
GlobalPlatform Systems Profile Specification.
[GP_SYS_KMS_REQ] GlobalPlatform Key Management System Functional
Requirements.
[GP_SYS_SCMS_REQ] GlobalPlatform Smart Card Management System Functional
Requirements.
[GP_SYS_MSG]
GlobalPlatform Messaging Specification
[ISO 7816-5]
identifiers.
Numbering system and registration procedure for application
www.zzzs.si
Page 11 of 34
STRICTLY CONFIDENTIAL
1.3 Abbreviations
Alphabetical list of abbrevations used in the document.
AID Application Identifier
AMS Application Management System
CAMS Card and Application Management System
CA Certificate Authority
CAP Java Card executable code format converted applet
CIA Cryptographic Information Application – (ISO 7186-15)
CID Card UniqueID
CIN Card Image Number / Card Identification Number
CIN’ Card Issuance Number
CIS Customer Information System
CRN Card Reference Number
CRL Certificate Revocation List
EMŠO Unique Citizen Identification Number (Enotna Matična Številka Občana)
GP GlobalPlatform
HIC Health Insurance Card
HIN Health Insurance Number
HPC Health Professional Card
HSM Hardware Security Module
IASE Identification Authentication Signature Encryption
IdNum Professional ID Number
IIN Issuer Identification Number
IPR Intellectual Property Rights
ISO International Organization for Standardization
JCSPP Java Card Security Protection Profile
KEK Key Encryption Key
KMS Key Management System
OID Object Identifier
PIN Personal Identification Number
PUK PIN Unlock Key
RA Registration Authority
SCMS Smart Card Management System
SDK Software Development Kit
SN Serial Number
SSCD Secure Signature Creation Device
SSVG-PP Secure Silicon Vendors Group Protection Profile
TK Transport Key
TLV Type-Length-Value
xxxROM ROM or EEPROM
ZZZS The Health Insurance Institute of Slovenia (Zavod za Zdravstveno
Zavarovanje Slovenije)
www.zzzs.si
Page 12 of 34
STRICTLY CONFIDENTIAL
2
Entity relations, requirements and responsibilities
The business model describing personalization process proposed in this document
involves several different entities with different role and responsibility assignment.
This chapter focuses on 3Rs: relations, requirements and responsibilities. The main
propose is to define a big picture where everyone involved shall find what of 3Rs they
must deliver.
2.1 Relations
The Card Issuer being the one that provides cards and applications to the Cardholders
is the main entity driving the project and as such has a role of integrator. It’s interest
is mainly to have the control of the processes and to be directly related to minimum
set of entities. It is thus expected from the entities that they, if so required, make a
direct relationship with 3rd party service providers. One of such relations is expected
from the Personalization Bureau which shall make a direct relationship with the
Certificate Agency issuing qualified certificates.
Although it is acceptable that one entity acts several main roles as may be the case
with the card vendor which acts both as the card manufacturer and the application
developer, it is the requirement of the Card Issuer to maintain the logical role
segregation as defined in this document in order to allow entity exchange or addition
in the future.
2.2 Requirements
Each entity has a specified list of deliverables it has to provide in order to satisfy the
project requirements.
2.2.1
List of deliverables
2.2.1.1 Documentation
Card
Card
-
-
Issuer:
HIC, HPC technical specification
ZZZS-HPC, ZZZS-HIC, IASE functional specification
integration documentation (processes) functional specification
catalogue of processes
DES-3 master keys extraction scenario (is possible)
entity message exchange requirements
contracts
IASE, ZZZS-HIC, ZZZS-HPC applet:
o reference guides (where possible)
o technical specification
middleware documentation (where possible)
Manufacturer:
smart card reference guide
testing suite documentation
HPC card:
o ISO 15408: SSCD Type 2 & Type 3 EAL4+ (card||platform||applets)
certification documentation
o RoHS compliance certificate/statement
o Mission Profile compliance certificate/statement and card qualification
report
HIC card:
www.zzzs.si
Page 13 of 34
STRICTLY CONFIDENTIAL
o ISO 15408: SSCD Type 2 & Type 3 EAL4+ (card||platform||applets)
certification documentation
o RoHS compliance certificate/statement
o Mission Profile compliance certificate/statement and card qualification
report
Personalization Bureau:
- Overall security concept functional specification
- KMS technical specification
- Key management procedure technical specification
- CMS Environment technical specification
- Optical personalisation technical specification
- Lettershop and Mailing technical specification
- Internal auditing technical documentation
- Non-qualified CA technical specification (certification practice statement)
- Qualified CA direct relation contract
- Test environment technical documentation
2.2.1.2 Services
Card Issuer:
- Contract management
- Documentation management
- Relations management
- Cardholder data management
- Cardholder support
- Conflict solving
Card Manufacturer:
- Application development/modifications
- Smart card shipment
- Key exchange ceremony
- Partial optical layout customization (static content)
- Partial electrical customization (xxxROM applet preloading)
- ISO 15408 SSCD Type-3 certification submission documentation preparation
- Card durability certification
Personalization Bureau:
- Personalization Data preparation
- Card Customization
o electrical personalization
o optical personalization
- Smart card management (card state database)
- Key management:
o DES-3 master keys injection (if possible)
OR support for Master Key Card with DES-3 master keys
- Internal auditing
- Smart card delivery
- PIN and PUK delivery
- PKI services:
o direct relation with qualified CA issuing qualified certificates
o managing internal CA issuing non-qualified certificates on behalf of
the Card Issuer
- Test environment
- Smart card management extensibility (if required, best effort)
- Post-issuance card updates/upgrades (if required, best effort)
www.zzzs.si
Page 14 of 34
STRICTLY CONFIDENTIAL
2.2.1.3 Products
2.2.1.3.1 Software
Card Manufacturer
- IASE applet:
o byte code
o IASE: testing suite (compliance, reporting)
- ZZZS-HIC, ZZZS-HPC applet modification:
o source code
o byte code
o testing suite (compliance, reporting)
- GP Application Profiles
- GP Application Load File Profile
- GP Load File Profiles
- middleware for IASE applet:
o Windows CSP, PKCS#11
o Linux PKCS#11
- GP Card profile
- Card performance (platform crypto operations (DES-3, RSA)) testing suite
Certification Authority
Software for signature-PIN activation and qualified certificate request
2.2.1.3.2 Hardware and accessories
Card Manufacturer
- Card Product
Personalization Bureau
- HSM management token (smart card) for the Card Issuer related key group
administration
- PIN/PUK letters
- Card letters
- Postage
2.3 Responsibilities
It is important to distinct the longevity of certain responsibility regarding it’s
“lifecycle”. Beside the basic responsibility of the entity, which is to provide deliverables
in given timeframe, certain services and warranties will have to be provided once the
production stage of the project begins. If not explicitly stated, the responsibility
timeframe shall be minimum 10 years from the beginning of the production stage of
the project.
Card Manufacturer:
- is responsible to provide compatible smart cards for the minimum period of 10
years from the first shipment. If the Card Manufacturer decides to ship new
Card Product to the Card Issuer, it is his responsibility to assure full
compatibility of a new product with the existing card infrastructure set by the
project. That is, if the new Card Product requires application changes, the Card
Manufacturer has to bear all costs of necessary application and personalization
changes required.
- is obliged to offer the application and middleware upgrade and modification
services once the applications are delivered. This is to ensure the portability of
an application between different cards with Java Card and GlobalPlatform
implementation.
www.zzzs.si
Page 15 of 34
STRICTLY CONFIDENTIAL
Personalization Bureau:
- shall offer full cooperation in entity migration if the Card Issuer decides to
contract new Personalization Bureau.
- shall inform the Card Issuer or any events and issues raised within the direct
relationship with the qualified CA concerning the Card Issuer operations and
will act in the Card Issuer best interest.
www.zzzs.si
Page 16 of 34
STRICTLY CONFIDENTIAL
3
Proposed Card Personalization process
The cards shall be only issued and reissued, no Card Content (application) update will
be made in the Post-Issuance stage. The application data contained may be modified
only by the authorized systems.
All GP Profiles shall be prepared with accordance to [GP_SYS_PRF] specification
regarding the structure and the format of the profile.
3.1 Assigning Actor roles and responsibilities
The Card Issuer is a generic term defined by the GlobalPlatform. Through this
document it is assumed that the actual entity which acts as the Card Issuer is the
Health Insurance Institute. For easier cross referencing with the GlobalPlatform
documentation, the Card Issuer term is maintained.
GlobalPlatform specifications defines Actors as unique entities participating in GP
compliant smart card environment. As in case of the Health Insurance Institute one
Actor will have many roles.
It is acceptable that one provider assumes the role of Card Manufacturer, Card Enabler
and Application Developer.
If the Card Issuer contracts a card vendor for a smart card delivery, the vendor shall
assume all responsibilities of the Card Manufacturer.
Figure 1: Relation between the Card Issuer systems and the SCM
Environment hosted by the Personalization Bureau
3.1.1
Card Manufacturer(s)
The number of Card Manufactures which could provide smart card products in
accordance to ZZZS technical specifications should not be limited by unnecessary
requirements such as:
www.zzzs.si
Page 17 of 34
STRICTLY CONFIDENTIAL
-
ROM masked applications; only the core applications (Card Manager) should be
masked so that if selection of new card manufacturer is made, standard cards can
be used.
The Card Manufacturer shall load specified applications to the xxxROM if so required
by the Card Issuer and provide the Personalization Bureau with updated GP Card
Profile.
The Card Manufacturer shall provide smart cards and associated GP Card Profiles to
the Personalization Bureau according to the agreement with Card Issuer. The GP
Application Profile for Card Manager|Issuer Security Domain (with load/install scripts)
shall also be provided.
The manufacturer shall implement the key ceremony requirements for pre-issuance
key management according to the procedure described in section 3.2.1. and then
Enable cards using own master key.
3.1.2
Application Developer(s)
Application Developer (it is role of Card manufacturer) shall provide GP Application
Profile with Script Fragments for the minimum operations required – Data preparation
script (PERSOPREP) and Personalization script (PERSONALIZE).
If needed, the Card Issuer will provide all the required data to enable the creation of
GP Data preparation scripts and GP Personalization scripts. The data will be provided
in Card Issuer specified format.
The Application Developer shall provide the Card Issuer with GP Application Profile, GP
Load File Profile, CAP file and technical documentation for:
- ZZZS-HPC application,
- ZZZS-HIC application,
- IASE application,
- other applications required by implementation (like CIA application) developed to
satisfy the requests from the Card Issuer provided application specifications.
3.1.3
Card Issuer
The ZZZS will have the roles of the Card Issuer, Application Provider and Application
Owner. The Card Issuer shall make appropriate modifications to its actions if
interaction with multiple Card Manufactures, Application Developers and/or
Personalization Bureaus be required.
CIS will manage individual smart card using the GP Card profile and SCMS filed – CID,
which shall be contained in EF.GDO data object of ZZZS(HIC/HPC) applet or shall be
calculated according to the rules in section 3.2.2.3.
The Card Issuer shall provide the application data required by the Personalization
Bureau in order to perform Card Customization:
- it shall prepare a proprietary personalization data file with its Data Preparation
System;
- it shall provide the requests application data required for the creation of nonqualified and qualified digital certificates.
The data will be prepared for initial issuance and reissuance of smart cards.
www.zzzs.si
Page 18 of 34
STRICTLY CONFIDENTIAL
The Card Issuer shall define the ModuleID attributes for all application executable
codes in Load files and UniqueID attributes for all GP profiles. It shall also defined the
AID for which purpose it shall obtain a registered application provider identifier (RID)
provided from the ISO. The AID naming scheme is precisely defined in ISO 7816-5.
3.1.4
Personalization Bureau(s)
The Personalization Bureau shall provide test and production SCM Environment/SCMS
compatible with [GP_SYS_SCMS_REQ] requirements. The GlobalPlatform 2.1.1 card
must be supported, the implementation must be so designed to permit addition of
support for the cards compliant with the new GlobalPlatform specifications.
It shall be responsibility of the Personalization Bureau to supply a KMS according to
requirements in [GP_SYS_KMS_REQ]. The KMS shall store the keys contained on the
Master Key Card, the keys exchanged with the Card Manufacturers and other keys
required during and after the Card Personalization. The HSM shall be dedicated for the
Card Issuer required key management or shall allow logical separation of keys or key
groups. The keys required by the Card Issuer defined processes shall be under sole
administrative control of the Card Issuer.
The production keys from the current system must be either migrated into the new
KMS or the existing Master Key Card must be integrated with the KMS. For the former
option it shall be assumed, that the keys are available as split secret and can be
imported into the KMS in a manual process. If the last option must be chosen, than
the personalization bureau must integrate the Master Key Card at a best effort
approach.
The GP Key Profiles shall be prepared for all keys required during the card
personalization.
The Personalization Bureau shall have the responsibility to gather and request all the
services, files and information needed to fulfill the requirements for GlobalPlatform
compliant Card Personalization process. All necessary profiles shall be collected before
performing a required task. It shall be responsible to verify it’s access to all Data
Elements specified in GP Load File Profile and GP Application Profiles scripts.
When required, it will perform the Load/Install and Personalize operations for the Card
Issuer.
The Personalization Bureau shall be authorized by the Card Issuer to issue the nonqualified certificates. The CMS Environment Interface to the non-qualified CA services
shall be determined by the Personalization Bureau.
If so required by the Card Issuer, the Personalization Bureau shall perform several
post-issuance procedures. The description of such procedures is given in chapter
3.2.2. The exact specification for the required service shall be provided upon request.
The Personalization Bureau shall prepare detailed technical documentation as required
in section 2.2.1.1. providing the details necessary to implement the required services
specified in section 2.2.1.2. Documented and implemented procedures and services
must be compliant with the functional and technical documentation provided by the
Card Issuer.
The agreement shall claim the Card Issuer legal right and ownership of all the data
and material gathered or generated by the Personalization Bureau when acting under
the contract.
www.zzzs.si
Page 19 of 34
STRICTLY CONFIDENTIAL
3.1.5
Certificate Agency
This entity is not acting according to GlobalPlatform specifications. The Card Issuer
shall make an agreement which will authorize the Personalization Bureau for issuance
of ISO 15408 SSCD Type 2 and Type 3 compliant cards according to the requirements
determined by the Card Issuer and the qualified Certification Authority. The
Personalization Bureau and the qualified Certification Authority shall make a direct
relationship and shall act with the Card Issuer requirements when applicable. The
qualified Certification Authority must provide testing instance for development and
test pourposes.
The Personalization Bureau shall provide the qualified Certificate Agency with all
required data (such as public keys) in order to be able to issue the qualified certificate
to the individual or organization approved by the Card Issuer and identified by the
qualified Certificate Agency RA.
The qualified Certificate Agency shall perform the necessary steps for certificate
reservation (e.g identification of the applicant) before the Card Issuer issues the
request for the card to the Personalization Bureau.
The testing and production non-qualified, self-signed Certificate Agency (non-qualified
ZZZS CA) shall be set up by the Personalization Bureau following the requirements of
the Card Issuer for non-qualified certificate issuance. The functional requests are
specified in Annex A.
3.2 Card content
The Card Issuer will issue three types of cards to the cardholders:
- HIC,
- HPC without qualified certificate,
- HPC with qualified certificate.
The following sections describe the applets and the certificates that are used by
different types of cards. Details such as PIN retry values are specified in [IASE_FS]
and [HPC2-CHPC].
In order to minimize the risk of PIN or PUK being disclosed, the Personalization Bureau
must implement the secure PIN and PUK generation and storing mechanisms. It is
suggested that PIN and PUK are derived from unique card data using the symmetric
key stored in HSM.
3.2.1
HIC
During personalization, the following applets must be installed on the card:
- HIC compatibility applet,
- IASE applets.
The IASE application on HIC shall be personalized with 2 non-qualified certificates,
required by ZZZS online services. One instance shall be created for user certificate.
During the personalization, one PIN and corresponding PUK shall be set to protect the
usage of ZZZS portal authentication certificate and user certificate private key. PIN is
local for the IASE applet and does not restrict access to ZZZS-HIC compatibility
application.
www.zzzs.si
Page 20 of 34
STRICTLY CONFIDENTIAL
Purpose and
issuance
Label*
Certificate
Issuer
Type
Key size
and
validity
period
Private key
usage
protection
Client/server
authentication
towards the ZZZS
entry point.
Issued during
personalization.
C.CH.AUT
non-qualified
ZZZS CA,
non-qualified
certificate
1024,
10 years
Not protected.
Client/server
authentication
towards the ZZZS
portal.
Issued during
personalization.
C.CH.AUTP
non-qualified
ZZZS CA
non-qualified
certificate
2048,
10 years
Protected by
local PIN and
PUK.
User certificates.
Issued or installed
after personalization.
C.CH.UXX
3d party CAs
non-qualified or
“Slovene
qualified”
certificates
CA policy and
user request
dependant
Protected by
local PIN and
PUK.
Table 1: digital certificates on HIC.
*
Label used as a reference in [IASE_FS].
3.2.2
HPC without qualified certificate
During personalization, the following applets must be installed on the card:
- HPC compatibility applet,
- IASE applets.
The IASE application on HPC shall be personalized with 1 non-qualified certificate,
required by ZZZS online services.
During the personalization, one PIN and corresponding PUK shall be set to protect the
usage of ZZZS online services authentication certificate. PIN and PUK are global,
providing access and usage restriction for the IASE and ZZZS-HPC compatibility
applet.
Note: during personalization the initial value of the authentication retry counter of
ZZZS-HPC compatibility applet is set to 20. For more information on the
authentication retry counter refer to [HPC2-CHPC].
Purpose and issuance
Label*
Client/server authentication
towards the ZZZS entry
point.
Issued during
personalization.
C.CH.AUT
Certificate
Issuer
Type
Key
size
non-qualified
ZZZS CA
non-qualified
certificate
2048
5 years
Private key
usage
protection
Protected by
global PIN and
PUK.
Table 2: digital certificates on HPC without qualified certificates.
*
Label used as a reference in [IASE_FS].
www.zzzs.si
Page 21 of 34
STRICTLY CONFIDENTIAL
3.2.3
HPC with qualified certificate
During personalization, the following applets must be installed on the card:
- HPC compatibility applet,
- IASE applets.
The IASE application on HPC shall be personalized with 1 non-qualified certificates,
required by ZZZS online services and a keypair required for qualified certificate
issuance.
During the personalization, several PINs are set:
- one PIN and corresponding PUK shall be set to protect the usage of ZZZS online
services authentication certificate. This PIN and PUK are global, providing access
and usage restriction for the IASE and ZZZS-HPC compatibility applet;
- the signature PIN shall be set to restrict the qualified certificate private key usage,
this PIN has no corresponding PUK;
- the transport PIN shall be set to provide the seal for the keypair generated for
qualified certificate before the certificate issuance.
Note: during personalization the initial value of the authentication retry counter of
ZZZS-HPC compatibility applet is set to 20. For more information on the
authentication retry counter refer to [HPC2-CHPC].
Certificate
issuer
Type
Key
size
Private key
usage
protection
C.CH.AUT
non-qualified
ZZZS CA
non-qualified
certificate
2048
5 years
Protected by global
PIN and PUK.
C.CH.QES
qualified CA
qualified
certificate
2048
5 years
Proteced by local
signature PIN, and
transport PIN.
Unlock not
possible.
Purpose and issuance
Label*
Client/server authentication
towards the ZZZS entry
point.
Issued during
personalization.
Qualified eletronic signature
creation.
Keypair generated during
the personalization.
Certificate issued after the
personalization.
Table 3: digital certificates on HPC with qualified certificates.
*
Label used as a reference in [IASE_FS].
For more information about the process of issuing a qualified certificate refer to the
IASE applet specification [IASE_FS], chapter “Issuance of qualified certificates”
3.3 Card customization
This chapter serves as an overview of GlobalPlatform infrastructure processes. Only
the subset of SCM environment functions necessary to determine migration scenario
from the proprietary system, is described.
As GlobalPlatform infrastructure specifications do not specify all processes needed for
the smart card deployment, some additional proprietary processes needed to be
implemented are also described.
During the Card Personalization a number of messages have to be exchanged between
the actors. The actors should agree to use messages proposed by [GP_SYS_MSG] if
applicable. The GlobalPlatform messaging specifications define the following:
www.zzzs.si
Page 22 of 34
STRICTLY CONFIDENTIAL
-
Card customization messages,
Profile exchange messages,
Post issuance messages,
Error messages.
3.3.1
Pre-personalization tasks
3.3.1.1 Key Management
The management of an individual GlobalPlatform enabled smart card is only possible
through the SCM Environment which has access to the Master Keys from which the
diversified Card Master Keys originated. Since the life cycle of the project may include
more than one Card Manufacturer it shall be required for the KMS of the
Personalization Bureau to handle several sets of Master and Transport keys from
different Card Manufacturers.
The project consists of various development stages which in turn require specifically
prepared smart cards by the Card Manufacturer. The main difference in smart card
configuration is the use of different Master Keys to prepare the:
- Card Manufacturer (SDK) development cards,
- development cards,
- test cards,
- production cards.
The Key Management must differentiate between test and production keys. All key
material must be clearly marked and only test keys may be disclosed within the
project scope for testing purposes. The security of the production keys must always be
maintained as described in the overall security concept and key management
procedures.
3.3.1.1.1 Naming conventions for keys
The naming conventions for keys used during the personalization is proposed in the
[GP_SYS_KMS_REQ]. All keys must be properly labeled as development, test or
production keys.
Name
Description
Application keys
Non-GlobalPlatform Key Values, which uses GlobalPlatform Key Values during personalization of
the ICC
CDKDEK
Card unique Issuer Key Value derived from CMK used for encrypting Application Key Values during
Post issuance
CDKENC
Card unique Issuer Key Value derived from CMK used for encrypting the commands to and from
ICC during Post issuance
CDKMAC
Card unique Issuer Key Value derived from CMK used for MAC’ing the commands to and from ICC
during Post issuance
CMK
Issuer Master Key Value – used by Card Issuer to prevent the ICC from further Initialization and
Personalization using KMC and to control Post-issuance initialization and Personalization
KDCDEK
Card unique Initial Card Manager Key Value derived from KMC used for encrypting Application Key
Values during personalization
KDCENC
Card unique Initial Card Manager Key Value derived from KMC used for encrypting the commands
to and from ICC during personalization
KDCMAC
Card unique Initial Card Manager Key Value derived from KMC used for MAC’ing the commands to
and from ICC during initialization and personalization
www.zzzs.si
Page 23 of 34
STRICTLY CONFIDENTIAL
Name
Description
KMC
Initial Issuer Master Key Value – used by the Card Issuer to control the initialization and
personalization of each ICC. In this document, the key is generated by the Card Manufacturer.
TK
Transport Key Value established between the various entities.
Table 4: GlobalPlatform Key naming convention
3.3.1.1.2 Exchange of keys
The Card Issuer and the Card Manufacturer shall define an exchange protocol for the
exchange of KMC and the TK for the required card configuration. The protocol shall
define at least the workflow, the labeling, the KMC wrapping and diversification
algorithm and the messages involved through the key exchange ceremony.
A generic KMC provided by the manufacturer shall be used for the card Enablement.
The Card Issuer shall define the validity period for the keys exchanged based on the
time period or the number of issued smart cards.
The Personalization Bureau SCM environment shall interface to the KMS to securely
generate any KEK (TK) necessary for the protection during transport of any of the
KMC's.
3.3.1.2 Card ordering and shipment
The protocol for batch ordering of smart cards shall be established between the Card
Issuer and the Card Manufacturer. The protocol should define at least the following:
- definition of the shipment location (Personalization Bureau),
- type of shipment and tracking,
- the quantity of the cards in batch,
- the packaging and labelling method for the smart card batch,
- the messages used to negotiate ordering and confirmation,
- the messages used to describe the requirements for smart cards being shipped in
the batch:
o smart card physical configuration,
o smart card application configuration,
o smart card graphical layout.
The number of the smart cards in the batch shall be defined for all smart card
configurations. Depending on the costs of preparation, the batch size for the SDK and
the development smart cards should be 5 cards in the batch. The batches of test and
production cards should contain 100 cards. Other batch configuration may be
requested, depending on the shipping costs and Personalization Bureau requirements.
3.3.1.3 Auditing
The Personalization Bureau shall implement auditing protocols and automatic
mechanisms in order to track the access to critical card customization resources or log
the sensitive operations. The auditing shall be implemented in such way that the
auditing trails will have strong legal value.
The Card Issuer must be granted access to audit trails when expressed by written
request. Either the Card Issuer or a third party authorized by the Card Issuer must be
allowed to perform regular site inspections to ensure the overall security of the
system.
www.zzzs.si
Page 24 of 34
STRICTLY CONFIDENTIAL
3.3.1.4 Personalization data preparation
Personalization data preparation shall be performed by the Personalization Bureau.
The GP Data Preparation Script from the GP Application Profile shall be used to
prepare the Card Issuer provided data in the proprietary format.
The current protocol for data exchange between the Card
Personalization Bureau shall be considered for the data exchange.
Issuer
and
the
The Personalization Bureau will, based on the current project status, require the
following data, provided by the Card Issuer:
- existing card personalization data,
- unique HP identifying and binding data (IdNum, EMŠO) for cardholder enrollment
at RA office,
- additional data required for the certificate creation.
3.3.1.4.1 Cardholder data
The Cardholder data is contained in the existing card personalization data file and is
used for both electrical and optical card customization. The data is provided in Card
Issuer proprietary format and must be further processed. Parts of Cardholder data are
included in existing card post-issuance data and additional data required for the
certificate creation.
3.3.1.4.1.1 Electrical personalization data
For electrical personalization, the GP Script Fragments from GP Application Profiles are
used to build the Personalization data file.
3.3.1.4.1.2 Optical personalization data
Data used for optical personalization is specified in card technical specification.
3.3.1.4.2 Card serial number
The card serial number contained in EF.GDO shall be compatible with the current card
numbering system in order to provide the compatibility with infrastructure. The Card
Issuer requires that the ZZZS card SN as described in “Annex B: Existing Card
Personalization Process - Card Unique ID” for the new cards shall have the first two
bytes set to hex values 41 (ASCII character ‘A’) and 22 (ASCII character ‘”’)
respectively. The ZZZS card SN is represented in 8 bytes (16 digits: 4 predefined
4122, 12 variable).
3.3.1.4.3 Secret keys derivation
The ZZZS-HIC and the ZZZS-HPC compatibility applets require the derivation of the
secret keys from the proprietary master keys. The serial number embedded in the
ICCSN is used as derivation parameter.
3.3.1.4.4 Digital certificates
The IASE applet personalization requires the generation of the keypair with or without
the associated certificate during the personalization process. Depending on the card
type, several predefined keys with or without associated certificates shall be created
on the card.
3.3.1.4.4.1 Qualified digital certificates
www.zzzs.si
Page 25 of 34
STRICTLY CONFIDENTIAL
If the Card Issuer card personalization request indicates the issuance of qualified
certificate, the procedure according to personalization requirements in [IASE_FS]
chapters “Initialization and personalization” and “Issuance of qualified certificates”
must be followed.
This type of the certificate is only created on the subset of HPC population and serves
for the creation of a electronic signature based on a qualified certificate. For such
purpose the HPC certified as SSCD Type 2 and Type 3 EAL4+ device must be used.
Only the keypair is generated on-card during the personalization. The qualified digital
certificate shall contain unique HP identifying number IdNum.
3.3.1.4.4.2 Non-qualified digital certificates
Several non-qualified digital certificates shall be created in the card during the card
personalization.
The non-qualified digital certificate on the HPC (C.CH.AUT) shall contain unique HP
identifying number IdNum.
3.3.1.5 Personalization process
The Personalization process shall be commenced when SCM environment determines
that all required profiles, data files and keys are available and the memory and
cryptographic requirements for the application portfolio are not in conflict for the
chosen card profile.
3.3.1.5.1 Application Load Server authentication
Application Load Server shall authenticate with the Issuer Security Domain (Card
Manager) and establish a secure channel. The necessary keys shall be provided by the
KMS.
3.3.1.5.2 Personalization (electrical personalization)
Personalization of the card includes several key actions:
- Load an application from the load file (performed by the Card Manufacturer),
- Install an application (performed by the Card Manufacturer),
- Select and personalize the application.
3.3.1.5.3 Optical personalization
Optical personalization shall be performed according to the requirements from
technical for the smart card which specifies the personalization parameters (position,
type, colour, printing type...).
3.3.1.5.4 Card Manager configuration
In addition to loading and personalizing applications, the Application Loader needs to
“personalize” the Card Manager and Security Domains by injecting the final derived
Card Manager and Security Domain keys. These keys are always independently
derived by the Personalization Bureau to ensure that, upon issuance, only the
Personalization Bureau has access to the CMK.
After card initialization, the card lifecycle state shall be set to “SECURED” and loaded
application lifecycle states to “PERSONALIZED” for GP 2.01 compliant cards.
www.zzzs.si
Page 26 of 34
STRICTLY CONFIDENTIAL
3.3.1.5.5 SCM Environment Updates
SCM Environment shall be updated with relevant personalization log values and
updated lifecycle states for card and application. Each individual card profile shall be
updated.
The SCM environment shall establish the cardholder master files containing relevant
cardholder information and the logical card reference number (CRN). It is suggested
that the Health Insurance Number (HIN) is used as a CRN and the HIN concatenated
with Card Issuance Number (CIN’ defined by the Card Issuer) shall be used as the
CIN. The CRN shall be linked with CIN. Details on the numbering scheme must be
agreed with the Card Issuer.
3.3.1.6 Personalization verification
When card personalization process is complete, both visual and logical card
verification shall be performed.
3.3.1.7 Delivery to the Cardholder
The Personalization Bureau shall deliver the card to the Cardholder according to the
agreement with the Card Issuer.
3.3.1.7.1 Secure PIN Delivery
The Personalization Bureau shall provide different PIN delivery schema for HPC with
and HPC without qualified digital certificate. For the HPC without qualified digital
certificate, the PIN and PUK are securely delivered to the cardholder. Both PINs shall
be delivered in a single secured envelope, separate from the HPC.
PINs for HIC are delivered upon explicit user request and if
Issuer. See section 3.3.2.2.
required by the Card
3.3.1.8 Card Production Completion
Upon the completion of batch personalization, the Personalization Bureau shall deliver
the report to the Card Issuer. Attached to this report shall be the file, which contains
all the output data from the personalization process in such a manner that can be
imported into Card Issuer Customer Information System (CIS). The Card Issuer shall
use CRN to link the application specific cardholder data to a SCM environment card
identifier.
The minimum set of data returned from the personalization process shall be:
- non-qualified certificate serial and thumbprint number,
- qualified certificate public key,
- CRN, CIN, ZZZS card SN.
Additional data may be required by the Card Issuer and shall be specified in technical
documentation.
3.3.2
Post-personalization issues
The Card Issuer is the initiator of the post-personalization issues. When the card lifecycle state is to be changed or card re-issued it shall provide the Personalization
Bureau with necessary application data files to enable the Personalization of new card.
www.zzzs.si
Page 27 of 34
STRICTLY CONFIDENTIAL
3.3.2.1 Post-issuance updates
Post-issuance updates will not be managed through the SCM environment. If so
required an agreement shall be made between the Card Issuer and the Personalization
Bureau.
3.3.2.1.1 Application data updates
The legacy data managed by the ZZZS-HIC and ZZZS-HPC applet will enable the
update of the application data through the proprietary system.
3.3.2.1.2 Card and applet updates
No card updates are to be done on personalized cards, however the Card Manager /
Issuer Security Domain keys must remain active, so that post-issuance updates to the
card will be possible in the future.
3.3.2.1.3 Certificates
3.3.2.1.3.1 User certificate
An instance of the IASE applet on the HIC will be created for the generation and
management of the user certificate. The content of this instance will controlled by the
Cardholder.
3.3.2.1.3.2 Qualified and non-qualified certificates
The card must be reissued when the certificate validity period expires.
3.3.2.2 Issuance of HIC PIN
The Card Issuer may require the Personalization Bureau to deliver the PIN and PUK to
the HIC cardholder. Following is a sample process for obtaining the PIN for the HIC:
- The HIC cardholder is already in possession of the personalized card. He
decides, that he wants to use PrK.CH.AUTP private key for authentication
toward the ZZZS portal. He also wants to manage his own user private keys
(PrK.CH.UXX).
- The cardholder applies for the PIN (and PUK) at the Personalization Bureau.
- The Personalization Bureau mails the PIN and the corresponding PUK to the
cardholder’s permanent address in secure envelope.
3.3.2.3 Unlocking the PIN
The PUK is managed by the Cardholder.
3.3.2.4 Card reissuance
The card may be reissued for the couple of reasons:
- the qualified or non-qualified certificate validity period expires,
- the card is reported to be defect, stolen or lost,
- the card is reported to be permanently locked (Unlock PIN max tries reached,
signature PIN max retries reached),
- the Cardholder related persistent application data on the card is no longer valid,
- the Cardholder of HPC with non-qualified signing certificate requires a qualified
certificate,
- the card data update is required by the Card Issuer and post-issuance
install/update service is not defined,
- there is a strong evidence that the credentials stored on the card were abused,
www.zzzs.si
Page 28 of 34
STRICTLY CONFIDENTIAL
-
the symmetric master key was disclosed,
the private key of the (non-)qualified Certificate Agency was disclosed,
the CMK was disclosed.
The SCM environment shall be able to associate the CRN with a new card for card reissue purposes. This shall be done by re-linking CRN with the CIN of the newly issued
card.
The SCM environment shall be able to associate a new card with an existing card and
shall correctly terminate an old card at the appropriate lifecycle stage after a new card
has been issued.
3.3.2.4.1 Card termination
Card termination shall be performed, when the Card Issuer ends the relationship with
the Cardholder due to breach of contract or due to death of the Cardholder.
The termination of the old card associated with the CRN shall also occur when the new
card is issued to the Cardholder.
Since the card updates shall not be performed, the Card Manager state on the card
can not be changed. When the card is terminated, the SCM environment shall change
the states in Application and Card profiles associated with the card’s CIN.
The terminated card CIN and associated CRN shall be returned to the Card Issuer.
3.3.2.4.2 Digital certificate revocation
All certificates on the terminated card shall be revoked. The revoked certificate serial
numbers shall be put on appropriate CRL.
www.zzzs.si
Page 29 of 34
STRICTLY CONFIDENTIAL
4
Other processes affecting personalization
4.1 Personalization Bureau role transfer
The Card Issuer may choose to transfer the role of Personalization Bureau to a new
entity. This shall require the transfer of the all the data and materials gathered or
generated by the previous Personalization Bureau when acting under the contract to
the new entity and inspection of relevant auditing trails.
4.2 Card Product replacement (same Card Manufacturer)
The Card Manufacture may chose to supply a compatible card product, which replaces
the previously used card. In such an event, the Card Manufacturer shall give notice to
the Card Issuer and perform, at his own cost, the required modifications to the system
components involved in the change. After such a change, the new Card Product must
be qualified to be compatible with the existing infrastructure and the Card Issuer must
release the new Card Product for use.
4.3 Card Manufacturer role transfer
During the production phase, the Card Issuer may chose to another/additional Card
Manufacturer.
www.zzzs.si
Page 30 of 34
STRICTLY CONFIDENTIAL
Annex A: Digital certificate issuance
1. Non-qualified (internal) CA functional specification
The following requirements are set for production level CA. Test CA should implement
only the requirements which are mandatory to perform the tests. The CA identification
data for the test CA must clearly mark the testing purpose of the CA.
For the operation of the non-qualified certification authority a certification practise
statement (CPS) according to RFC3647 must be defined and implemented accordingly.
For certificates issued by the CA a certificate policy according to RFC3647 must be
defined and published.
The following information shall be defined before the CA operational phase, starting
with root certificate issuance, begins:
- the CA identification data (Name, Distinguished Name, Owner, Address and
Contact data),
- the method of generating the root certificate for the CA shall be determined (selfsigned, subordinate CA, cross-certified),
- the certificate properties (Issuer, Subject, Validity period, RSA key pair modulus
length, signature algorithm) for the root certificate shall be determined. The
constraints may be defined on the properties by the 3 rd party depending on the
method of the root certificate generation,
- the type and purpose of issued certificates,
- the identity and role of CA subjects (CA, RA, certificate requestor/owner),
- the subject obligations,
- the subject responsibilities,
- the CA public information (issued certificates, CRL, public parts of CA
documentation) accessibility (location),
- the data confidentiality regulations,
- the distinguished name static part for all types of issued certificates,
- the rules to form unique distinguished names,
- the method of proving the ownership of private key,
- the method of proving the certificate requestor/owner identity,
- the certificate issuance method,
- the issued certificate storage locations,
- the issued certificate retrieval methods,
- the procedure of certificate revocation:
o possible reasons for revocations,
o possible revocation claimers,
o procedures for certificate revocation,
o timeframe of actual revocation,
o the CRL validity period,
o the CRL validation requirement
- auditing requirements and procedures,
- information archiving,
- the disaster recovery plan:
o server and data-storage failure,
o revocation of root certificate,
o the CA public key disclosure threats,
- actions to be taken upon the CA service termination,
- actions to be taken upon change of the CA distinguished name,
- operational security requirements,
o physical location construction and security,
o physical access,
o sensitive data storage,
www.zzzs.si
Page 31 of 34
STRICTLY CONFIDENTIAL
-
-
o internal CA organization structure and role responsibilities,
technical security requirements:
o key pair generation location and storage,
o private key transfers,
o public key transfers,
o access to the CA public key,
o length of the asymmetric keys,
o asymmetric key generation parameters,
o key usage determination,
o private key protection
 protection of the CA private key,
 private key termination method requirements,
o security requirements for the CA host, required OS and HW CC certification level
profiles (version, extensions, supported algorithms, naming conventions) for the all
issued certificate types,
CRL profile (version, extensions),
documentation (revision leads, publishing, authorization).
The data exchange protocol shall be selected/developed for data exchange with the
CMS Environment interface.
The required CA operational, technical and formal documentation shall be composed.
The CA application software shall be determined, based on price, scalability and
applicability.
www.zzzs.si
Page 32 of 34
STRICTLY CONFIDENTIAL
Annex B: Existing Card Personalization Process
Personalization data exchange
Both entities have reached an agreement on message exchange format. The messages
exchanged are preformatted e-mail massages with attached PGP encrypted and signed
TLV encoded personalization data files.
The format of personalization data file is Card Manufacturer proprietary.
Personalization data message format
Each TLV encoded personalization data file (package) can contain Cardholder data for
Card Customization of up to 2500 smart cards. Packages can be of four types,
depending of the card type (HIC, HPC) and issuance type (initial issuance,
reissuance).
The Card Issuer performs TLV encoding according to the rules set by the
personalization software vendor (developed by the existing Card Manufacturer)
specification. The Card Issuer stores Cardholder information in UTF-8 format.
Card Unique ID
In the current system, the ZZZS card SN is used as the Card Unique ID. Card data
objects contain several different SNs:
- The ICC Manufacturer IC SN; stored in EF.SYSTEM file, can be accessed through
ISO 7816-4 administrative command Get Data and the reference 03h. The length
of this SN is 8 bytes.
- The Card Manufacturer card SN; stored in EF.SYSTEM file, can be accessed through
ISO 7816-4 administrative command Get Data and the reference 02h. This SN is
used during the Personalization process to derivate the ZZZS card SN and card
specific keys. It is also used during the INTERNAL AUTHENTICATE and EXTERNAL
AUTHENTICATE command sequences. The length of this SN is 8 bytes.
- The ZZZS card SN (IHISD_ICCSN); calculated according to ISO 7812-1 and prEN
1867 standard during the Personalization from the Card Manufacturer card SN and
stored in EF.GDO, 16 numerical characters, 8 bytes. The fist byte has a value of
41.
Reporting personalization results to the Card Issuer
Upon successful Personalization, the Personalization Bureau delivers the TLV encoded
personalization data with additional data collected during the Personalization process
to the Card Issuer. Among the additional data, the ZZZS card SN is returned, which is
used as a verification number in the Card Issuer infrastructure network.
Secret keys
The existing Personalization Bureau was delivered a pair of smart cards containing
master keys (master Key card) by the existing Card Manufacturer. One Key card
contains test master keys (green keys), other stores production master keys (red
keys). The secret keys stored on the smart card are;
 1x KI : Internal authentication DES-3 secret key (16 bytes long)
 14x KE : External authentication DES-3 secret key (16 bytes long)
www.zzzs.si
Page 33 of 34
STRICTLY CONFIDENTIAL
 1x KEK : Key Encryption Key for PIN encryption (HPC cards only)
 1x K_PUK : Mother key for PUK derivation (HPC cards only)
Keys are stored in transparent file in specified order.
Some External authenticate keys are not currently used, they might be used for new
file type access control.
Key derivation
Before each HIC or HPC Personalization, personalization software retrieves the Key
card SN and uses the Read secret code and key reference to access the key required
from the master Key Card.
Individual card keys are derived using Card Manufacturer card SN and master key
(mother key, G.HIC).
www.zzzs.si
Page 34 of 34