HPC-Spezifikation 2.3.2 - COS Teil 1

Specification
German
Health Professional Card
and
Security Module Card
Part 1: Commands, Algorithms and Functions

of the COS Platform
Version 2.3.2
05.08.2009
Bundesrztekammer
Kassenrztliche Bundesvereinigung
Bundeszahnrztekammer
Bundespsychotherapeutenkammer
Kassenzahnrztliche Bundesvereinigung
Bundesapothekerkammer
Deutsche Krankenhausgesellschaft
HPC Part 1 COS, V2.3.2 Page 1 of 278

Editor: Ulrich Waldmann (Fraunhofer SIT)
The HPC specification consists of the following parts:
Part 1: Commands, Algorithms and Functions of the COS Platform

Part 2: HPC Applications and Functions
Part 3: SMC Applications and Functions

Revision History
Date Version Modifications

10.08.2005 V0.7 New version with enhancements:
- CV certificates with 1024 and 1280 bits
- MANAGE CHANNEL mandatory
- Support of Key Usage Counter and reset with
RESET (RETRY) COUNTER command
21.09.2005 V0.8 Changes:
- Selection status after CREATE/ACTIVATE FILE
- Le Handling
- Clarification security status evaluation counter
- Precisions, corrections and further information
- RESET RETRY COUNTER extensions optional
- CVCs with 1280 bits not yet mandatory
- ENC and MAC computation for MUTUAL AUTHENTICATE
07.10.2005 V2.09 Alignment of version no.
07.11.2005 V2.099 Changes:
- Addition of an Annex with Authentication Procedures (transfer of technical
details of Part 2 to Part 1; no technical change)
- Re-ordering of Annexes for alignment with Part 1 of eGK
- Insertion of Clause 14 for specifying the Le and Lc handling
14.12.2005 V2.1 Changes:
- Precision PIN management
- CVC harmonization with eGK
- Command handling after interrupt
21.02.2006 V2.1.0 Changes:
- Some precisions for error cases
- Harmonization with eGK V 1.1.0
18.05.2007 V2.1.1 Changes:
- Some precisions for error cases
- Some clarifications
- Some adjustments to gematik SRQs
- No security relevant changes, no need to adjust the PP for the HPC
04.07.2008 V2.2.1 V2.3.0 - Complete change for compliance with BSI technical guidelines (algorithms,
stack and comfort signature) and interoperability with eGK generation 1
09.04.2009 V2.3.1 SRQ-0001 GET RANDOM auf HBA
SRQ-0002 SM Padding Case1 APDU
SRQ-0003 Sicherheitszustnde beim Verzeichniswechsel
SRQ-0004 "Verborgene Records"
SRQ-0005 "Anzahl Oktette in signInput9796_2_DS2"
SRQ-0006 "Zuordnung CHA-Sicherheitszustand zu einem Ordner"
SRQ-0007 "Eindeutige Identifier"
SRQ-0008 "HPC-P1 Corrigenda 1"
SRQ-0011 "Access Condition of TC-sessionkeys"
SRQ-0012 "Wertebereich flagSessionEnabled"
SRQ-0013 SM-Header-Integration bei Kanalnummern > 3"
SRQ-0014 "Introductionkeys in HBA und SMC"
05.08.2009 V2.3.2 SRQ-0016 "Introductionkeys und Sicherheitszustand"
SRQ-0018 "HPC-P1 Corrigenda2"
SRQ-0020 "Schlsselwerte der Introductionkeys"

Content
Content ................................................................................................................. 5
1 Purpose and Scope......................................................................................11

1.1 Purpose...................................................................................................................11
1.2 Structure of this document ...................................................................................11
1.3 Target Group ..........................................................................................................12
1.4 Area of validity .......................................................................................................12
1.5 Working Basis ........................................................................................................12
1.6 Scope of this document ........................................................................................12
2 References....................................................................................................14
3 Abbreviations and Notation ........................................................................17

3.1 Abbreviations .........................................................................................................17
3.2 Notation of large numbers ....................................................................................20
3.3 Notation of Attributes and Values ........................................................................20
3.4 Notation of Keys and Certificates ........................................................................21
3.5 Use of Key Words ..................................................................................................22
3.6 Normative and informative clauses .....................................................................23
4 Life Cycle of a smartcard and the applications (informative) .................24
5 Data Types and Data Conversion ...............................................................25

5.1 BitLength Number of bits in a Bit String ............................................................25
5.2 OctetLength Number of Octets in an Octet String.............................................26
5.3 I2OS Integer to Octet String................................................................................26
5.4 OS2I Octet String to Integer................................................................................27
5.5 OS2P Octet String to Point .................................................................................27
5.6 P2OS Point to Octet String .................................................................................28
5.7 Extraction of leading Elements ............................................................................28
5.7.1 Extraction of leading bits.....................................................................................28
5.7.2 Extraction of leading Octets................................................................................29
5.8 PaddingIso..............................................................................................................29
5.9 TruncateIso.............................................................................................................30
5.10 Mask Generation Function...............................................................................31
5.11 Random Octet String........................................................................................32
6 Cryptographic Algorithms (normative) ......................................................33

6.1 Hash Algorithms ....................................................................................................33
6.1.1 SHA256, G1 and G2 (normative)......................................................................33
6.2 Key Agreement.......................................................................................................33
6.2.1 Characteristics G1 (normative) ...........................................................................33
6.2.2 Characteristics G2 (informative) .........................................................................34
6.3 Basic algorithm (symmetric) for confidentiality .................................................35
6.3.1 Symmetric encryption of a data block, G1 (normative).......................................35
6.3.2 Symmetric decryption of a data block, G1 (normative).......................................36
6.3.3 Symmetric encryption of a data block, G2 (informative) .....................................36
6.3.4 Symmetric decryption of a data block, G2 (informative) .....................................37
6.4 Basic algorithm (asymmetric), G1, (normative) ..................................................37
6.5 Basic algorithm (asymmetric), G2, (informative) ................................................38
6.6 Authentication of data ...........................................................................................38
6.6.1 MAC generation..................................................................................................38
6.6.2 MAC Validation ...................................................................................................40
6.6.3 Signature Calculation..........................................................................................41
6.6.4 Signature Validation............................................................................................45
6.7 Confidentiality of data, symmetric case ..............................................................47
6.7.1 Symmetric encryption .........................................................................................47
6.7.2 Symmetric Decryption.........................................................................................48
6.8 Data confidentiality, asymmetric case.................................................................49
6.8.1 Asymmetric Encryption .......................................................................................49
6.8.2 Asymmetric Decryption.......................................................................................52
7 CV-Certificates (normative).........................................................................56
7.1 CV-Certificates for RSA keys, G1 (normative) ....................................................56
7.1.1 Elements of a CV-Certificate ..............................................................................56
7.1.2 Certificate Profiles...............................................................................................57
7.1.3 Structure and Content of a CV-Certificate ..........................................................58
7.2 CV-Certificate for ELC keys, G2 (informative).....................................................59
8 Objects (normative) .....................................................................................60

8.1 Several Attributs (normative)................................................................................60
8.1.1 File Identifier .......................................................................................................60
8.1.2 Short File Identifier..............................................................................................60
8.1.3 Life Cycle Status.................................................................................................60
8.1.4 List of Access Rules ...........................................................................................61
8.1.5 Record ................................................................................................................61
8.1.6 SE-Identifier ........................................................................................................62
8.1.7 PIN......................................................................................................................62
8.2 Key Material............................................................................................................62
8.2.1 Symmetric Keys..................................................................................................62
8.2.2 Domainparameter for elliptical Curves, G2 (informative)....................................63
8.2.3 Private Key .........................................................................................................64
8.2.4 Public Key...........................................................................................................64
8.2.5 Transport security for a Password (normative)...................................................64
8.3 File (normative) ......................................................................................................65
8.3.1 Folder..................................................................................................................65
8.3.2 File ......................................................................................................................67
8.3.3 File Control Parameter........................................................................................71

8.4 Password (normative) ...........................................................................................73
8.5 Key Objects (normative)........................................................................................75
8.5.1 Symmetric Authentication Object........................................................................76
8.5.2 Symmetric Introduction Object............................................................................77
8.5.3 Private Key Object ..............................................................................................78
8.5.4 Public Key Object ...............................................................................................80
8.6 Data objects (informative).....................................................................................82
8.7 Security Environment (informative) .....................................................................82
8.8 Security Status (informative) ................................................................................84
9 Object System (normative)..........................................................................85

9.1 Design and depth of the structure .......................................................................85
9.2 Object Search.........................................................................................................87
9.2.1 File Search..........................................................................................................87
9.2.2 Password Search................................................................................................88
9.2.3 Search for a Key Object......................................................................................89
10 Access Control (normative) .....................................................................94

10.1 Access Mode.....................................................................................................94
10.2 Access Condition .............................................................................................94
10.3 Access Rules ....................................................................................................96
10.4 Evaluation of Access Rules.............................................................................97
11 Communication (normative) ....................................................................98

11.1 Request Response ........................................................................................98
11.2 Electrical Interface............................................................................................98
11.2.1 Activation ........................................................................................................98
11.2.2 Deactivation ....................................................................................................99
11.2.3 Character Frame.............................................................................................99
11.2.4 Protocol and Parameter Selection ..................................................................99
11.3 OSI Reference Model (informative) .................................................................99
11.4 Command Handling........................................................................................100
11.5 Command APDU .............................................................................................101
11.5.1 Class Byte.....................................................................................................101
11.5.2 Instruction Byte .............................................................................................102
11.5.3 Parameter P1................................................................................................102
11.5.4 Parameter P2................................................................................................102
11.5.5 Data Field .....................................................................................................102
11.5.6 Le Field .........................................................................................................103
11.6 Response APDU .............................................................................................103
11.6.1 Data Field .....................................................................................................104
11.6.2 Trailer............................................................................................................104
11.7 Allowed Command Response Pairs .............................................................104
11.7.1 Case 1 Command Response Pair ................................................................104
11.8 Transmission Protocol...................................................................................110
11.9 Command Chaining........................................................................................110
12 Channel Context (normative).................................................................112

12.1 Attributes of a Logical Channel.....................................................................112
12.2 Reset Behavior................................................................................................114
12.3 Set of a Security Status..................................................................................114
12.4 Deletion of a Security Status .........................................................................115
12.5 Set of a Password Status...............................................................................116
12.6 Deletion of a Password Status ......................................................................117
13 Secured Communication (normative) ...................................................118

13.1 Secure Messaging Layer................................................................................118
13.1.1 Derivation of Session Keys ...........................................................................118
13.1.2 Processing an APDU command ...................................................................120
13.2 Securing a Command APDU..........................................................................121
13.3 Securing a Response APDU ..........................................................................124
14 Commands (normative)..........................................................................127
14.1 Roll-Back and Roll-Forward...........................................................................127
14.1.1 Roll-Back ......................................................................................................128
14.1.2 Roll-Forward .................................................................................................128
14.2 Management of the Object System ...............................................................128
14.2.1 ACTIVATE ....................................................................................................128
14.2.2 CREATE .......................................................................................................130
14.2.3 DEACTIVATE ...............................................................................................130
14.2.4 DELETE........................................................................................................132
14.2.5 LOAD APPLICATION ...................................................................................134
14.2.6 SELECT........................................................................................................137
14.2.7 TERMINATE CARD USAGE ........................................................................150
14.2.8 TERMINATE DF ...........................................................................................150
14.2.9 TERMINATE EF ...........................................................................................150
14.3 Access to Data in a transparent EF ..............................................................150
14.3.1 ERASE BINARY ...........................................................................................150
14.3.2 READ BINARY .............................................................................................153
14.3.3 SEARCH BINARY ........................................................................................156
14.3.4 UPDATE BINARY.........................................................................................156
14.3.5 WRITE BINARY............................................................................................160
14.4 Access to structured Data .............................................................................160
14.4.1 ACTIVATE RECORD....................................................................................160
14.4.2 APPEND RECORD ......................................................................................164
14.4.3 DEACTIVATE RECORD...............................................................................168
14.4.4 ERASE RECORD .........................................................................................172
14.4.5 READ RECORD ...........................................................................................175
14.4.6 SEARCH RECORD ......................................................................................179
14.4.7 UPDATE RECORD.......................................................................................182
14.4.8 WRITE RECORD..........................................................................................186
14.5 Access to data objects...................................................................................186
14.5.1 GET DATA....................................................................................................186
14.5.2 PUT DATA ....................................................................................................187
14.6 User Verification .............................................................................................187
14.6.1 CHANGE REFERENCE DATA.....................................................................187
14.6.2 DISABLE VERIFICATION REQUIREMENT .................................................190
14.6.3 ENABLE VERIFICATION REQUIREMENT ..................................................192
14.6.4 GET PIN STATUS ........................................................................................194
14.6.5 RESET RETRY COUNTER ..........................................................................196
14.6.6 VERIFY.........................................................................................................201
14.7 Component Authentication............................................................................203
14.7.1 EXTERNAL AUTHENTICATE / MUTUAL AUTHENTICATE ........................203
14.7.2 GENERAL AUTHENTICATE ........................................................................209
14.7.3 GET SECURITY STATUS KEY ....................................................................209
14.7.4 INTERNAL AUTHENTICATE .......................................................................212
14.8 Commands of the Cryptobox ........................................................................215
14.8.1 PSO: COMPUTE DIGITAL SIGNATURE .....................................................215
14.8.2 PSO: COMPUTE CRYPTOGRAPHIC CHECKSUM ....................................219
14.8.3 PSO: DECIPHER..........................................................................................221
14.8.4 PSO: ENCIPHER (normative) ......................................................................224
14.8.5 PSO: VERIFY CRYPTOGRAPHIC CHECKSUM .........................................228
14.8.6 PSO: HASH ..................................................................................................230
14.8.7 PSO: TRANSCIPHER ..................................................................................230
14.8.8 PSO: VERIFY CERTIFICATE.......................................................................235
14.9 Miscellaneous .................................................................................................238
14.9.1 ENVELOPE ..................................................................................................238
14.9.2 GENERATE ASYMMETRIC KEY PAIR .......................................................244
14.9.3 GET CHALLENGE........................................................................................248
14.9.4 GET RESPONSE .........................................................................................249
14.9.5 MANAGE CHANNEL ....................................................................................249
14.9.6 MANAGE SECURITY ENVIRONMENT .......................................................252
14.9.7 GET RANDOM .............................................................................................260
15 Authentication Protocols (normative)...................................................263

15.1 Internal Authentication without Negotiation of Session Keys ...................264
15.1.1 Internal Authentication with symmetric Keys ................................................264
15.1.2 RSA, asymmetric role authentication............................................................265
15.1.3 ELC, asymmetric proof of authorization (G2, informative) ............................265
15.2 External Authentication without Negotiation of Session Keys ..................266
15.3 Card-2-Card Authentication without Negotiation of Session Keys............266
15.4 Negotiation of Session Keys .........................................................................267
15.4.1 Symmetric Negotiation of Session Keys between SMC and eGK ................267
15.4.2 Symmetric Negotiation of Session Keys between HPC and SMC................268
15.4.3 RSA Negotiation of Session Keys between SMC and eGK..........................269
15.4.4 RSA Negotiation of Session Keys between SMC and HPC .........................270
15.4.5 ELC Negotiation of Session Keys (informative) ............................................271
15.5 Mutual Introduction ........................................................................................271
15.6 Establishment of a Trusted Channel with Introduction Keys.....................273
16 Miscellaneous (normative).....................................................................275
16.1 Algorithm Identifier.........................................................................................275
16.2 Coding for Trailer............................................................................................278

1 Purpose and Scope
1.1 Purpose
This specification defines the requirements to the functionality of an operating system for the
electronic Health Professional Card and the Security Module Card, which correspond to in-
ternational standards to guarantee international and European interoperability.
On the basis of [ISO7816-4], [ISO7816-8] and [ISO7816-9] commands and options will be
described which have to be supported by the HPC and the SMC.
1.2 Structure of this document
Clause 1: Introduction: contains information how to work with this document
Clause 2: Reference List: contains the list of documents referenced in this document
Clause 3: Abbreviations: contains the abbreviations and notations used in this document.
Clause 4: Lifecycle of smartcard and application (informative): terminates the scope of the
HPC/SMC -specification on the timeline.
Clause 5: Data types and data conversion: defines some basic data types, which simplify
the normative description in following clauses.
Clause 6: Cryptographic algorithms (normative): defines some basic cryptographic func-

tions which simplify the normative description in following clauses.
Clause 7: CV-Certificates (normative): describes certificates which will be used to import

public keys into the HPC and the SMC.
Clause 8: Objects (normative): contains a kind of class diagram in textual form. The de-
fined objects and attributes simplify the normative description in following clauses.
Clause 9: Object system (normative): describes how information can be stored persistent
and hierarchically on an HPC resp. an SMC.
Clause 10: Access Control (normative): describes the protection of information on an HPC
resp. an SMC against unauthorized access.
Clause 11: Communication (normative): describes how HPC and SMC exchanges infor-
mation with other systems.
Clause 12: Channel context (normative): describes the information which can be stored
volatile and channel-specific on an HPC and an SMC (compare also [ISO7816-4] in re-
spect to logical channels).
Clause 13: Secured Communication (normative): describes how the HPC and the SMC
exchange information with other systems with cryptographic protection.
Clause 14: Commands (normative): contains normative statements to commands which

will be sent to an HPC and to an SMC and normative statements how these commands
have to be processed by the HPC and the SMC. This is the most important clause of this
document, because it describes the outside view on the behavior of the HPC and the
SMC at the electrical interface most broadly.
Chapter 15: Authentication Protocols (normative): describes the sequences containing

more -than one command.
Clause 16: Miscellaneous (normative): specifies concrete values for a number of place-
holders.
The document is built bottom-up: artifacts will be first described and defined before used.
To read top down, it is recommended to start with Clause 14. In this clause references to
other clauses will be mentioned, if themes will be described there more in detail. Because of
the special importance of Clause 14, the structure of this clause will be described in detail:
Chapter 14 contains all commands standardized in ISO/IEC 7816. Because of better clarity
Clause 14 is divided in the sections Roll-Back and Roll-Forward, Management of the Object
System, Access to Data in a transparent EF, Access to structured Data, Access to Data Ob-
jects, User Verification, Component Authentication, Commands of the Cryptobox, Miscella-
neous. Each sector contains a number of sub-clauses with commands in alphabetical order.
The relatively simple command READ BINARY is used as an example to explain the specifi-
cation of a command. It starts with a basic description of the command. In the sub-clauses
14.3.2.1 and 14.3.2.2 guidelines for the APDUs will follow. Looking at (N544.00) it becomes
obvious that the guidelines for command APDUs are not addressed to the card operating
system but to the using systems. The requirements to the card operating system are de-
scribed in a separate sub-clause Command Handling inside the smartcard.
1.3 Target Group
This document is addressed to manufacturers of card operating systems (COS) and pro-
grammers of application software, which communicates directly with the smartcard.
1.4 Area of validity
The content of this document is mandatory for the production of HPCs and SMCs.
1.5 Working Basis
The work on this document is closely related to the specification of the electronic Health Card
(eGK) [eGK-P1]und [eGK-P2] and the specification of the SMC-K [SMC-K].
1.6 Scope of this document
This document specifies the behavior at the electrical interface of a card operating system.
This document does not specify the architecture of the operating system. To simplify the pic-
ture this document will be based on a modular structure of the COS. The structure described
here is not mandatory. But it is recommended to be oriented at this structure because sup-
plements and extensions will be based on this.
The configuration of a smartcard, thus the definition which applications, folders, files, keys
and passwords can be found on an HPC / SMC is not part of this document.
Normative rules for the useful life of cryptographic methods are defined in [Krypt-Alg]. For
reasons of interoperability with the eGK and the SMC-K [Krypt-Alg] it is relevant also for the
HPC, the SMC-A and the SMC-B. Redundancies to that document will be accepted.

2 References
[AES-128]
Federal Information Processing Standards Publication 197,
(FIPS-197), November 26, 2001, Announcing the ADVANCED ENCRYPTION STANDARD
(AES), http://csrc.nist.gov/publications/
[AES-CTR]
Section 6.5 of NIST Special Publication 800-38A, Recommendation for Block, Cipher Modes
of Operation, Methods and Techniques, Morris Dworkin, December 2001 Edition,
http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
[ANSI X3.92]
American National Standard X3.92 1981, Data Encryption Algorithm
[ANSI X9.62]
Public Key Cryptography for the Financial Services Industry, The Elliptic Curve Digital Signa-
ture Algorithm (ECDSA), 2005
[ANSI X9.63]
Public Key Cryptography for the Financial Services Industry, Key Agreement and Key Trans-
port Using Elliptic Curve Cryptography, 2001
[BinPrefix]
Prefix for binary multiples, IEC INTERNATIONAL STANDARD 60027-2, Third edition, 2005-
08, Letter symbols to be used in electrical technology Part 2: Telecommunications and
electronics, Clause 3.8.3, http://physics.nist.gov/cuu/Units/binary.html
http://de.wikipedia.org/wiki/Bin%C3%A4rpr%C3%A4fix
http://en.wikipedia.org/wiki/Binary_prefix
[BrainPool]
ECC Brainpool Standard Curves and Curve Generation v. 1.0 19.10.2005,
http://www.teletrust.de/fileadmin/files/oid/oid_ECC-Brainpool-Standard-curves-V1.pdf
[CMAC]
NIST Special Publication 800-38B, Recommendation for Block, Cipher Modes of Operation:
The CMAC Mode for Authentication, Morris Dworkin, May 2005,
http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf
[eGK-P1]
gematik (19.09.2008): Spezifikation elektronische Gesundheitskarte; Teil 1: Spezifikation der
elektrischen Schnittstelle, Version 2.2.2, www.gematik.de
[eGK-P2]
gematik (19.06.2008): Spezifikation elektronische Gesundheitskarte; Teil 2: Grundlegende
Applikationen, Version 2.2.1, www.gematik.de
[EN14890-1]
EN 14890-1: 2008, Application Interface for smart cards used as secure signature creation
devices Part 1: Basic services
[EN14890-2]

EN 14890-2: 2008, Application Interface for smart cards used as secure signature creation
devices Part 2: Additional services
[HPC-P2]
German Health Professional Card and Security Module Card, Part 2: HPC Applications and
Functions, Version 2.3.2, 12.08.2009
[HPC-P3]
German Health Professional Card and Security Module Card, Part 3: SMC Applications and
Functions, Version 2.3.2, 12.08.2009
[ISO7816-3]
ISO/IEC 7816-3: 2006
Identification cards Integrated circuit cards with contacts Part 3: Electrical interface and
transmission protocols
[ISO7816-4]
ISO/IEC ISO 7816-4: 2005
Identification cards Integrated circuit cards Part 4: Organization, security and commands
for interchange
[ISO7816-5]
ISO/IEC 7816-5: 2004
Identification cards Integrated circuit cards Part 5: Registration of application providers
[ISO7816-8]
ISO/IEC 7816-8: 2004
Identification cards Integrated circuit cards Part 8: Commands for security operations
[ISO7816-9]
ISO/IEC 7816-9: 2004
Identification cards Integrated circuit cards Part 9: Commands for card management
[ISO9796-2]
ISO/IEC 9796-2: 2002
Information technology Security techniques Digital signature schemes giving message
recovery Part 2: Integer factorization based mechanisms Second edition, 2002-10-01
[Krypt-Alg]
gematik: Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur,
Version 1.6.0, www.gematik.de
[PKCS#1]
PKCS #1 v2.1: RSA Cryptography Standard, RSA Laboratories, June 14, 2002,
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf
[PKI-Reg]
gematik: Registrierung einer CVC-CA der zweiten Ebene, Version 1.8.0, www.gematik.de
[PKI-Nota]
gematik: Festlegungen zu den Notationen von Schlsseln und Zertifikaten kryptographischer
Objekte in der TI, Version 1.1.0, www.gematik.de
[RFC2119]

Network Working Group, Request for Comments: 2119, S. Bradner Harvard, University,
March 1997, Category: Best Current Practic, Key words for use in RFCs to Indicate Re-
quirement Levels, http://www.apps.ietf.org/rfc/rfc2119.html
[SHA-256]
Federal Information Processing Standards Publication 180-2
Change Notice to include SHA-224), section 6.2, 2002 August 1, Announcing the, SECURE
HASH STANDARD, http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf
[SMC-K]
gematik: Spezifikation der SMC-K,
Version 1.2.0, www.gematik.de
[TR-03111]
Technical Guideline TR-03111, Elliptic Curve Cryptography,
Based on ISO 15946, Version 1.00, http://www.bsi.de/literat/tr/tr03111/BSI-TR-03111.pdf
[TR-03116]
BSI TR-03116, Technische Richtlinie fr die eCard-Projekte der Bundesregierung, Version:
3.0, Datum: 08.04.2009, http://www.bsi.de/literat/tr/tr03116/BSI-TR-03116.pdf

3 Abbreviations and Notation
3.1 Abbreviations
AC Attribute Certificate
ADF Application Dedicated File
AID Application Identifier [ISO7816-5]
AKS Auslser KomfortSignatur (Comfort Signature Trigger)
APDU Application Protocol Data Unit [ISO7816-3]
ATR Answer-to-Reset
AUT Authentication
AUTD CV-based device-authentication
AUTR CV-based role-authentication
C Certificate
CA Certification Authority
CAMS Card Application Management System
CAR Certification Authority Reference
CBC Cipher Block Chaining
CC Cryptographic Checksum
CH Cardholder
CHA Certificate Holder Authorization
CHR Certificate Holder Reference
CLA Class-Byte of a command APDU
COS Chipcard Operating System
CPI Certificate Profile Identifier
CRT Control Reference Template
CS CertSign (CertificateSigning)
CTR Counter mode [AES-CTR]
CVC Card Verifiable Certificate
DE Data Element
DER Distinguished Encoding Rules
DES Data Encryption Standard
DO Data Object
DF Dedicated File [ISO7816-4]
DS Digital Signature

DSI Digital Signature Input
ECDSA Elliptic Curve Digital Signature Algorithm
EF Elementary File [ISO7816-4]
eGK elektronische Gesundheitskarte (electronic Health Card)
ELC Elliptic Curve Cryptography
ENC Encryption
ENC( ) Encrypted data
ES Electronic Signature
FCP File Control Parameter
FID File Identifier
G1 Generation 1, names this version of the document, normally with the addition
normative
G2 Generation 2, names a later version of the document, normally with the addi-
tion informative
HBA Heilberufsausweis (Health Professional Card)
(see also [HPC-P2] und [HPC-P3])
HCI Health Care Institution
HP Health Professional
HPC Health Professional Card
ICC Integrated Circuit Card
ICCSN ICC Serial Number
ID Identifier
INS Instruction-Byte of a command APDU
IFD Interface Device
IFSC maximum Information Field Size for the Card ([ISO7816-3], 11.4.2])
IFSD maximum Information Field Size for the Interface Device ([ISO7816-3],
11.4.2])
KD Key derivation Data
KM Komfortmerkmal (Comfort Token)
LSBit Least Significant Bit
LSByte Least Significant Byte
MAC Message Authentication Code
MSBit Most Significant Bit
MSByte Most Significant Byte
MSE Manage Security Environment
NAD Node Address Byte
OAEP Optimal Asymmetric Encryption Padding
OID Object Identifier

OSI Open Sytems Interconnection
OSIG Organizational Signature
P1 Parameter P1 of a command APDU
P2 Parameter P2 of a command APDU
PI Padding Indicator
PIN Personal Identification Number
PKI Public Key Infrastructure
PP Protection Profile
PPS Protocol Parameter Selection
PrK Private Key
PRND Padding Random Number
PSO Perform Security Operation
PuK Public Key
PUK Personal Unblocking Key - Resetting Code
QES Qualified Electronic Signature
RAM Random Access Memory
RCA Root CA
RFC Request fr Comment
RND Random Number
RPE Remote PIN-Empfnger (Remote PIN-Receiver)
RPS Remote PIN-Sender
RSA Algorithm of Rivest, Shamir, Adleman
SAK Signaturanwendungskomponente (signature creation component)
SE Security Environment
SFI Short File Identifier
SIG Signature
SK Secret Key
SM Secure Messaging
SMC Security Module Card
SMKT Sicherheitsmodul Kartenterminal (Security Module Card Terminal)
SN Serial Number
SSC Send Sequence Counter
SUK Stapel- und Komfortsignatur (stack and comfort signature)
TLV Tag Length Value
TC Trusted Channel
TPDU Transport Protocol Data Unit [ISO7816-3]
3TDES 3-Key-Triple-DES

3.2 Notation of large numbers
Table 1: (N0.10) prefixes, based on multiples to the power of 10
Name Symbol Value according to SI Next multiple to the power of 2

kilo k 103 = 1.000 210 = 1.024
mega M 106 = 1.000.000 220 = 1.048.576
giga G 109 = 1.000.000.000 230 = 1.073.741.824
tera T 1012 = 1.000.000.000.000 240 = 1.099.511.627.776
peta P 1015 = 1.000.000.000.000.000 250 = 1.125.899.906.842.624
exa E 1018 260
zetta Z 1021 270
yotta Y 1024 280
The following table is based on [BinPrefix].

Table 2: (N0.20) Prefixes based on multiples to the power of two:
Name Symbol Value

kibi Ki 210 = 10241 = 1.024
mebi Mi 220 = 10242 = 1.048.576
gibi Gi 230 = 10243 = 1.073.741.824
tebi Ti 240 = 10244 = 1.099.511.627.776
pebi Pi 250 = 10245 = 1.125.899.906.842.624
exbi Ei 260 = 10246 = 1.152.921.504.606.846.976
zebi Zi 270 = 10247 = 1.180.591.620.717.411.303.424
yobi Yi 280 = 10248 = 1.208.925.819.614.629.174.706.176
Note: example: 300 GB 279,4 GiB, 300 giga Byte are approximately 279,4 gibi Byte
3.3 Notation of Attributes and Values
In this document an object oriented view will be pursued. Therefore the artefacts file (EF in
the nomenclature of [ISO7816-4] or keys will be regarded as objects and their properties as
attributes of the objects. If attributes of an object are meant the notation obj.attribute is used.
If the attribute is an object with additional attributes, also longer names are possible.

Table 3: (N0.30) Notation of values and assignments:
1D Hexadecimal numbers and octet strings will be written in inverted commas
x || y The symbol || stands for the concatenation of octet strings or bit strings
1234 || 5678 = 12345678
y=x A value of x will be assigned to the variable y (standard notation in established programming
languages).
yx A value of x will be assigned to the variable y (notation from [TR-03111]).
3.4 Notation of Keys and Certificates
For keys and certificates the following simplified Backus-Naur-Notation is used (see [PKI-
Nota] for definitions):
<object descriptor> ::= <key descriptor> | <certificate descriptor>
<key descriptor>::= <key>.<keyholder>.<key usage>
<key>::= <private key> | <public key> | <secret key>
<private key>::= PrK (asym.)

<public key>::= PuK (asym.)
<secret key>::= SK (sym.)
<keyholder>::= <health professional> | <card holder> | <certification authority> |

<health professional card> | <card application management system> |
<health care institution> | <security module card> |
<signature application component> | <security module card terminal> |
<electronic health card>
<health professional>::= HP
<card holder>::= CH
<certification authority>::= <root certification authority> |
<certification authority for CAMS of HPC> | <certification authority for HPC> |
<certification authority for SMC> | <certification authority for eGK> |
<certification authority for comfort signature trigger>
<root certification authority>::= RCA
<certification authority for card application management
system of health professional card>::= CA_CAMS_HPC
<certification authority for health professional card>::= CA_HPC
<certification authority for security module card>::= CA_SMC
<certification authority for electronic health card>::=
CA_eGK (CA elektronische Gesundheitskarte)
<certification authority for comfort signature trigger>::= CA_KM (CA Komfortmerkmal)
<health professional card>::= HPC

<card application management system> ::= CAMS
<health care institution>::= HCI
<security module card>::= SMC
<signature application component>::= SAK
<security module card terminal>::= SMKT
<electronic health card>::= eGK (elektronische Gesundheitskarte)
<key usage>::= <organizational signature> | <encipherment> | <authentication> |

<certsign cvc> | <certsign x509>
<organizational signature>::= OSIG
<encipherment>::= ENC
<certsign cvc>::= CS
<certsign x509>::= CA
<authentication>::= AUT | <cv based authentication>
<cv based authentication>::= <role authentication> | <device authentication>

<role authentication> ::= AUTR_CVC
<device authentication> ::= AUTD_CVC | <remote pin sender> |
<remote pin receiver> | <stack and comfort signature card> |
<comfort signature trigger> |
<signature application component>
<remote pin Sender>:: = AUTD_RPS_CVC (Remote PIN Sender)

<remote pin Receiver>::= AUTD_RPE_CVC (Remote PIN Empfnger)
<stack and comfort signature card>::= AUTD_SUK_CVC (Stapel- und Komfortsignatur)
<comfort signature trigger>::= AUTD_AKS_CVC (Auslser Komfort Signatur)
<certificate descriptor>::=
<certificate>.<certificate holder>.<certificate usage>
<certificate>::= C
<certificate holder>::=
<health professional> | <certification authority> | <health professional card> |
<card application management system> | <security module card> |
<security module card terminal> | <electronic health card>
<certificate usage>::=
<organizational signature> | <encipherment> | <authentication> | <certsign cvc> |
<certsign x509>
3.5 Use of Key Words
To distinguish between normative and informative information key words in capital letters as
defined in [RFC2119] will be used.
MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an
absolute requirement of the specification.
MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an abso-
lute prohibition of the specification.
SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid
reasons in particular circumstances to ignore a particular item, but the full implications
must be understood and carefully weighed before choosing a different course.
SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may
exist valid reasons in particular circumstances when the particular behavior is acceptable
or even useful, but the full implications should be understood and the case carefully
weighed before implementing any behavior described with this label.

MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One
vendor may choose to include the item because a particular marketplace requires it or be-
cause the vendor feels that it enhances the product while another vendor may omit the
same item. An implementation which does not include a particular option MUST be pre-
pared to interoperate with another implementation which does include the option, though
perhaps with reduced functionality. In the same vein an implementation which does in-
clude a particular option MUST be prepared to interoperate with another implementation
which does not include the option (except, of course, for the feature the option provides.)
Statements with the key word MAY are expressed both with a negative definition as well as
with a positive definition. (N22.00) in combination with (N21.00) is a good example: in
(N21.00) normative requirement is posed, which leaves open whether additional values are
optionally forbidden or not. This gap is closed by (N22.00).
3.6 Normative and informative clauses
Clauses with normative content will show the following addition in the headline:
(normative)
In general only structures marked by (N4711.00) SHALL contain properties being relevant for
the accreditation tests and therefore SHALL be tested during the accreditation tests. If in a
special case this is not mentioned, this is very likely an editorial fault.
Clauses marked with Generation 1 (G1) normally have the addition normative. Clauses
marked with Generation 2 (G2) are provided for the use in a later version of this document;
these clauses have the addition informative. It shall be mentioned that the informative
clauses relating to generation 2 are only an outlook. On one hand this means that changes
are possible until the realization of generation 2. There is no guarantee that no changes will
occur until than. On the other hand these clauses are in no way relevant for the accreditation
for generation 1.

4 Life Cycle of a smartcard and the applications
(informative)
In the literature different definitions for the term lifecycle can be found. This clause gives a
simplified view and defines the area of validity of this specification. Roughly the lifecycle of a
smartcard can be divided into three phases:
1. Preparation phase: from a production point of view this phase contains all steps being
necessary to prepare the smartcard for the useful life. Parts of this are the development
of the operational system (OS), the test of the OS, the certification and eventually the
evaluation. Chips coming out of this process will than be produced initialized and person-
alized. The chips will be implanted into a card body and the smartcards will be delivered
to the final user. The sequence described here is only an example and can also be differ-
ent.
This specification is not valid for the preparation phase of a smartcard.
The preparation phase of the smartcard ends with the transfer of the smartcard to the fi-
nal user. Then it starts the useful life of a smartcard.
2. Useful Life: This phase includes the electrical use of the smartcard.
This specification is valid for the useful life of the electrical interface of the smartcard.
The useful life of the smartcard ends after the irreversible termination of all business use
cases, that means also, if the card is physically destroyed.
3. Termination phase: If a smartcard is in the termination phase all intended applications of

the smartcard are blocked in an irreversible way. This can be reached by physical dete-
rioration of the chip or by supporting the command TERMINATE CARD USAGE (see
Clause 14.2.7). Depending on the manufacturer of the chip specific other commands may
be usable after executing the command TERMINATE CARD USAGE (SELECT, GET
CHALLENGE, ), or the transfer layer T = 1 may still be active. Therefore it is not possi-
ble to talk about an absolutely inactive smartcard in that case.
This specification is not valid for the termination phase.
In line with the phases of the smartcard it is possible to define the phases preparation, use
and termination also for applications and their parts (EF, passwords, keys). The deteriora-
tion of the smartcard is then comparable with the deletion of the application and all parts of it.
This specification is not valid for the preparation phase of applications and their parts. It de-
scribes only the status of the object system during the useful life.
The useful life of an application or a part of an application starts as soon as such an object
as defined in the specification of the application can be used. The useful life of an application
or parts of an application ends after deletion or termination of the related object.

5 Data Types and Data Conversion
The following data types equivalent to [TR-03111] Clause 3 are used in this document:
1. Octet string (OS)
2. Bit string (BS)
3. Integer (I),
4. Field element (FE) and
5. elliptical curve point (ECP)
Definition: the most significant bit (MSBit) of a bit string is the bit farthest left
Definition: the least significant bit (LSBit) of a bit string is the bit farthest right
Definition: the most significant octet (most significant byte MSByte) of an octet string is the
octet farthest left
Definition: the least significant octet (least significant byte LSByte) of an octet string is the
octet farthest right
The following conversion functions conform to [TR-03111] are used in this document:
1. Bit string to octet string BS2OS
2. Octet string to bit string OS2BS
3. Field element to octet string FE2OS
4. Octet string to field element OS2FE
5.1 BitLength Number of bits in a Bit String
This functionality is not directly visible at the physical interface. In the context of several in-
ternal operations in the operating system of a smartcard the function described will be used
as follows:
Input: in Bit string with any content and any length
Output: out Integer, number of bits equal to in
Errors: none
Notation: out = BitLength( in )

5.2 OctetLength Number of Octets in an Octet String
as follows:
Input: in Octet string with any content and any length, or integer having no nega-
tive value
Output: out Integer, number of octets in consists of or

Number of octets being at least necessary to code an integer which is not
negative
Errors: none
Notation: out = OctetLength( in )

Note: examples
OctetLength( ) = 0
OctetLength( 1234 ) = 2
OctetLength( 0 ) = 1, because the cipher null has to be coded in an octet, 0 = 00.
OctetLength( 127 ) = 1, because 127 = 7F`
OctetLength( 255 ) = 1, because 255 = FF
OctetLength( 256 ) = 2, because 256 = 0100.
5.3 I2OS Integer to Octet String
This clause describes the conversion of an integer having not a negative value into an octet
string. This functionality is not directly visible at the physical interface. In the context of sev-
eral internal operations in the operating system of a smartcard the function described will be
used as follows:
Input: x Integer, number having not a negative value
n Integer, number of octets in out, n may be null, then out is empty
Output: out Octet string with the length of n octets
Errors: None. Warning: different to [TR-03111] no error message will be gener-

ated if x is greater than or equal to 256n
Notation: out = I2OS( x, n )

Note: to a certain extent this is the reverse function of (N2.00)
(N1.00)
As a principle the integer x having no negative value will be taken as a number of digits
to the basis of 256; only the least significant digits will than be used for the output:
a. Step 1: x = 2560 x0 + 2561 x1 + 2562 x2 + + 256i xi +

b. Step 2: Mi = xi.
Note: each digit will be coded unsigned in an octet.
c. Step 3: out = Mn1 || Mn2 || || M2 || M1 || M0.
Note: Examples I2OS(30010, 1) = 3A, I2OS(30010, 2) = 753A, I2OS(30010, 3) = 00753A.
5.4 OS2I Octet String to Integer
This clause describes the conversion of an octet string into an integer having no negative
values. This functionality is not directly visible at the physical interface. In the context of sev-
eral internal operations in the operating system of a smartcard the function described will be
used as follows:
Input: in Octet string of any length and any content
Output: out Integer, no negative value
Errors: none
Notation: out = OS2I( in )

Note: to a certain extent this is the reverse function of (N1.00)
(N2.00)
As a principle each octet will be regarded as a number in big endian-format without
negative values to the basis of 256,
a. Step 1: n = OctetLength( in )
b. If n
i. equals 0, then out = 0
ii. does not equal 0, than out has to be chosen so that I2OS( out, n ) = in
5.5 OS2P Octet String to Point
This clause describes the conversion of an octet string into a point on an elliptical curve. This
functionality is not directly visible at the physical interface. In the context of several internal
operations in the operating system of a smartcard the function described will be used as fol-
lows:
Input: PO Octet string, coding a point on an elliptical curve
dP Domain parameter according to (N86.00)
Output: P Point on an elliptical curve with coordinates P = (x,y)
Errors: ERROR if PO has not the format uncompressed coding
Notation: P = OS2P( PO, dP )

(N3.00)
Decoding of PO according to [TR-03111] Clause 3.1.1
a. Step 1: if OctectLength (PO) is not equal to (2 dP.L + 1) then return the error code
ERROR and terminate this algorithm
b. Step 2: Divide PO according to:
PO = PC || X || Y,
1 = OctetLenght( PC ),
L = OctetLength( X ) = OctetLength( Y ).
c. Step 3: If PC is not equal to 04 then return error code ERROR and terminate this
algorithm.
d. Step 4: PEA = ( x, y ) = ( OS2I( X ) mod dP.p, OS2I( Y ) mod dP.p ).
e. Step 5: If PEA is not part of the curve defined by dP then return error code ERROR
and terminate this algorithm.
5.6 P2OS Point to Octet String
This clause describes the conversion of a point on an elliptical curve into an octet string. This
functionality is not directly visible at the physical interface. In the context of several internal
operations in the operating system of a smartcard the function described will be used as fol-
lows:
Input: P Point on an elliptical curve with coordinates P = ( x,y )
n Integer, number of octets per coordinate
Output: PO Octet string, coding a point on an elliptical curve
Errors:
Notation: PO = P2OS( P, n )
(N4.00)
Coding of P according to [TR-03111] Clause 3.1.1:
PO = 04 || I2OS( x, n ) || I2OS( y, n ).
5.7 Extraction of leading Elements
5.7.1 Extraction of leading bits
This clause describes the extraction of leading bits from a bit string
Input: in either bit string of length s bits
or octet string of length s bits
n Integer, number of bits to be extracted

Output: out Bit string of length n bits
Errors: none
Notation: out = Extract_MSBit( in, n )
(N5.00)
Precondition: n less than or equal to s
(N6.00)
The bit string out contains the n MSBit of in
5.7.2 Extraction of leading Octets
This clause describes how to extract leading octets from an octet string.
Input: in either bit string of length s octets
or octet string of length s octets
n Integer, number of elements to be extracted
Output: out Octet string of length n octets
Errors: none
Notation: out = Extract_MSByte( in, n )
(N7.00)
Precondition: n less than or equal to s
(N8.00)
The octet string out contains the n MSByte of in
5.8 PaddingIso
This functionality is not directly visible at the physical interface. The padding is done accord-
ing to [ISO7816-4] Clause 6.2.3.1 Sequential stage bullet point 2. In the context of several
internal operations in the operating system of a smartcard the function described will be used
as follows:
Input: in Octet string with any content and any length
n Integer, states the block length of out in octets
Output: out Octet string with a number of octets being a multiple of n
Errors: none

Notation: out = PaddingIso( in, n )
Note: This is the reverse function of (N10.00).
(N9.00)
Execute the following:
a. Step 1: out in || 80.
b. Step 2: If 0 = OctetLength( out ) mod n, then return out and terminate the algorithm.
Otherwise continue with step 3.
c. Step 3: out out || 00.
d. Step 4: continue with step 2
5.9 TruncateIso
as follows:
Input: in Octet string with any content and a number of octets being a
multiple of n
n Integer, defines the block length in octets used for the padding
Output: out Octet string with any content and any length
Errors: paddingError The length of in is not a multiple of n
Too many padding bits
Notation: out = TruncateIso( in, n )

Note: This is the reverse function of (N9.00).
(N10.00)
a. Step 1: len OctetLength( in )
If len is not a multiple of n, then terminate the algorithm with the error code pad-
dingError.
b. Step 2: If OctetLength( in ) is null, then terminate the algorithm with the error code
paddingError.
c. Step 3: If LSByte of in has the value 00, then set
in Extract_MSByte( in, OctetLength( in ) 1)
and continue with step 2.
d. Step 3: If LSByte of in has not the value 80, then terminate the algorithm with the
error code paddingError.
e. Step 4: out Extract_MSByte( in, OctetLength( in ) 1)

f. Step 5: If ( len OctetLength( out ) ) is greater than n, then terminate the algorithm
with the error code paddingError.
5.10 Mask Generation Function
as follows:
Input: Z Bit string with any content and any length
LN Integer, defines the bit length of N
i Integer, initial value for the iteration
Output: N Bit string, result of the Mask Generation Function
Errors: error According to [ISO9796-2] Annex B.3.2 Point 1 an error has to be re-
turned, if Z is too long or LN is too large.
Note: Today these errors are not relevant for the use of smartcards. They will
only occur if Z or N has values of more than several Gigabytes.
Notation: N = MGF( Z, LN , i )
Note 1: If this function is called with i = 0, then the result is in accordance with
[ISO9796-2] Annex B,
[PKCS#1] Annex B.2.1.
Note 2: If this function is called with i = 1, then the result is in accordance with
[ANSI X9.63] Clause 5.6.3, if there the optional parameter SharedInfo is empty.
[TR-03111] Clause 4.4.2, however the key material will be extracted from N in a different way.
(N11.00)
a. Step 1: Set n (empty octet string).
b. Step 2: Set n n || SHA_256( BS2OS( Z ) || I2OS( i, 4 ) ).
c. Step 3: If the hash operation terminates with an error then stop this algorithm with
the error code error.
d. Step 4: Set i i + 1.
e. Step 5: If i is greater than or equal to 232 = 1 0000 0000, then stop this algorithm
with the error code error.
f. Step 6: If 8 times OctetLength( n ) is less than LN, then continue this algorithm with
step 2.
g. Step 7: Set N Extract_MSBit( n, LN ).

5.11 Random Octet String
as follows:
Input: n positive integer, which defines the number of octets in out
Output: out random octet string with the length of n octets
Errors: none
Notation: out = RAND( n )
(N12.00)
Execute the following: generate an octet string out with a length of n whereas each bit
of out is generated by chance.
Note: This document does not define normative statements in terms of quality of the random number
generator. However, for evaluation purposes it is reasonable that the quality of the random num-
ber generator follows [Krypt-Alg] Clause 5.2 and[TR-03116].

6 Cryptographic Algorithms (normative)
6.1 Hash Algorithms
A hash algorithm calculates a bit string of fixed length from any sequence of bits of (nearly)
unlimited length. This functionality is not directly visible at the physical interface. In the con-
text of several internal operations in the operating system of a smartcard a hash algorithm
will be used as a function as described in the following clauses:
6.1.1 SHA256, G1 and G2 (normative)
Input: M any octet string (message) to be hashed
Output: H Octet string, hash-value with a length of 32 octets = 256 bits
Errors: M too long Message to be hashed contains too many bits. This is the case
for M with more than (264 -1) bits
Note: In practice this error is not relevant for smartcards. To hash a
message with a length of 264 bits in 10 years the hash algorithm
has to work with 6,8 GiB per second.
Notation: H = SHA_256( M )
(N13.00)
The COS MUST calculate H from M according to [SHA-256].
6.2 Key Agreement
In this clause a function is described, which calculates - starting from an initial value key
material for symmetric algorithms. This key material will mainly be used for encryption during
transport. This functionality is not directly visible at the physical interface. In the context of
several internal operations in the operating system of a smartcard the key agreement as a
function will be used as described in the following sub-clauses:
6.2.1 Characteristics G1 (normative)
Input: KD Octet string, key derivation data, initial material for the key agreement,
in principle it is an octet string of any content and any length
Output: Kenc Octet string with the length of 24 octets, used as 3TDES-key for en-
cryption and decryption
T1 Integer, without negative values, used in combination with Kenc as Send

Sequence Counter, see functions in Clause 6.7.
Kmac Octet string with the length of 24 octets, used as 3TDES-key for MAC-
generation and MAC-check.
T2 Integer without negative values, used in combination with Kmac as Send

Sequence Counter, see functions in (N337.00) and (N340.00).
Errors: none
Notation: ( Kenc, T1, Kmac, T2 ) = KeyDerivation_3TDES( KD )
(N14.00)
The COS MUST calculate ( Kenc, T1, Kmac, T2 ) from KD according to [ANSI X9.63]
Clause 5.6.3.
a. Step 1: km = BS2OS( MGF( OS2BS( KD ), 512, 1 )).
b. Step2: Split km to Kenc, t1, Kmac and t2 in a way, that:
i. OctetLength( Kenc ) = OctetLength( Kmac ) = 24
ii. OctetLength( t1 ) = OctetLength( t2 ) = 8
iii. km = Kenc || t1 || Kmac || t2
c. Step 3: T1 = OS2I( t1 ) and T2 = OS2I( t2 )
6.2.2 Characteristics G2 (informative)
Input: KD Octet string, key derivation data, initial material for the key agreement,
in principle it is an octet string of any content and any length
Output: Kenc Octet string with the length of 16 octets, used as AES128 key for en-
cryption and decryption
T1 non-negative integer used in combination with Kenc initial value for the
counter, see functions in Clause 6.7
Kmac Octet string with the length of 16 octets, used as AES128 key for
MAC-generation and MAC-check.
T2 non-negative integer used in the context of Kmac as Send Sequence

Counter, see (N337.00) and (N341.00).
Errors: none
Notation: ( Kenc, T1, Kmac, T2 ) = KeyDerivation_AES128( KD )
(N15.00)
The COS MUST calculate (Kenc, T1, Kmac, T2 ) from KD according to [TR-03111]
Clause 4.4.2 as follows:.
a. Step 1: km = BS2OS(MGF( OS2BS( KD), 512, 1 )).
b. Step 2: split km to Kenc, t1, Kmac and t2 in a way that:
i. OctetLength( Kenc ) = OctetLength( Kmac ) = 16
ii. OctetLength( t1 ) = OctetLength( t2 ) = 16
iii. km = Kenc || t1 || Kmac || t2
c. Step 3: T1 = OS2I(t1) and T2 = OS2I (t2)
6.3 Basic algorithm (symmetric) for confidentiality
Starting with any octet string (plaintext), an encryption algorithm calculates an encrypted text
(cipher text) by using a secret key. A corresponding decryption algorithm calculates from the
encrypted text (cipher text) the original octet string (plaintext) using the same symmetric se-
cret key. In this clause only the encryption of one block with a block-cipher algorithm will be
shown. The processing of input data of any length will be treated in Clause 6.7.
6.3.1 Symmetric encryption of a data block, G1 (normative)
ternal operations in the operating system of a smartcard the encryption as a function will be
used as described in the following:
6.3.1.1 Encryption with DES
Input: Pj any octet string with a length of 8 octets = 64 bits
K any octet string with a length of 8 octets = 64 bits, to be used as a key
Output: Cj Octet string, encrypted data with a length of 8 octets
Errors: none
Notation: Cj = DES_ENC( K, Pj )
(N16.00)
The COS MUST calculate Cj from Pj using K, according to [ANSI X3.92].
6.3.1.2 Encryption with 3TDES
K any octet string with a length of 24 octets = 192 bits, to be used as a key.
K consists of the three partial keys Ka, Kb, Kc and it applies: K = Ka ||
Kb || Kc
Output: Cj Octet string, encrypted data with a length of 8 octets.
Errors: none
Notation: Cj = 3TDES_ENC( K, Pj )

(N17.00)
The COS MUST calculate Cj from Pj using K as follows:
Cj = DES_ENC( Kc, DES_DEC( Kb, DES_ENC( Ka, Pj ) ) ).
6.3.2 Symmetric decryption of a data block, G1 (normative)
6.3.2.1 Decryption with DES
Input: Cj any octet string with a length of 8 octets = 64 bits
K any octet string with a length of 8 octets = 64 bits, used as a key
Output: Pj Octet string, decrypted data with a length of 8 octets
Errors: none
Notation: Pj = DES_DEC( K, Cj )
(N18.00)
The COS MUST calculate Pj from Cj using K, according to [ANSI X3.92].
6.3.2.2 Decryption with 3TDES
Input: Cj any octet string with a length of 8 octets = 64 bits
Kb || Kc
Output: Pj Octet string, decrypted data with a length of 8 octets
Errors: none
Notation: Pj = 3TDES_DEC( K, Cj )
(N19.00)
The COS MUST calculate Pj from Cj using K as follows:
Pi = DES_DEC( Ka, DES_ENC( Kb, DES_DEC( Kc, Ci ) ) ).
6.3.3 Symmetric encryption of a data block, G2 (informative)

K any octet string with a length of 16 octets = 128 bits, used as a key
Output: Cj Octet string, encrypted data with a length of 16 octets
Errors: none
Notation: Cj = AES_ENC( K, Pj )
(N20.00)
The COS MUST calculate Cj from Pj using K according to [AES-128] Figure 5.
6.3.4 Symmetric decryption of a data block, G2 (informative)
This clause deliberately contains no normative requirements: it is not necessary because of

the used CTR-mode (see [AES-CTR]).
6.4 Basic algorithm (asymmetric), G1, (normative)
RSA is used as the basic asymmetric algorithm. The mathematical background of this
scheme is described in [PKCS#1].
(N21.00)
The COS MUST support RSA-keys with
a. a modulus length n from the set of {2048} bits
b. a public exponent e in the following interval
[216+1, 2321] = [65.537, 4.294.967.295] = [0001 0001, FFFF FFFF].
(N22.00)
The COS MAY accept additional modulus lengths.
The COS MAY refuse additional modulus lengths.
(N23.00)
The COS MAY support public exponents of other intervals.
The COS MAY refuse public exponents of other intervals.
(N24.00)
Private RSA keys violating the 2 bound from [TR-03116] Clause 3.5.2,
therefore |log2(p) log2 (q)| < 30 does not apply for these keys,
a. MAY be accepted by the COS
b. MAY be refused by the COS
In accordance with [PKCS#1] Clause 2 the RSA-key-parameters will be described in this
document as follows:

Table 4: (N24.50) List of key parameters of a RSA-key
Parameter Meaning
n RSA modulus
e RSA public exponent
d RSA private exponent
Note: To simplify matters Chinese remainder theorem-parameters are not used in this document.
Nevertheless it is recommended to use Chinese remainder theorem parameters for operations
with the private key inside the COS for performance reasons.
6.5 Basic algorithm (asymmetric), G2, (informative)
As the basic algorithm elliptical curves will be used. The mathematical background of this
scheme is described in [TR-03111].
(N25.00)
The COS MUST support elliptical curves, for which the domain-parameters comply with
the requirements of [BrainPool] Clause 3 and have a length of 256 bits.
(N26.00)
The COS MAY support additional elliptic curves.
The COS MAY refuse additional elliptic curves.
In accordance with to [TR-03111] Table 2.1 the domain parameters will be described in this
document as follows:
Table 5: (N26.50) List of domain parameters of an elliptical curve

Parameter Meaning
p Prime number, which describes the group Fp being the base
a First coefficient of the Weierstra equation
b Second coefficient of the Weierstra equation
G A base point on the curve E(Fp)
n Order of the base point G in E(Fp)
h Co-factor of G in E(Fp)
Based on (N25.00) h = 1 applies for all curves which MUST be supported by a COS
6.6 Authentication of data
Within the scope of data authentication information will be added to any data, which allows
checking the integrity and the authenticity of the data.
6.6.1 MAC generation
The MAC-generation is a data authentication based on a basic symmetric algorithm. For an

octet string of any content and any length a MAC is calculated. The length of the MAC de-
pends only on the algorithm but not on the octet string. This functionality is not directly visible
at the physical interface. In the context of several internal operations in the operating system
of a smartcard the MAC-generation as a function will be used as described in the following

6.6.1.1 Generation Retail-MAC, G1 (normative)
Input: M any octet string of any length for which the MAC should be calculated
Kb || Kc
Output: T Octet string to be used to check the integrity and the authenticity of M
Errors:
Notation: T = CALCULATE_Retail_MAC( K, M )
(N27.00)
The COS MUST calculate T from M using K. The following steps will be executed:
a. Step 1: Calculate X = PaddingIso( M, 8 )
b. Step 2: Divide X into blocks with 64 bits each X = X1 || X2 || || Xn.
c. Step 3: Set Y0 = 0000 0000 0000 0000.
d. Step 4: Calculate Yi = DES_ENC( Ka, Yi1 XOR Xi ) for i = 1, , n 1.
e. Step 5: Calculate T = 3TDES_ENC( K, Yn1 XOR Xn )
Note: In the context of Secure Messaging an initialization vector Y0 unequal to null is used for the con-
struction of the message, see (N354.00)and (N367.00).
6.6.1.2 Generation of CMAC, G2, (informative)
Input: M any octet string for which the MAC should be calculated
K any octet string used as a key. The length of K is 16 octets, if K is an AES-

128-key.
Output: T Octet string to be used to check the integrity and the authenticity of M
Errors:
Notation: T = CALCULATE_CMAC( K, M )
(N28.00)
The COS MUST calculate T from M using K according to [CMAC] Clause 6.2. The fol-
lowing steps will be executed:
a. Step 0: Mlen = BitLength( M ).
CIPH = Block Cipher Algorithm (see (N20.00))
b = Blocklength of CIPH = 128 bits
b. Step 1: generate subkeys K1 and K2 according to [CMAC] Clause 6.1.
c. Step 2: If Mlen = 0 then set n=1
Otherwise r = Mlen mod b and
If r = 0, then set n = Mlen / b
Otherwise set n = (Mlen r) / b + 1
d. Step 3: Divide M in blocks as follows:
M = M1 || M2 || || Mn1 || M*n.
The blocks M1 until Mn1 have the length b. The block length of M*n is less than or
equal to b.
e. Step 4: If r = 0 then set Mn = K1 XOR M*n,
Otherwise set Mn = K2 XOR PaddingIso( M*n, b / 8 ).
f. Step 5: C0 = I2OS( 0, b / 8 )
g. Step 6: Ci = AES_ENC( K, Ci1 XOR Mi ).
h. Step 7: T = Cn.
6.6.2 MAC Validation
With the MAC validation the consistency of the data and the added data of the data authenti-
cation will be checked. This functionality is not directly visible at the physical interface. In the
context of several internal operations in the operating system of a smartcard the MAC valida-
tion as a function will be used as described in the following
6.6.2.1 Retail-MAC validation, G1 (normative)
Input: M any octet string being protected by a MAC
T Octet string, added to M for data authentication
K Any octet string used as a key. K has a length of 24 octets. K consists of

the three partial keys Ka, Kb, Kc and it applies: K = Ka || Kb || Kc
Output: out Result of the MAC validation, either VALID or INVALID
Errors:
Notation: out = VERIFY_Retail_MAC( K, T, M )
(N29.00)
The COS MUST check the integrity of M using T and K. The following steps have to be
done:
a. Step 1: T = CALCULATE_Retail_MAC( K, M ).
b. Step 2: If T is identical to T then return VALID.
Otherwise return INVALID
6.6.2.2 CMAC validation, G2 (informative)
Input: M any octet string being protected by a MAC
T Octet string, added to M for data authentication
K Any octet string used as a key. K has a length of 16 octets if K is an AES-

128 key.
Output: out Result of the MAC validation, either VALID or INVALID
Errors:
Notation: out = VERIFY_CMAC( K, T, M )
(N30.00)
The COS MUST check the integrity of M using T and K according to [CMAC]
Clause 6.3. The following steps have to be performed:
a. Step 1: T = CALCULATE_CMAC( K, M ).
b. Step 2: If T is identical to T then return VALID.
Otherwise return INVALID
6.6.3 Signature Calculation
In this document calculation of a signature only means the operation using the private key.
6.6.3.1 Signature calculation with RSA, G1 (normative)
6.6.3.1.1 RSA, ISO9796-2, DS1, SIGN

Using the command INTERNAL AUTHENTICATE this functionality is visible at the physical
interface (see (N888.00)e, (N888.00)f, (N888.00)g and (N888.00)h). It will be used as fol-
lows:
Input: PrK a private RSA-key according to Clause 8.2.3
M any octet string representing the message to be signed
Output: sig Octet string representing the signature
M2 Octet string representing the non recoverable part of the message M
Errors:
Notation: ( sig, M2 ) = RSA_ISO9796_2_DS1_SIGN( PrK, M )
(N31.00)
According to [ISO9796-2] Clause 7 and 8 the COS MUST perform the following opera-
tions using these definitions: n = PrK.n, d = PrK.d
a. Step 1: message allocation: splitting the message M in M1 and M2 according to
[ISO9796-2] Clause 7.1.2.
b. Step 2: message representative production: Calculate the representation F of the
message M according to [ISO9796-2] Clause 8.2. whereas t = 1 MUST be set and
the hash function SHA-256 (see (N13.00)) MUST be used.
c. Step 3: signature production: According to [ISO9796-2] Clause 7.1.4 and [ISO9796-
2] Annex A.4 the following operations will be performed:

i. Step 3.1: J = OS2I( F )
ii. Step 3.2: a = Jd mod n
iii. Step 3.3: b =na
iv. Step 3.4: c = min{ a, b }
v. Step 3.5: sig = I2OS( c, OctetLength( n ) )
6.6.3.1.2 RSA, SSA, PKCS1-V1_5

Using the command PSO: COMPUTE DIGITAL SIGNATURE this functionality is visible at
the physical interface (see (N912.00)b). It will be used as follows:
Input: digestInfo any octet string being used as digest info, see [PKCS#1] Annex
A.2.4
PrK a private RSA-key according to Clause 8.2.3
Output: S Octet string representing the signature
Errors: ERROR DigestInfoTooLong
Notation: S = RSASSA_PCKS1_V1_5_SIGN( PrK, digestInfo )
(N32.00)
According to [PKCS#1] Clauses 8.2.1, 9.2 the COS MUST perform the following opera-
tions using these definitions: n = PrK.n, d = PrK.d
a. Step 0: If OctetLength( digestInfo ) > 0,4 OctetLength( n ), then terminate this algo-
rithm with error code DigestInfoTooLong.
b. Step 1: Set EM 00 || digestInfo.
c. Step 2: Set EM FF || EM.
d. Step 3: If OctetLength( EM ) is less than OctetLength( n ) 2, then continue with
step 2..
e. Step 4: Set EM 01 || EM.
f. Step 5: Set m OS2I( EM ).
d
g. Step 6: Set s m mod n.
h. Step 7: Set S I2OS( s, OctetLength( n ) ).
6.6.3.1.3 RSA, SSA, PSS

This functionality is not visible at the physical interface. It will be used internally.
Input: M1 any octet string representing the recoverable part of the message M to
be signed.
h(M2) any octet string representing the hash value which is calculated from the
non recoverable part of the message to be signed M.

Errors:
Notation: sig = RSA_PSS_SIGN( PrK, M1, h(M2) )
(N33.00)
According to [ISO9796-2] Clauses 7 and 9, the COS MUST perform the following op-
erations using these definitions: n = PrK.n, d = PrK.d
a. Step 1: Message representative production: Calculate the representation F of the
message M according to [ISO9796-2] Clause 9.2. whereas t = 1 and Ls = Lh MUST
be set and the hashfunction SHA-256 (see (N13.00)) MUST be used. In detail:
i. Set C = I2OS( BitLength( OS2BS( M1 ) ), 8)
ii. Set S = RAND( 32 )
iii. Calculate H = SHA_256( C || M1 || h(M2) || S )
iv. Calculate F according to [ISO9796-2] Clause 9.2.2.
b. Step 2: signature production: according to [ISO9796-2] Clause 7.1.4 and [ISO9796-
2] Annex A.6 the following operations will be performed:
i. Step 2.1: J = OS2I( F )
ii. Step 2.2: a = Jd mod n
iii. Step 2.3: sig = I2OS( a, OctetLength( n ) )
6.6.3.1.4 RSA, ISO9796-2, DS2, SIGN

the physical interface (see (N912.00)a). It will be used as follows:
Input: M1 any octet string representing the recoverable part of the message M to
be signed.
h(M2) any octet string representing the hash value which is calculated from
the non recoverable part of the message to be signed M.
Errors:
Notation: sig = RSA_ISO9796_2_DS2_SIGN( PrK, M1, h(M2) )
(N34.00)
According to [ISO9796-2] Clauses 7 and 9, the COS MUST perform the following op-
erations using this definition: n = PrK.n,
a. Step 1: a = OS2I( RSA_PSS_SIGN( PrK, M1, h(M2) )).
b. Step 2: b =na
c. Step 3: c = min{ a, b }
d. Step 4: sig = I2OS( c, OctetLength( n ) )
6.6.3.1.5 RSASSA-PSS-SIGN
Using the command INTERNAL AUTHENTICATE (see (N895.00)d) and the command PSO:
COMPUTE DIGITAL SIGNATURE (see (N912.00)c) this functionality is visible at the physical
interface. It will be used as follows:
Input: mHash any octet string representing the hash value of the message to be
signed M.
Output: S Octet string representing the signature
Errors:
Notation: S = RSASSA_PSS_SIGN( PrK, mHash )
(N35.00)
According to [PKCS#1], Clauses 8.1.1, 9.1.1 the COS MUST perform the following
operation:
a. Step 1: M1 = (M1 is an empty octet string)
b. Step 2: S = RSA_PSS_SIGN( PrK, M1, mHash ).
6.6.3.2 Signature calculation with ELC, G2 (informative)
the physical interface (see (N912.00)d). It will be used as follows:
Input: H any octet string representing a hash value
PrK a private ELC-key according to Clause 8.2.3
Output: R Octet string, first part of the ECDSA-signature
S Octet string, second part of the ECDSA-signature
Errors:
Notation: ( R, S ) = ELC_SIG(PrK, H)
(N36.00)
According to [TR-03111] Clause 4.2.1 the COS MUST perform the following opera-
tions using these definitions:
n = PrK.domainParameter.n, G = PrK.domainParameter.G,
dA = PrK.domainParameter.d, L = PrK.domainParameter.L
a. Step 1: k RNG({1,2, , n 1}).
b. Step 2: Q [k] G with Q = ( xQ, yQ ).
c. Step 3: r OS2I( FE2OS(xQ) ) mod n.
If r = 0, then continue with step 1
d. Step 4: kinv k1 mod n.
e. Step 5: s kinv ( r dA + OS2I( H ) ) mod n.
If s = 0, then continue with step 1.
f. Step 6: R I2OS( r, L ).
S I2OS( s, L ).
6.6.4 Signature Validation
In this document validation of a signature only means the operation processed with the
public key. This functionality is not directly visible at the physical interface. It will be used
internally. In the context of several internal operations in the operating system of a smartcard
the signature validation as a function will be used as described in the following.
6.6.4.1 RSA, ISO9796-2, DS1, VERIFY, G1 (normative)
Input: PuK a public RSA-key as described in Clause 8.2.4
sig any octet string representing a signature
M2 any octet string representing the non recoverable part of the message M.
M2 MAY be empty.
Output: out Boolean: True if the signature is valid; otherwise False
M Octet string, the reconstructed message
Errors:
Notation: ( out, M ) = RSA_ISO9796_2_DS1_VERIFY( PuK, sig, M2 )
(N37.00)
According to [ISO9796-2] Clauses 7.2 the COS MUST perform the following operations
using these definitions: n = PuK.n, e = PuK.e
a. Step 1: signature opening: according to [ISO9796-2] Annex A.5:
i. Step 1.1: if the bit length of sig is not equal to the bit length of modulus n, then
return False and terminate this algorithm.
ii. Step 1.2: if the most significant bit of sig has the value 1, then return False
iii. Step 1.3: s = OS2I( sig ).
iv. Step 1.4: J* = se mod n.
v. Step 1.5: If J* is even then set I* = J*,
otherwise set I* = n J*.
vi. Step 1.6: If I* mod 256 is not equal to BC, then return False and terminate
this algorithm.
vii. Step 1.7: F* = I2OS( I*, OctetLength( n ) ).
viii. Step 1.8: If the most significant bit of F* has the value 1, then return False
b. Step 2: message recovery; according to [ISO9796-2] Clause 8.3:
i. Step 2.1: If the second significant bit of F* has the value 0, then return False
ii. Step 2.2: Calculate H* and M1* according to [ISO9796-2] Clause 8.3.
iii. Step 2.3: Calculate M = M1 || M2.
iv. Step 2.4: Calculate H = SHA_256( M ).
v. Step 2.5: If H is identical with H*, then return True and M otherwise return
False without M.
Note: Keep in mind that F* in (N37.00) is an octet string. From this F* a bit string will be emerged by
cutting off the most significant bit. This bit string complies with F* [ISO9796-2] Clause 8.3.
Therefore the second important bit will be checked in (N37.00)b.i and in [ISO9796-2] Clause 8.3
the leftmost bit.
6.6.4.2 Signature Validation with elliptical curves, G2 (informative)
Input: PuK a public ELC-key according to Clause 8.2.4
H any octet string representing a hash value
R Octet string, first part of the ECDSA-signature
S Octet string, second part of the ECDSA-signature
Output: out Boolean, True, if the signature is valid, otherwise False
Errors:
Notation: out = ELC_VER_SIG(PuK, R, S, H)
(N38.00)
According to [TR-03111] Clause 4.2.2 the COS MUST perform the following operations
using this definitions:
n = PuK.domainParameter.n, G = PuK.domainParameter.G,
Pa = PuK.P
a. Step 0: r OS2I( R ).
s OS2I( S ).
b. Step 1: check whether r and s are elements of the set {1, 2, , n 1}.
If not return False and terminate the algorithm.
c. Step 2: sinv s1 mod n.
d. Step 3: u1 sinv OS2I ( H ) mod n.
u2 sinv r mod n.
e. Step 4: Q [u1] G + [u2] Pa.
f. Step 5: v OS2I ( FE2OS(xQ) ) mod n.
g. Step 6: Return True if v = r , otherwise False.

6.7 Confidentiality of data, symmetric case
6.7.1 Symmetric encryption
The symmetric encryption transfers any plaintext (octet string of any content and any length)
into a cipher text. This functionality is not directly visible at the physical interface. In the con-
text of several internal operations in the operating system of a smartcard the symmetric en-
cryption as a function will be used as described in the following
6.7.1.1 Encryption 3TDES, G1 (normative)
Input: P Octet string, plaintext, any octet string of any length to be en-
crypted
K any octet string with a length of 24 octets to be used as a key
T1 any number having no negative value, to be used as initial value
Output: C Octet string, cipher text
Errors: lengthError the length of P is not a multiple of the block length.
Notation: C = 3TDES_CBC_ENC( K, T1, P )
(N39.00)
The COS MUST calculate C from P using K and T. The following steps have to be per-
formed:
a. Step 1: If OctetLength( P ) mod 8 is not equal to 0, then return lengthError and ter-
minate the algorithm.
b. Step 2: Divide P in blocks of 64 bits each P = P1 || P2 || || Pn.
c. Step 3: Set C0 = I2OS( T1, 8 )
d. Step 4: Calculate Ci = 3TDES_ENC( K, Ci1 XOR Pi ) for i = 1,, n.
e. Step 5: Calculate C = C1 || C2 || || Cn1 || Cn.
6.7.1.2 Encryption with AES-128, G2 (informative)
Input: P Octet string, plaintext, any octet string of any length to be encrypted
K any octet string with a length of 16 octets to be used as a key
T1 any number having no negative value, to be used as initial value for the
counter
Output: C Octet string, cipher text, having the same length as P
Tn+1 Positive number, to be used as T1 for the next operation with K

Errors:
Notation: ( C, Tn+1 ) = AES_CTR_ENC( K, T1, P )
(N40.00)
The COS MUST calculate C and Tn+1 from P using K according to [AES-CTR] Clause
6.5. The following steps have to be performed:
a. Divide P in blocks P = P1 || P2 || || Pn1 || P*n.
The blocks P1 to Pn1 have a length of 128 bits. The block P*n has a length which is
equal to or less than 128 bits.
b. Set Oj = AES_ENC(K, I2OS(T1 + j 1, 16)) for j = 1, 2, , n.
c. Set Cj = Pj XOR Oj for j = 1, 2, , n 1.
d. Set C*n = P*n XOR Extract_MSByte( On, OctetLength( P*n ) ).
e. Set C = C1 || C2 || || Cn1 || C*n
f. Set Tn+1 = T1 + n
6.7.2 Symmetric Decryption
The symmetric decryption transfers a cipher text (octet string of any content and any length)
into a plaintext. This functionality is not directly visible at the physical interface. In the context
of several internal operations in the operating system of a smartcard the symmetric decryp-
tion as a function will be used as described in the following.
6.7.2.1 Decryption with 3TDES, G1 (normative)
Input: C any octet string, cipher text, to be decrypted; the length being a
multiple of the block length.
K any octet string with a length of 192 bit to be used as a key
T1 any number having no negative value, to be used as initial

value
Output: P Octet string, plaintext
Errors: InvalidLength The length of C is not a multiple of the block length
Notation: P = 3TDES_CBC_DEC( K, T1, C )
(N41.00)
The COS MUST calculate P from C using K and T1. The following steps have to be per-
formed:
a. Step 0: If length of C is not a multiple of the block length, then return InvalidLength
and terminate the algorithm.
b. Step 1: Divide C into blocks with a length of 64 bits each
C = C1 || C2 || || Cn.

c. Step 2: Set C0 = I2OS( T1, 8)
d. Step 3: Calculate Pi = 3TDES_DEC( K, Ci ) XOR Ci1 for i = 1,,n.
e. Step 4: Calculate P = P1 || P2 || || Pn1 || Pn.
6.7.2.2 Decryption with AES-128, G2 (informative)
Input: C any octet string, cipher text, of any length to be deciphered
K any octet string with a length of 128 bits to be used as a key
T1 any number having no negative value, to be used as initial value for the
counter
Output: P Octet string, plaintext, with the same length as C
Tn+1 Positive number, to be used as T1 for the next operation with K
Errors: none
Notation: ( P, Tn+1 ) = AES_CTR_DEC( K, T1, C )
(N42.00)
It applies: ( P, Tn+1 ) = AES_CTR_DEC( K, T1, C ) = AES_CTR_ENC( K, T1, C ).
6.8 Data confidentiality, asymmetric case
6.8.1 Asymmetric Encryption
The asymmetric encryption transfers a message M (octet string of any content and any
length) into a cipher text C. This functionality is not directly visible at the physical interface. In
the context of several internal operations in the operating system of a smartcard the asym-
metric encryption as a function will be used as described in the following:
6.8.1.1 RSA, ES, PKCS1 V1.5, G1 (normative)
Input: PuK a public RSA-key according to Clause 8.2.4.1
M any octet string, message to be encrypted
Output: C Octet string, cipher text of the message M
Errors: ERROR if one of the following cases occurs:
message too long, if M is too long

Note: as long as this function is used in the context of PSO: TRANSCI-
PHER this situation does not occur
Notation: C = RSAES_PKCS1_V1_5_ENCRYPT( PuK, M )

(N43.00)
The COS MUST calculate C using PuK and M according to [PKCS#1] Clause 7.2.1 us-
ing the definitions n = PuK.n, e = PuK.e.
a. Step 0: Set Plen OctetLength( n ) OctetLength( M ) 3.
b. If Plen is less than 8, then terminate the algorithm and return the error message
message too long.
c. Step 1: Set EM 00 || M.
d. Step 2: Set PS RAND( 1 ).
e. Step 3: If PS equals 00, then continue with step 2
f. Step 4: Set EM PS || EM.
g. Step 5: If OctetLength( EM ) is less than OctetLength( n ) 2, then continue with
step 2
h. Step 6: Set EM 02 || EM.
i. Step 7: Set m OS2I( EM ).
j. Step 6: Set c me mod n.
k. Step 7: Set C I2OS( c, OctetLength( n ) ).
6.8.1.2 RSA, OAEP, Encryption, G1 (normative)
Input: PuK a public RSA-key according to Clause 8.2.4.1
M any octet string, message to be encrypted
Output: C Octet string, cipher text of the message M
Errors: ERROR if one of the following cases occurs:
message too long, if M is too long

Note: as long as this function is used in the context of PSO: TRANSCI-
PHER this situation does not occur
Notation: C = RSAES_OAEP_ENCRYPT( PuK, M )
(N44.00)
The COS MUST calculate C using PuK and M according to [PKCS#1] Clause 7.1.1 us-
ing the definitions n = PuK.n, e = PuK.e.
a. Step 1: If OctetLength( M ) is greater than OcetLength( n ) 66, then terminate the
algorithm and return the error message message too long.
b. Step 2: Set L = , (empty octet string).
c. Step 3: Set lHash = SHA_256( L ).
d. Step 4: Set Plen = OctetLength( n ) OctetLength( M ) 66.
e. Step 5: Set PS = I2OS( 0, Plen ).
f. Step 6: Set DB = lHash || PS || 01 || M.
g. Step 7: Set seed = RAND( 32 ).
h. Step 8: Set dbMask = MGF( seed, Octetlength( n ) 33 ).
i. Step 9: Set maskedDB = DB XOR dbMasked.
j. Step 10: Set seedMask = MGF( maskedDB, 32 ).
k. Step 11: Set maskedSeed = seed XOR seedMask.
l. Step 12: Set EM = 00 || maskedSeed || maskedDB.
m. Step 13: Set m = OS2I( EM ).
n. Step 14: Set c = me mod n.
o. Step 15: Set C = I2OS( c, OctetLength( n )).
6.8.1.3 ELC Encryption, G2 (informative)
Input: M Octet string, message of any content and any length to be en-
crypted
POB Octet string, public point PB of the receiver
dP Domain parameter, according to (N86.00)
Output: POA Octet string, ephemeral point PEA of the sender
C Octet string, cipher text of the message M
T Octet string, MAC of the cipher text C
Errors: ERROR if the result of step 5 is the point at infinity
Notation: ( POA, C, T ) = ELC_ENC( M, POB, dP )
(N45.00)
The COS MUST calculate POA, C and T using M and POB. The steps 1 to 6 are per-
formed according to Clause 4.3.1 in [TR-03111] and the following definitions are used:
n = dP.n, h = dP.h,
G = dP.G, L = dP.L
a. Step 0: PB OS2P( POB, dP ).
If this function terminates with an error, then return ERROR and terminate this al-
gorithm.
b. Step 1: r RNG({1, 2, , n 1}).
c. Step 2: PEA [r] G.
d. Step 3: l h1 mod n.
e. Step 4: Q [h] PB.
f. Step 5: S [ r l mod n ] Q with S=(xS, yS).
If S equals the point of infinity O of the curve, then return ERROR and terminate
this algorithm.
g. Step 6: KAB I2OS( xS, L ).

h. Step 7: Calculate derived keys according to (N15.00)
( Kenc, T1, Kmac, SSC ) KeyDerivation_AES128( KAB ).
i. Step 8: POA P2OS( PEA, L ).
j. Step 9: (C, x) AES_CTR_ENC( Kenc, T1, M ).
k. Step 10: T AES_CMAC( Kmac, C ).
Note 1: the return value SSC in step 7 will never be used here
Note 2: the return value x in step 9 will never be used here
6.8.2 Asymmetric Decryption
The asymmetric decryption transfers a cipher text C into a message M.
6.8.2.1 RSA, ES, PKCS1 V1.5, Decrypt, G1 (normative)
This functionality is visible in the context of the command PSO: DECIPHER at the physical
interface (see (N945.00)a).
Input: PrK a private key according to Clause 8.2.3
C any octet string, cipher text of the message M
Output: M Octet string, plaintext of the cipher text
Errors: ERROR decryption error, if one of the following cases occurs:
numerically C is greater than the modulus
EM does not start with 0002
In EM no 00 octet exists which separates PS from M
PS has less than 8 octets
Notation: M = RSAES_PKCS1_V1_5_DECRYPT( PrK, C )
(N46.00)
The COS MUST calculate M using PrK and C according to [PKCS#1] Clause 7.2.2 us-
ing these definitions: n = PrK.n, d = PrK.d
a. Step 1: If OctetLength( C ) is not equal to OctetLength( n ), then terminate this algo-
rithm with decryption error.
b. Step 2: Set c = OS2I( C ).
c. Step 3: If c is greater than or equal to n, then terminate this algorithm with decryp-
tion error.
d. Step 4: Set EM = I2OS( cd mod n, OctetLength( n )).
e. If the first octet in EM is not equal to 00, or the second octet in EM is not equal to
02, then terminate this algorithm with decryption error.
f. Step 5: Split EM as follows: EM = 00 02 || PS || 00 || M. Each octet in PS
MUST be unequal to 00.
g. Step 6: Terminate this algorithm with decryption error, if

i. PS is shorter than 8 octets, or
ii. no octet with the value 00exists, which separates PS from M.
h. Step 7: return M
Note: The check in Step 1 is not necessary as the case does not occur in the context of this specifica-
tion because of (N928.00) Furthermore, Step 3 checks more strictly.
6.8.2.2 RSA, OAEP, Decrypt, G1 (normative)
interface (see (N945.00)b).
Input: PrK a private key according to Clause 8.2.3
C any octet string, cipher text of the message M
Errors: ERROR decryption error, if the following error occurs:
numerically C is greater than the modulus
Notation: M = RSAES_OAEP_DECRYPT( PrK, C )
(N47.00)
The COS MUST calculate M using PrK and C according to [PKCS#1] Clause 7.1.2 us-
ing these definitions: n = PrK.n, d = PrK.d
a. Step 1: Set L = , (empty octet string).
b. Step 2: Set c = OS2I( C ).
c. Step 3: If c is greater than or equal to n, then terminate this algorithm with decryp-
tion error.
d. Step 4: Set m = cd mod n.
e. Step 5: Set EM = I2OS( m, OctetLength( n ) ).
f. Step 6: Set lHash = SHA_256( L ).
g. Step 7: Divide EM as follows:
i. Step 7.1: EM = Y || maskedSeed || maskedDB.
ii. Step 7.2: 1 = OctetLenght( Y ).
iii. Step 7.3: 32 = OctetLength( maskedSeed ).
h. Step 8: Set seedMask = MGF( OS2BS( maskedDB ), 256, 0 ).
i. Step 9: Set seed = OS2BS( maskedSeed ) XOR seedMask.
j. Step 10: Set dbMask = MGF(seed, 8 OctetLength(maskedDB),0).
k. Step 11: Set DB = maskedDB XOR BS2OS( dbMask ).
l. Step 12: Split DB as follows:
i. Step 12.1: DB = lHash || PS || 01 || M.
ii. Step 12.2: 32 = OctetLength(lHash).
iii. Step 12.3: the octet string PS (possibly empty) may only contain octets
with the value 00.
m. Step 13: Terminate this algorithm with decryption error, if
i. lHash is not equal to lHash, or
ii. Y has not the value 00, or
iii. No octet with the value 01 exists, which separates PS from M .
n. return M
6.8.2.3 Asymmetric Decryption with ELC, G2 (informative)
interface (see (N945.00)c).
Input: PrK a private ELC-key according to Clause 8.2.3
PO Octet string, ephemeral point PEA of the sender
C Octet string, cipher text of the message M
T Octet string, MAC of the cipher text C
Errors: ERROR if PO has not the format uncompressed encoding
if PO represents a point which is not on the same curve as PrK
if the result in step 3 is the point of infinity
if the MAC validation fails
Notation: M = ELC_DEC( PO, PrK, C, T )
(N48.00)
The COS MUST calculate M using PEA, PrK, C and T. The steps 1 to 4 are performed
according to Clause 4.3.2 in [TR-03111] and the following definitions are used:
n = PrK.domainParameter.n, h = PrK.domainParameter.h,
dB = PrK.domainParameter.d, L = PrK.domainParameter.L
a. Step 0: PEA OS2P( PO, PrK.domainParameter ).
If this function terminates with an error, return ERROR and terminate this algo-
rithm.
b. Step 1: l h1 mod n.
c. Step 2: Q [ h ] PEA with Q = ( xQ, yQ ).
d. Step 3: S [ dB l mod n ] Q. with S = ( xS, yS ).
If S is equal to the point of infinity O of the curve, then return ERROR and termi-
nate this algorithm.
e. Step 4: KAB I2OS( xS, L ).
f. Step 5: Calculate derived keys according to 0
( Kenc, T1, Kmac, SSC ) Key_Derivation_AES128( KAB ).

g. Step 6: out = VERIFY_CMAC( Kmac, T, C ).
If out has the value INVALID, then return ERROR and terminate this algorithm.
h. Step 7: (M, x) AES_CTR_DEC( Kenc, T1, C )

Note 1: The return value SSC in step 5 will never be used here
Note 2: The return value x in step 7 will never be used here

7 CV-Certificates (normative)
According to [ISO7816-8] a card verifiable certificate is a certificate which can be validated

by the smartcard. Typically the certificates contain only information which the smartcard
needs for a specific use case. Therefore these certificates are more compact than other for-
mats for certificates, leading to a better performance.
7.1 CV-Certificates for RSA keys, G1 (normative)
In this chapter only non self-descriptive CV-certificates will be regarded, containing a signa-
ture with message recovery as defined in [ISO9796-2] DS1.
Technically such a certificate is a message M signed according to [ISO9796-2] DS1. The
message M contains several data, being concatenated without structural information or sepa-
rators, therefore non self-desriptive as a denotation. To allow an explicit extraction of the
information, the most significant octet of M will be analyzed.
7.1.1 Elements of a CV-Certificate
All signed messages M looked at in Clause 7.1 contain the information described in the fol-
lowing sub-clauses.
7.1.1.1 Certificate Profile Identifier (CPI)
The Certificate Profile Identifier (CPI) indicates the exact structure of a CV-certificate.
7.1.1.2 Certification Authority Reference (CAR)
The Certification Authority Reference (CAR) references the key of the CA issuing the certifi-
cate. Typically the CAR contains an internal structure which guarantees that worldwide the
CAR is unique.The document [PKI-Reg] contains the corresponding definitions.
Typically also the issuing CA has a CV-certificate. Thus a tree of certificates is defined (PKI),
starting with the Root-CA at the top.
The public key of the Root-CA is regarded as the security base. It will be stored in the smart-
card during the preparation phase (see Clause 4). Therefore it is not necessary to import this
public key with the CV-certificate (break of the recursion).
7.1.1.3 Certificate Holder Reference (CHR)
The Certificate Holder Reference (CHR) is used to assign a unique identifier to the public key
being part of the certificate. Typically the unique serial number of the smartcard (ICCSN) is
used as part of the CHR. Within this document it is irrelevant how the CHR is built. The
document [PKI-Reg] contains the corresponding definitions.
7.1.1.4 Certificate Holder Authorization (CHA)
The Certificate Holder Authorization (CHA) indicates the role of the certificate owner. Typi-
cally it is a requirement of the security concept that two different roles below a Root-CA are
not allowed to have the same CHA. Therefore more and more the requirement is raised that
the CHA should be worldwide unique. To achieve this typically a part of the unique applica-
tion identifier is used as part of the CHA. Within this document it is irrelevant how concrete
values will be defined. The document [PKI-Reg] contains the corresponding definitions.
7.1.1.5 Object Identifier (OID)
The Object Identifier (OID) in a CVC describes the algorithm, which is assigned to the key in
the cerificate. Within this specification different algorithms will be used for different purposes.
Therefore the usage of the public key being part of the certificate is defined by the algorithm-
OID in an implicit way. OIDs are worldwide unique.
Within Clause 7.1 only the following OIDs are used:
Table 6: (N48.50) Object Identifier of the Registration Authority TeleTrusT (www.teletrust.de)
OID Name OID Value OID Coding

sigS_ISO9796-2Withrsa_sha256 {1 3 36 3 4 2 2 4} 2B24 0304
0202 04
signature scheme with RSA signature and DSI according to
[ISO9796-2] and [SHA-256]
authS_ISO9796-2Withrsa_sha256_mutual {1 3 36 3 5 2 4} 2B24 0305
0204
authentication scheme with RSA signature and DSI according to
[ISO9796-2] and [SHA-256] for mutual authentication with or
without establishment of a Trusted Channel
7.1.1.6 Public Key
The public RSA-key has the parts defined in the following sub-clauses.
7.1.1.6.1 Modulus
The modulus is hex-coded, unsigned in big endian-format
7.1.1.6.2 Public Exponent

The public exponent is hex-coded, unsigned in big endian-format
7.1.2 Certificate Profiles
This clause lists the certificate profiles to be supported. The certificate profiles will be identi-
fied by means of the CPI.
7.1.2.1 CV-Certificates for CA-keys
In this sub-clause the content of a CV-certificate will be described. It contains the public key
of a CA. With the help of this public key additional public keys can be imported per CV-
certificate using the command PSO: VERIFY CERTIFICATE (see Clause 14.8.8.1). The fol-
lowing conditions have to be fulfilled:
(N49.00)
The CPI MUST have the value 21
(N50.00)
The coding of the OID MUST have a length of seven octets. Within Clause 7.1 only
2B24 0304 0202 04 will be used for the OID {1.3.36.3.4.2.2.4} (see Table 6 (N48.50)).

(N51.00)
The length of the modulus MUST be 28 octets less than the message M
(N52.00)
The public exponent MUST have a length of 4 octets
(N53.00)
The CHR MUST have a length of eight octets
(N54.00)
The CAR MUST have a length of eight octets
(N55.00)
For the message to be signed M the following applies:
M = CPI || modulus || public exponent || OID || CHR || CAR.
CHR and CAR belong to the non recoverable part of the signed message if (N21.00)a is
regarded and the hash value is calculated according to Clause 6.1. Then CHR and CAR are
stored as plaintext.
7.1.2.2 CV-Certificates for authentication keys
In this sub-clause the structure of a CV-certificate will be described which contains the public
key of an entity using this key for authentication purposes. The following conditions have to
be fulfilled for those certificates:
(N56.00)
The CPI MUST have the value 22
(N57.00)
The CHA MUST have a length of seven octets
(N58.00)
The coding of the OID MUST have a length of six octets. Within Clause 7.1 only 2B24
0305 0204 will be used for the OID {1 3 36 3 5 2 4} (see Table 6 (N48.50)).
(N59.00)
The length of the modulus MUST be 38 octets less than the message M
(N60.00)
The public exponent MUST have a length of 4 octets
(N61.00)
The CHR MUST have a length of twelve octets
(N62.00)
The CAR MUST have a length of eight octets
(N63.00)
For the message to be signed M the following applies:
M = CPI || modulus || public exponent || OID || CHA || CHR || CAR.
CHR and CAR belong to the non recoverable part of the signed message if (N21.00)a is
regarded and the hash value is calculated according to Clause 6.1. Then CHR and CAR are
stored as plaintext.
7.1.3 Structure and Content of a CV-Certificate
The content of a certificate data object will be calculated as follows:

(N64.00)
Step 1: the message M MUST be generated according to Clause 7.1.2.
(N65.00)
Step 2: The message M MUST be signed with the private RSA-key PrK. (N31) MUST
be used as the signature method, so that the following applies:
( SIG.CA, M2 ) = RSA_ISO9796_2_DS1_SIGN( PrK, M ).
(N66.00)
An EF for CV-certificates MUST contain a combined certificate data object with tag =
7F21 (RSA-certificate with message recovery). The certificate data object MUST con-
tain exactly two primitive data objects in the specified order:
a. Data element SIG.CA as value in a data object with tag= 5F37.
b. Non-recoverable part M2 as value in a data object with tag = 5F38.
CV-certificates for RSA-keys with a modulus length of 2048 bits = 256 octets:
Table 7: (N66.10) CV-Certificate of a CA with CPI = 21, SHA-256
Tag L Value
7F21 820146 CV-Certificate (0146 = 326 octets)
Tag L Value
5F37 820100 Signature SIG.CA (0100 = 256 octets)
5F38 3E non recoverable part M2 (003E = 62 octets)
Table 8: (N66.20) CV-Certificate for Authentication with CPI = 22, SHA-256
Tag L Value
7F21 820150 CV-Certificate (0150 = 336 octets)
Tag L Value
5F37 820100 Signature SIG.CA (0100 = 256 octets)
5F38 48 non recoverable part M2 (0048 = 72 octets)
7.2 CV-Certificate for ELC keys, G2 (informative)
This clause will be added in a later version of this document.

8 Objects (normative)
8.1 Several Attributs (normative)
This sub-clause describes some attributes which are relevant for several object types.
8.1.1 File Identifier
The attribute type fileIdentifier is used for the object types DF and EF.
The specification of an application has to comply with the following rules defined in the norm
[ISO7816-4]:
(N67.00)
The value of the fileIdentifier MUST be an integer in the interval [1000, FEFF].
(N68.00)
An object not being root (see Clause 9.1) MUST NOT have a fileIdentifier with the
value 3F00.
(N69.00)
An object MUST NOT have a fileIdentifier with the value 3FFF.
Note: Requirement (N67.00) is stronger than [ISO7816-4]. This gives room for manufacturer-specific
folders (DF) and files (EF).
8.1.2 Short File Identifier
It is possible that the attribute type shortFileIdentifier is used by the object types file (see
Clause 8.3.2).
The specification of an application has to comply with the following rule defined in the norm
[ISO7816-4]:
(N70.00)
The value of shortFileIdentifier MUST be an integer in the interval [1, 30].
8.1.3 Life Cycle Status
The attribute type lifeCycleStatus is used by the object types folder, file and record to store a
physical Life Cycle Status (see (N216.00)). The object types password and key only have a
logical Life Cycle Status (see (N217.00)).
The specification of an application has to comply with the following rules defined in the norms
[ISO7816-4] Table 13 and [ISO7816-9] Figure 1:
(N71.00) The value of lifeCycleStatus MUST be an element of the set {
Operational state (activated),
Operational state (deactivated)
}.
A COS MAY support additional values for lifeCycleStatus.
A COS MAY refuse additional values for lifeCycleStatus.

8.1.4 List of Access Rules
The attribute type accessRuleList is used by object types, for which the execution of com-
mands depends on access rules. Normally it is a combination of several access rules. Typi-
cally more than one access rule is assigned to an object, thus allowing the COS to react
situationally. As an example: specific read operations are only allowed via the contact inter-
face whereas they are forbidden for the contactless interface. On the other hand normally the
access to deactivated objects is strictly limited. Additionally security environments are used
to realize access conditions depending on the operational environment.
From an academic point of view it would be necessary to use a 3D-matrix with access condi-
tions: access conditions depending on the interface (contact/contactless = first dimension),
the life cycle (activated/deactivated = second dimension) and the operational environment
(SE-identifier = third dimension).
In this document the first dimension will not be regarded because a contactless interface is
not defined; for the second dimension it is sufficient to look only at the operational environ-
ment in respect to the deactivated state. Therefore in this version of the document a simple
list is used instead of a (multidimensional) matrix.
(N72.00)
The value of accessRuleList MUST be a list of at least two and a maximum of five ele-
ments:
A COS MAY support a list with more elements.
A COS MAY refuse a list with more elements.
(N73.00)
An element of the list MUST be used for the value of the variable lifeCycleStatus =
Operational state (deactivated) (see Clause 8.1.3)
(N74.00)
The remaining elements of the list MUST be assigned to exactly one value of seIdenti-
fier (according to (N79.00)).
(N75.00)
Each element of the list MUST contain exactly one access rule according to Clause
10.3.
8.1.5 Record
The objecttype record will be used by the object types linear variable, linear fixed and cyclic
Elementary File (EF).
(N76.00)
A record MUST have a record number number. The record number MUST be an inte-
ger in the interval [1, 254].
A COS MAY support record numbers with additional values.
A COS MAY refuse record numbers with additional values.
(N77.00)
A record MUST contain an octet string data; the number of included octets MUST be in
the interval [1, 255].
A COS MAY support additional lengths for record.
A COS MAY refuse additional lengths for record.

(N78.00)
A record MUST support a list of attributes of the type lifeCycleStatus (see
Clause 8.1.3). The list is either
a. empty (the record has no lifeCycleStatus and is implicitely in the state Operational
state (activated)) or
b. contains exactly one element (the record has exactly one lifeCycleStatus)
8.1.6 SE-Identifier
The attribute type seIdentifier is closely linked to the term Security Environment (see
Clause 8.7). From the range of values defined in [ISO7816-4] Clause 6.3.3 the following sub-
set will be chosen:
(N79.00)
The value of seIdentifier MUST be an integer in the interval [1, 4].
The COS MAY support additional values for seIdentifier.
The COS MAY refuse additional values for seIdentifier.
8.1.7 PIN
The attribute type pin is used in the context of user authentication. The following applies:
(N80.00)
A pin MUST be a sequence of digits from the set {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}. The num-
ber of digits MUST be in the interval [4, 12].
A COS MAY support additional digits and additional numbers of digits for pin.
A COS MAY refuse additional digits and additional numbers of digits for pin.
(N81.00)
The following rules apply for the conversion of the attribute type pin to a format-2-PIN-
block:
a. The format-2-PIN-block is an octet string with 8 octets = 16 nibbles
b. The first nibble MUST have a value 2.
c. The second nibble MUST code the number of digits in pin in hex.
d. The nibble i + 2 MUST code the digit i of pin in hex
e. All other nibbles MUST have the value F.
8.2 Key Material
8.2.1 Symmetric Keys
8.2.1.1 3TDES keys, G1 (normative)
The attribute type 3TDES_Key acts as a store for a 3TDES-key, which consists of three par-
tial keys Ka, Kb and Kc.
(N82.00)
The value of 3TDES_Key MUST be an octet string of 24 octets.
(N83.00)
The value of 3TDES_Key MUST be selectable without restrictions, but the following
applies for the parity of each octet: If the parity of the octets is not correct, then

a. the COS MAY accept 3TDES_Key.
b. the COS MAY refuse COS 3TDES_Key.
Note 1: For security reasons the partial keys Ka, Kb and Kc have to be pairwise different. This is not a
requirement to the COS, but to the external world, which may load such keys into the smartcard
during the personalization process.
Note 2: For security reasons none of the partial keys Ka, Kb and Kc shall have the value of a weak or
semi-weak DES-key. This is not a requirement to the COS, but to the external world, which may
load such keys into the smartcard during the personalization process.
8.2.1.2 AES keys, G2 (informative)
The attribute type aesKey acts as a store for an AES-128-key.

(N84.00)
The value of aesKey MUST be an octet string of 16 octets.
(N85.00)
The value of aesKey MUST be selectable without restrictions.
This clause may be changed in a later version of this document. Generation2-smartcards may be in the field until
2020. Therefore it is possible, that in Generation 2 AES-256 will be used instead of AES-128 from the beginning.
That has to be discussed.
8.2.2 Domainparameter for elliptical Curves, G2 (informative)
The attribute type domainParameter acts as a store for parameters, which characterise an
elliptical curve. The following rules apply for the specification of applications, compare Table
5 (N26.50):
(N86.00)
domainParameter contains
a. a prime number p,
b. a number a,
c. a number b,
d. a point G on an elliptical curve,
e. a number n,
f. a number h,
g. a number L, which defines the minimum number of octets being necessary to code p
as an unsigned number. This parameter was added to the official list of domain pa-
rameters, because it is used in many cases in this document.
Because of (N25.00) L = 32 applies for all curves which MUST be supported by a

COS.
h. An octet string OID, defining the domain parameters (p, a, b, G, n, h) worldwide
unique. This parameter was added to the official list of domain parameters, be-
cause domain parameters are in many cases referenced per OID in this document.

8.2.3 Private Key
The attribute type privateKey acts as a generic term for privateRsaKey and privateElcKey.
8.2.3.1 Private RSA Key, G1 (normative)
The attribute type privateRsaKey acts as a store for the private part of an asymmetric RSA-
keypair. The following rules apply for the specification of applications:
(N87.00)
A privateRsaKey MUST have an attribute n according to (N21.00).
(N88.00)
A privateRsaKey MUST have an attribute d with an integer value in the interval [1, n
1].
8.2.3.2 Privat ELC Key, G2 (informative)
The attribute type privateElcKey acts as a store for the private part of an asymmetric ELC-
(N89.00)
A private privateElcKey MUST have an attribute domainParameter according to
(N86.00), which MAY be referenced per OID according to (N86.00)h.
(N90.00)
A privateElcKey MUST have an attribute d, with an integer value in the interval [1, n
1].
8.2.4 Public Key
8.2.4.1 Public RSA Key, G1 (normative)
The attribute type publicRSAKey acts as a store for the public part of an asymmetric RSA-
(N91.00)
A publicRsaKey MUST have an attribute n according to (N21.00)a.
(N92.00)
A publicRsaKey MUST have an attribute e according to (N21.00)b.
8.2.4.2 Public ELC Key, G2 (informative)
The attribute type publicElcKey acts as a store for the public part of an asymmetric ELC-
(N93.00)
A publicElcKey MUST have an attribute domainParameter according to (N86.00),
which MUST be referenced per OID according to (N86.00)h.
(N94.00)
A publicElcKey MUST have an attribute P which describes a point of the curve defined
by the domain parameters.
8.2.5 Transport security for a Password (normative)
The attribute type transportStatus defines whether a password is protected by a transport

security mechanism. The value of this attribute defines also if the command VERIFY is pos-

sible (see (N853.00)) and which variant of CHANGE REFERENCE DATA has to be used. At
the external interface of the COS this attribute type is used with the command GET PIN
STATUS (see Table 106 (N804.50)).
(N95.00)
For transportStatus the following values are allowed:
a. regularPassword
b. Empty_PIN_1
c. Empty_PIN_2
d. Transport_PIN_0000
e. Transport_PIN_random
f. Transport_PIN_derived
g. Transport_PIN_fixedValue
(N96.00)
The COS MUST support the value regularPassword.
The COS MUST support at least one value from the set { Transport_PIN_random,
Transport_PIN_derived, Transport_PIN_fixedValue }.
A COS MAY support additional values for transportStatus, also values not being de-
fined in (N95.00).
A COS MAY refuse other values for transportStatus.
(N97.00)
If the command CHANGE REFERENCE DATA is used to suspend the transport secu-
rity (see (N772.00)b.iii), then depending on the value of transportStatus at the physi-
cal interface a variant according to Table 9 (N98.50) MUST be chosen.
(N98.00)
If oldSecret or newSecret are not mentioned for a specific variant, their content MUST
be freely selectable within the bounds of (N80.00) and (N81.00).
Note: The transport security can also be suspended with the command RESET RETRY COUNTER ,
see use cases in Clause 14.6.5.1 and Clause 14.6.5.3 as well as (N837.00)b.
Table 9: (N98.50) Coding of Transport Security
Transport Security Parameters for CHANGE REFERENCE DATA

regularPassword P1=00
Empty_PIN_1 P1=01
Empty_PIN_2 P1=00, oldSecret = 20FF FFFF FFFF FFFF
Transport_PIN_0000 P1=00, oldSecret = 2400 00FF FFFF FFFF
Transport_PIN_random P1=00
Transport_PIN_derived P1=00
Transport_PIN_fixedValue P1=00
8.3 File (normative)
This sub-clause describes file-oriented object types. In this context file is used as a generic
term for folder (see Clause 8.3.1) and file (see Clause 8.3.2).
8.3.1 Folder
Folders are used for the hierachical arrangement of objects in an object oriented system. In
this document the term folder is used as a generic term for:
Applications (Clause 8.3.1.1),
Dedicated Files (Clause 8.3.1.2) and
Application Dedicated Files (Clause 8.3.1.3)
The specification of an application has to comply with the following rules for folders defined in
the norm [ISO7816-4]:
(N99.00)
A folder MUST have exactly one attribute of the type lifeCycleStatus (see
Clause 8.1.3).
(N100.00)
A folder MUST have exactly one attribute of the type accessRuleList (see Clause 8.1.4.
(N101.00)
A folder MUST have a list children (possibly empty) with child objects.
a. The following object types (considering the maximum number of nestings) MUST be
supported as list elements (see (N215.00))
Dedicated File (see Clause 8.3.1.2)
Application Dedicated File (see Clause 8.3.1.3)
File (see Clause 8.3.2)
Password (see Clause 8.4)
Symmetric object for authentication (see Clause 8.5.1)
private key object (see Clause 8.5.3)
b. The COS MAY support additional object types as list elements.
The COS MAY refuse additional object types as list elements.
c. For all elements of the list children, which contains the child objects of a folder, it
applies: the list children of a folder MUST NOT contain child objects,
i. whose attribute fileIdentifier (if available, see (N108.00) and (N110.00) has the
same value.
ii. whose attribute shortFileIdentifier (if available, see (N111.00) has the same
value.
iii. whose attribute pwdIdentifier (if available, see (N153.00) has the same value.
iv. whose attribute keyIdentifier (if available, see (N167.00) and (N184.00) has
the same value.
(N102.00)
A folder MUST have exactly one attribute shareable of the type Boolean. In the context
of this specification the value of this attribute MUST be always True. This indicates
that this folder can be used as currentFolder in more than one logical channel (see
(N321.00)a).
Note: in (N101.00)a applications (see Clause 8.3.1.1) are deliberately not included, compare also
(N213.00)).
Additional channel-specific attributes are assigned to a folder, typically allocated to a channel

context (see (N322.00)) stored in a volatile memory (e.g. a RAM). Typically they are changed
in the context of folder selection, but also in the context of user verification or component
authentication.
8.3.1.1 Application
An application is a folder, which can only be selected by an AID. This is the main difference
to a DF (see Clause 8.3.1.2).
The specification of an application has to comply with the following rules defined in the norm
[ISO7816-4]:
(N103.00)
An application is an extension of a folder and MUST fulfill the requirements of Clause
8.3.1.
(N104.00)
The attribute applicationIdentifier (AID) MUST be an octet string.
a. The length of applicationIdentifier MUST be in the interval [5, 16].
b. The octets in applicationIdentifier MUST be selectable without any restriction.
c. A COS MAY accept applicationIdentifier violating these rules.
A COS MAY refuse applicationIdentifier violating these rules.
(N105.00)
An application MUST have at least one applicationIdentifier.
(N106.00)
An application MUST have NOT more than two applicationIdentifier.
A COS MAY accept more than two applicationIdentifier for applications.
8.3.1.2 Dedicated File
A Dedicated File (DF) is a folder, which can only be selected by a File Identifier. This is the
main difference to an application (see Clause 8.3.1.1).
The specification of an application has to comply with the following rules defined for a DF in
(N107.00)
A DF is an extension of a folder and MUST fulfill the requirements of Clause 8.3.1.
(N108.00)
A DF MUST have exactly one attribute of the type fileIdentifier (see Clause 8.1.1)).
8.3.1.3 Application Dedicated File
An Application Dedicated File (ADF) is a folder which can be selected by the applicationIden-
tifier as well as by the fileIdentifier. In this document ADF is regarded as the set union of
application (Clause 8.3.1.1) and DF (Clause 8.3.1.2). Accordingly for an ADF the following
rule applies, which have to be fulfilled by the specification of an application:
(N109.00)
An ADF MUST combine the characteristics of application and DF. Therefore it MUST
fulfill both the requirements of Clause 8.3.1.1 and Clause 8.3.1.2.
8.3.2 File
In this document a file is the generic term for a transparent EF (see Clause 8.3.1.2) and a
structured EF (see Clause 8.3.2.2).
The specification of an application has to comply with the following rules defined for a file in
(N110.00)
A file MUST have exactly one attribute of the type fileIdentifier (see Clause 8.1.1).
(N111.00)
A file MUST support a list of elements of the type shortfileIdentifier (see Clause 8.1.2).
this list is either
a. empty (the file has no shortFileIdentifier) or

b. contains exactly one element (the file has exactly one shortFileIdentifier)
(N112.00)
A file MUST have exactly one attribute of the type lifeCycleStatus (see Clause 8.1.3)
(N113.00)
A file MUST have exactly one attribute of the type accessRuleList (see Clause 8.1.4).
(N114.00)
A file MUST have an attribute flagTransactionMode of the Boolean type.
A COS MAY manage such an attribute per file individually.
A COS MAY set this attribute implicitely for all files to True.
(N115.00)
A file MUST have an attribute flagChecksum of the Boolean type
A COS MAY manage such an attribute per file individually.
A COS MAY set this attribute implicitely for all files to True.
(N116.00)
A file MUST have exactly one attribute shareable of the type Boolean. In the context of
this specification the value of this attribute MUST be always True. This indicates that
this file can be used as currentEF in more than one logical channel (see (N322.00)b).
Note 1: Setting the Flag flagTransactionMode reduces the performance of write operations.
Note 2: Setting the Flag flagChecksum reduces the performance of write and read operations.
8.3.2.1 Transparent Elementary File
A transparent elementary file (transparent EF) serves to store octet strings, whereas it is
possible to access any part of the octet string. The content of octet strings in transparent EF
being defined in the context of an application is merely stored but will never be interpreted or
used internally by the COS. The octet strings are divided into data units (see [ISO7816-4]).
The data units are referenced by an offset value.
The specification of an application has to comply with the following rules defined for a trans-
parent EF in the norm [ISO7816-4]:
(N117.00)
A transparent EF is an extension of a file and MUST comply with the requirements of
Clause 8.3.2.
(N118.00)
A transparent EF MUST have exactly one attribute numberOfBytes; the value MUST
be an integer in the interval [1, 32768].
A COS MAY refuse numberOfBytes if it is out of this interval.
A COS MAY accept numberOfBytes if it is out of this interval.
(N119.00)
A transparent EF MUST have an attribut body of the type octet string. The number of
octets in body is equal to the numberOfBytes.
(N120.00)
The size of one data unit in body MUST be 1 octet.
(N121.00)
The offset of the first octet in body is zero. If i is the offset of the octet i, than (i+1) is the
offset of the next octet.
(N122.00)
A transparent EF MUST support the following commands:

a. ERASE BINARY (see Clause 14.3.1)
READ BINARY (see Clause 14.3.2),
UPDATE BINARY (see Clause 14.3.4).
The transparent EF has to be selected, before these commands can work with the
octet string. This can be done either with the SELECT command (see
Clause 14.2.6.13 and Clause 14.2.6.14), or with the Short File Identifier being a pa-
rameter of the command sequence.
b. ACTIVATE (see Clause 14.2.1),
DEACTIVATE (see Clause 14.2.3),
DELETE (see Clause 14.2.4).
octet string. This is done with the SELECT command (see Clause 14.2.6.13 and
Clause 14.2.6.14).
(N123.00)
A transparent EF MAY support additional commands.
A transparent EF MAY refuse additional commands.
8.3.2.2 Structured Elementary File
A structured Elementary File (structured EF) serves to store a list of records (see Clause
8.1.5). Access to any list element is possible. The content of an octet string of a record in a
structured EF being defined in the context of an application is merely stored but will never be
interpreted or used internally by the COS.
The specification of an application has to comply with the following rules defined for a struc-
tured EF in the norm [ISO7816-4]:
(N124.00)
A structured EF is an extension of a file and MUST comply with the requirements of
Clause 8.3.2.
(N125.00)
A structured EF MUST have exactly one attribute recordList of the type list with ele-
ments of the type record. The number of list elements MUST be in the interval [0, 254].
A COS MAY accept a greater number of list elements.
A COS MAY refuse a greater number of list elements.
(N126.00)
The element i in recordList MUST have the record number i.
(N127.00)
A structured EF MUST have exactly one attribute maximumNumberOfRecords. Its
value MUST be an integer in the interval [1, 254].
A COS MAY accept maximumNumberOfRecords if its value is outside this interval.
A COS MAY refuse maximumNumberOfRecords if its value is outside this interval.
(N128.00)
A structured EF MUST have exactly one attribute maximumRecordLength; its value
MUST be an integer in the interval [1, 255].
A COS MAY accept maximumRecordLength if its value is outside this interval.
A COS MAY refuse maximumRecordLength if its value is outside this interval.
(N129.00)
A structured EF MUST have exactly one attribute flagRecordLifeCycleStatus of the
Boolean type. If this attribute
a. is True then all elements in recordList MUST have a lifeCycleStatus.
b. is False then NO element in recordList MUST have a lifeCycleStatus.
(N130.00)
A structured EF MUST support the following commands:
a. ACTIVATE RECORD (see Clause 14.4.1),
APPEND RECORD (see Clause 14.4.2),
DEACTIVATE RECORD (see Clause 14.4.3),
ERASE RECORD (see Clause 14.4.4),
READ RECORD (see Clause 14.4.5),
SEARCH RECORD (see Clause 14.4.6),
UPDATE RECORD (see Clause 14.4.7).
octet string. This can be done either with the SELECT command (see
Clause 14.2.6.13 and Clause 14.2.6.14), or with the Short File Identifier being a pa-
rameter of the command sequence.
b. ACTIVATE (see Clause 14.2.1),
DEACTIVATE (see Clause 14.2.3),
DELETE (see Clause 14.2.4).
octet string. This is done with the SELECT command (see Clause 14.2.6.13 and
Clause 14.2.6.14).
(N131.00)
A structured EF MAY support additional commands.
A structured EF MAY refuse additional commands.
8.3.2.2.1 Linear variable Elementary File

A linear variable Elementary File (linear variable EF) serves to store a list of elements of the
type record (see Clause 8.1.5). It is possible that the number of octets in each list element is
different.
The specification of an application has to comply with the following rules defined for a linear
variable EF in the norm [ISO7816-4]:
(N132.00)
A linear variable EF is an extension of the structured EF and MUST comply with the
requirements of Clause 8.3.2.2.
(N133.00)
A linear variable EF MUST have exactly one attribute numberOfBytes. Its value MUST
be an integer in the interval [1, 64770].
(64770 = 254 records x 255 octets per record).
A COS MAY accept numberOfBytes if its value is out of this interval.
A COS MAY refuse numberOfBytes if its value is out of this interval.
(N134.00)
If a new record is added to the list with the command APPEND RECORD, this record
MUST be added at the end of the list.
8.3.2.2.2 Linear fix Elementary File

A linear fix Elementary File (linear fix EF) serves to store a list of elements of the type record
(see Clause 8.1.5). The number of octets in the octet string of each list element is the same.
The specification of an application has to comply with the following rules defined for a linear
fix EF in the norm [ISO7816-4]:

(N135.00)
A linear fix EF is an extension of the structured EF and MUST comply with the re-
quirements of Clause 8.3.2.2.
(N136.00)
In each record in recordList the number of octets MUST be maximumRecordLength.
(N137.00)
MUST be added at the end of the list.
8.3.2.2.3 Cyclic Elementary File

A cyclic Elementary File (cyclic EF) is used to store a list of elements of the type record (see
Clause 8.1.5). The number of octets in the octet string of each list element is the same.
The specification of an application has to comply with the following rules defined for a cyclic
EF in the norm [ISO7816-4]:
(N138.00)
A cyclic EF is an extension of the structured EF and MUST comply with the require-
ments of Clause 8.3.2.2.
(N139.00)
In each record in recordList the number of octets MUST be maximumRecordLength.
(N140.00)
MUST be added at the beginning of the list.
(N141.00)
Cyclic Elementary Files MUST use the value False for the attribute flagRecordLifeCy-
cleStatus.
8.3.3 File Control Parameter
The File Control Parameters (FCP) contain attributes of a file. In the context of this document
the FCP are only visible in the response data of a SELECT command (see (N510.00)a) at
the interface of the interpreter (see Figure 1 (N270.50)). For the coding of the File Control
Parameters the following rule apply:
(N142.00)
According to DER-TLV the File Control Parameters (FCP) MUST be coded in a
DO_FCP which MUST have a tag = 62.
(N143.00)
80: If the file is of the type transparent EF (see Clause 8.3.2.1) or linear variable EF
(see Clause 8.3.2.2.1), then DO_FCP MUST contain a DO_Size. It applies:
a. DO_Size MUST have a tag = 80.
b. The value field MAY be of any length.
c. If the octet string is converted with OS2I(), then this number MUST be equal to
numberOfBytes (see (N118.00), resp. (N133.00)).
(N144.00)
82: DO_FCP MUST contain a DO_FileDescriptor. If the file is of the type
a. Folder, then it applies:
i. DO_FileDescriptor MUST have a tag = 82

ii. The value field MUST consist of one octet.
iii. The value field MUST contain the value 38 in the six LSBit.
iv. The seventh LSBit of the value field MUST be set, in order to indicate that the
folder is shareable in logical channels.
b. Transparent EF then it applies:
i. DO_FileDescriptor MUST have a tag = 82
ii. The value field MUST consist of one octet.
iii. The value field MUST contain the value 01 in the three LSBit.
iv. The seventh LSBit of the value field MUST be set in order to indicate that the
transparent EF is shareable in logical channels.
c. Structured EF, then it applies:
i. DO_FileDescriptor MUST have a tag = 82.
ii. The length of the value field of DO_FileDescriptor MUST be part of the set {5,
6}.
iii. The three LSBit in the first octet of the value field MUST be
1. 02, if it is a file of the type linear fix EF.
2. 04, if it is a file of the type linear variable EF.
3. 06 if it is a file of the type cyclic EF.
iv. The seventh LSBit of the first octet of the value field MUST be set in order to
indicate that the structured EF is shareable in logical channels.
v. The second octet MUST have the value 41.
vi. The third and fourth octet MUST equal to I2OS( maximumRecordLength, 2).
vii. The fifth octet respectively the fifth and the sixth octet MUST be defined in
such a way that an OS2I conversion results in the attribute maximumNum-
berOfRecords.
(N145.00)
83: If the file has an attribute of the type fileIdentifier (according to Clause 8.1.1), then
the DO_FCP MUST contain a DO_FID. It applies:
DO_FID = 83 02 I2OS( fileIdentifier, 2 ).
(N146.00)
84: If the file has attributes of the type applicationIdentifier (according to (N104.00)),
then DO_FCP MUST contain each of these attributes. Each attribute MUST be coded
as value field in a DO_AID. It applies:
DO_AID = 84 || I2OS(OctetLength( applicationIdentifier, 1 ) || applicationIdentifier.
(N147.00)
88: If the file is of the type file, DO_FCP MUST contain a DO_SFI. If the file has
a. an attribute shortFileIdentifier according to Clause 8.1.2, then it applies:
DO_SFI = 88 01 I2OS( 8 shortFileIdentifier, 1 ).
b. no attribute shortFileIdentifier, then it applies:
DO_SFI = 88 00.
(N148.00)
8A: The physical value of the attribute lifeCycleStatus (see Clause 8.1.3) MUST go
into DO_FCP. It MUST be coded in a value field in DO_LCS with tag = 8A. The value

of lifecycleStatus MUST be coded in an octet according to [ISO7816-4] Table 13. That
means:
a. Operational state (activated) MUST be part of the set {05, 07}.
b. Operational state (deactivated) MUST be part of the set {04, 06}
(N149.00)
8F: If the file is of the type structured EF and the value of the attribute flagRecord-
LifecycleStatus is
a. False, then DO_FCP MAY contain
i. a DO_ProfileIdentifier = 8F 01 00.
ii. no DO with tag = 8F.
b. True, then and only then DO_FCP MUST contain a DO_ProfileIdentifier = 8F 01
XX. OS2I(XX) MUST be an odd number less than 128.
(N150.00)
C5: If the file is of the type transparent EF (see Clause 8.3.2.1) and the concept sup-
ports logical End Of File, then and only then the DO_FCP MUST contain a
DO_ReadSize. It applies:
a. DO_ReadSize MUST have a tag = C5.
b. The value field MAY be of any length.
c. If the octet string is converted using OS2I(), then the resulting number MUST be
equal to the maximum number of octets readible with READ BINARY.
(N151.00)
DO_FCP MAY contain additional data objects. The coding of these data objects MAY
be manufacturer-specific.
(N152.00)
For the order of the data objects in DO_FCP it applies:
a. The order of all data objects is manufacturer-specific.
b. If present in DO_FCP, the data objects DO_Size, DO_FileDescriptor, DO_FID,
DO_AID, DO_SFI, DO_LCS, DO_ProfileIdentifier and DO_ReadSize MUST comple-
tely go into the first 256 octets of the octet string DO_FCP.
Note: The concept of logical End Of File distinguishes between a data size which can be described
with UPDATE BINARY and a logical data size which can be read with READ BINARY.
8.4 Password (normative)
A password is a secret usually known only to the card holder. The COS will process specific
Services only after this secret is successfully presented in the context of a user authentica-
tion. The necessity of this user authentication can be switched on (enable) or off (disable), if
the COS supports the commands ENABLE VERIFICATION REQUIREMENT and DISABLE
VERIFICATION REQUIREMENT.
Normally this secret can be changed for security reasons. Also for security reasons the ser-
vice user authentication will be blocked by the COS if the user authentication with a specific
password fails too often. Normally it is possible to unblock the blocking.
Note: In other documents normally the term PIN is used that denotes sometimes the 6-digit secret
known to the cardholder (Please enter your PIN) and sometimes the object as such (The PIN is
blocked). For clearness only the term password is used for the object type in this document.

The specifications of applications have to comply with the following rules:
(N153.00)
A password MUST have exactly one attribute pwdIdentifier; the value of this attribute
A COS MAY support additional values for pwdIdentifier.
A COS MAY refuse additional values for pwdIdentifier.
(N154.00)
A password MUST have exactly one attribute of the type accessRuleList (see
Clause 8.1.4).
(N155.00)
A password MUST have exactly one attribute secret of the type pin (see Clause 8.1.7)
(N156.00)
A password MUST have exactly one attribute minimumLength. The value of this attrib-
ute MUST be an integer in the interval [4, 12].
A COS MAY support additional values for minimumLength.
A COS MAY refuse additional values for minimumLength.
(N157.00)
A password MUST have exactly one attribute startRetryCounter. The value of this at-
tribute MUST be an integer in the interval [1, 15].
A COS MAY support additional values for startRetryCounter.
A COS MAY refuse additional values for startRetryCounter.
(N158.00)
A password MUST have exactly one attribute RetryCounter. The value of this attribute
A COS MAY support additional values for RetryCounter.
A COS MAY refuse additional values for RetryCounter.
(N159.00)
A password MUST have exactly one attribute transportStatus according to
Clause 8.2.5
(N160.00)
A password MUST have exactly one attribute flagEnabled of Boolean Type, if the COS
supports the commands DISABLE VERIFCATION REQUIREMENT and ENABLE
VERIFCATION REQUIREMENT. This attribute is used in the context of the validation
of access rules (see (N237.00)a.ii).
(N161.00)
A password MUST have exactly one attribute startSsecList.
a. The list MUST contain at least one element and MUST NOT have more than four
elements.
A COS MAY support lists with more elements.
A COS MAY refuse lists with more elements.
b. Each list element MUST have
i. exactly one seIdentifier according to (N79.00) and
ii. exactly one integer startSsec. startSsec MUST be in the interval [1, 250] or
represent the value infinity.
A COS MAY support additional values for startSsec.
A COS MAY refuse additional values for startSsec.
(N162.00)
A password MUST have exactly one attribute PUK of the type pin (see Clause 8.1.7),
which represents the secret to unblock the retryCounter which has run down.
(N163.00)
A password MUST have an attribute pukUsage. The value of pukUsage MUST be an
integer in the interval [0, 15].
A COS MAY support additional values for pukUsage.
A COS MAY refuse additional values for pukUsage.
(N164.00)
The sequence of digits for secret and PUK MUST be transferred at the interface Inter-
preter (see Figure 1 (N270.50)) all the time as Format-2-PIN Block (see (N81.00)).
A COS MAY support additional formats for the transfer.

A COS MAY refuse additional formats for the transfer.
(N165.00)
A Password MUST support the following commands:
CHANGE REFERENCE DATA (see Clause 14.6.1),
GET PIN STATUS (see Clause 14.6.4),
RESET RETRY COUNTER (see Clause 14.6.5),
VERIFY (see Clause 14.6.6).
Before these commands can use the password, the password has to be selected. This
is done by a password identifier, which is part of the respective command.
(N166.00)
A COS MAY support additional commands.
A COS MAY refuse additional commands.
An additional, channel-specific attribute securityStatusEvaluationCounter (see (N321.00)k) is
assigned to a password. Typically this attribute is assigned to a security status stored in vola-
tile memory (e.g. a RAM), see Clause 8.8. It will be changed in the context of commands for
user authentication (see Clause 14.6.6).
8.5 Key Objects (normative)
This sub-clause describes key objects being used in the context of cryptographic operations.
In this document the term key object is the generic term for symmetric, private and public
keys.
In this document symmetric keys are used for the following purposes:
1. With a secret (key) stored in a persistent way for one-sided authentication
(see Clause 15.1.1, (N895.00)a, (N895.00)b).
2. With a secret (key) stored in a persistent way for mutual authentication with parallel
negotiation of session keys (see Clause 15.4.1, Clause 15.4.2, Clause 15.6,
(N870.00)d, (N870.00)e, (N870.10)a, (N870.10)b, (N895.00)g).
3. As session keys to guarantee confidential communication
4. As session keys to guarantee the integrity and the authenticity of the communication
In this document private keys are used for the following purposes:
1. Calculation of electronic signatures (see Clause 14.8.1)
2. Decryption of data (see Clause 14.8.3)
3. Cornfirmation of the authenticity of this card
(see Clause 15.1.2, Clause 15.1.3, (N895.00)c, (N895.00)d, (N895.00)e, (N895.00)i)

4. Securing session keys during transport
(see Clause 15.4.3, Clause 15.4.4, Clause 15.4.5, Clause 15.5, (N870.00)h,
(N870.00)i, (N870.00)j, (N895.00)f, (N895.00)h)
In this document public keys are used for the following purposes:
1. Validation of electronic signatures while importing certificates (see (N1019.00))
2. Validation of electronic signatures in the context of role authentication
(see (N870.00)g)
3. Securing session keys during transport
(see Clause 15.4.3, Clause 15.4.4, Clause 15.4.5, Clause 15.5, (N870.00)h,
(N870.00)i, (N870.00)j, (N895.00)f, (N895.00)h)
8.5.1 Symmetric Authentication Object
A symmetric authentication object is used in the context of authentication according to

Clause 15.1.1 and Clause 15.4.1. The specifications of applications have to comply with the
following rules:
(N167.00)
A symmetric authentication object MUST have an attribute keyIdentifier. The value
A COS MAY support additional values for keyIdentifier.
A COS MAY refuse additional values for keyIdentifier.
(N168.00)
A symmetric authentication object MUST have exactly one attribute of the type ac-
cessRuleList (see Clause 8.1.4)
(N169.00)
A symmetric authentication object MUST have exactly one attribute encKey according
to Clause 8.2.1
(N170.00)
A symmetric authentication object MUST have exactly one attribute macKey according
to Clause 8.2.1
(N171.00)
A symmetric authentication object MUST have exactly one attribute algorithmIdentifier
which defines for which purpose it can be used.
a. For symmetric authentication objects in Generation 1 the value for algorithmIdenti-
fier MUST be an element of the set {
desRoleAuthentication, (see Clause 14.7.4.1, (N895.00)b)
desRoleCheck, (see Clause 14.7.1.1, (N870.00)c)
desSessionkey4SM (see Clause 14.7.1.1, (N870.00)d
and Clause 14.7.1.2, (N870.10)a
and Clause 14.7.4.1, (N895.00)g)
desSessionkey4TC (see Clause 14.7.1.1, (N870.00)e
and Clause 14.7.1.2, (N870.10)b
and Clause 14.7.4.1, (N895.00)g)
} (see Table 186 (N1216.00) )
b. A COS MAY support additional values for algorithmIdentifier.
A COS MAY support additional values for algorithmIdentifier.
(N172.00)
A symmetric authentication object MUST support the following commands:

EXTERNAL AUTHENTICATE (see Clause 14.7.1.1 and Clause 14.9.6.4),
MUTUAL AUTHENTICATE (see Clause 14.7.1.2 and Clause 14.9.6.6).
Before these commands can work with a symmetric authentication object it has to be
selected. This is done according to the use cases described in Clause 14.9.6.
(N173.00)
A symmetric authentication object MAY support additional commands.
A symmetric authentication object MAY refuse additional commands.
8.5.2 Symmetric Introduction Object
At first an asymmetric mutual and certificate based authentication is performed (mutual intro-
duction) in order to provide the key derivation data. The session keys established during au-
thentication are persistently stored for later use. Session keys which are stored this way will
perform the same tasks as the two asymmetric keys that were involved in the authentication
procedure. Thus, an introduction object inherits certain information of the public key certifi-
cate as well as security-related properties of the private key. The advantage of introduction
objects is that their use is more efficient (about the factor 2 to 3). Cards which frequently
have to mutually authenticate can use the introduction objects from the time when they were
introduced to each other.
Assuming that it is possible to store several private key objects for authentication purposes
on a card, the ICCSN alone is no longer an adequate reference to the corresponding public
keys. Therefore, the following CHR format MUST be used as reference:
(N174.00)
The CHR of the certificate is used as public key reference of a private key. The CHR
consists of 12 octets and is constructed as follows:
a. CHR = index || keyReference || ICCSN, with
b. index = 00 for all certificates,
c. keyReference = reference of the corresponding private key
according to (N1089.00)
d. ICCSN = card serial number of length 10 octets as given in EF.GDO
(N175.00)
It SHOULD be possible to store several introduction objects per public key. As refer-
ence to introduction objects the CHR MUST be used with an index octet denoting the
agreed key material as follows:
a. index = 01 introduction object with 2TDES key material
b. index = 02 introduction object with 3TDES key material
c. index = 03 introduction object with AES-128 key material
d. index = 04 introduction object with AES-192 key material
e. index = 05 introduction object with AES-256 key material
f.
A symmetric introduction object is used in the authentication context according to Clause
15.6. For this key object the following rules have to be observed while defining an applica-
tion:
(N176.00)
A symmetric introduction object MUST have an attribute keyIdentifier. Any octet string
of length 12 octets MUST be allowed as value of keyIdentifier.

The COS MAY support further values of keyIdentifier.
The COS MAY refuse further values of keyIdentifier.
(N177.00)
A symmetric introduction object MUST have exactly one attribute of type access-
RuleList (see Clause 8.1.4).
(N178.00)
A symmetric introduction object MUST have exactly one attribute of type encKey ac-
cording to Clause 8.2.1.
(N179.00)
A symmetric introduction object MUST have exactly one attribute of type macKey ac-
cording to Clause 8.2.1.
(N180.00)
A symmetric introduction object MUST have exactly one attribute of type listAlgorith-
mIdentifier with elements of type algorithmIdentifier indicating the particular purposes of
the object.
a. The list MUST contain at least one element.
b. The list MUST be able to include four elements.
c. The COS MAY support lists of more than four elements.
The COS MAY refuse lists of more than four elements.
d. The value of algorithmIdentifier for symmetric introduction objects in Generation 1
MUST be an element of the set {
desRoleAuthentication,
desRoleCheck,
desSessionkey4TC, (only SMC-A and SMC-B)
desSessionkey4SM
}
e. The COS MAY support further values of algorithmIdentifier.
The COS MAY refuse further values of algorithmIdentifier.
(N181.00)
A symmetric introduction object MUST have exactly one attribute of type CHA accord-
ing to Clause 7.1.1.4.
(N182.00)
A symmetric introduction object MUST support the following commands:
INTERNAL AUTHENTICATE (see Clause 14.7.4.1),
MUTUAL AUTHENTICATE (see Clause 14.7.1.2 and Clause 14.9.6.6),
Prior to sending the command that uses the symmetric introduction object, the object
itself has to be selected by applying one of the use cases described in Clause 14.9.6.
(N183.00)
A symmetric introduction object MAY support further commands.
A symmetric introduction object MAY refuse further commands.
8.5.3 Private Key Object
A private key object is used

for authentication of a smartcard towards another technical component,
for decryption of data and
for computation of electronic signtures.
The specifications of applications have to comply with the following rules for private key ob-
jects:
(N184.00)
A private key object MUST have an attribute keyIdentifier. The value MUST be an inte-
ger in the interval [2, 28].
A COS MAY support additional values for keyIdentifier.
A COS MAY refuse additional values for keyIdentifier.
(N185.00)
A private key object MUST have exactly one attribute of the type accessRuleList (see
Clause 8.1.4).
(N186.00)
A private key object MUST have exactly one attribute privateKey according to
Clause 8.2.3.
(N187.00)
A private key object MUST have exactly one attribute listAlgorithmIdentifier, which de-
fines, for which purpose the private key object can be used.
a. For the length of the list it applies: The list MUST contain at least one element and
MUST NOT contain more than four elements (compare (N79.00)).
b. Each list element MUST contain
i. exactly one attribute seIdentifier according to (N79.00) and
ii. exactly one set setAlgorithmIdentifier with elements of type algorithmIdenti-
fier.
c. The set setAlgorithmIdentifier MUST NOT contain more than six elements.
d. The COS MAY
i. support sets of type setAlgorithmIdentifier, which include more elements than
specified in (N187.00)c.
ii. refuse sets of type setAlgorithmIdentifier, which include more elements than
specified in (N187.00)c.
(N188.00)
The COS MUST support as elements for setAlgorithmIdentifier each element from the
sets defined in (N189.00), (N191.00) and (N194.00).
A COS MAY support additional values for algorithmIdentifier.
A COS MAY refuse additional values for algorithmIdentifier.
(N189.00)
In Generation 1 for the purpose of authentication algorithmIdentifier MUST be an ele-
ment of the following set (see Table 186 (N1216.00)): {
rsaClientAuthentication, (see Clause 14.7.4.1 and (N895.00)d)
rsaRoleAuthentication (see Clause 14.7.1.1 and (N895.00)e)
rsaSessionkey4SM (see Clause 14.7.4.1 and (N895.00)f)
rsaSessionkey4Intro (see Clause 14.7.4.1 and (N895.00)h)
rsaSessionkey4TC (requirement for SMC-A and SMC-B,
see Clause 14.7.4.1 and (N895.00)h)
}
(N190.00)
If an algorithmIdentifier from the set specified in (N189.00) is assigned to a private key
object, then the key object MUST support the following commands:

INTERNAL AUTHENTICATE (see Clause 14.7.4.1 and Clause 14.9.6.3) and
PSO: COMPUTE DIGITAL SIGNATURE (see Clause 14.8.1.1 and Clause 14.9.6.7)
Before these commands can work with the private key object it has to be selected. This
is done according to the use cases described in Clause 14.9.6.
A COS MAY support or refuse additional commands for such private key objects.
(N191.00)
In Generation 1 for the purpose of decryption algorithmIdentifier MUST be an element
of the following set (see Table 187 (1217.00)): {
rsaDecipherPKCS1_V1_5 (see Clause 14.8.3.1, (N945.00)a and
Clause 14.8.7.1, (N1004.00)a)
rsaDecipherOaep (see Clause 14.8.3, (N945.00)b and
Clause 14.8.7.1, (N1004.00)b)
}
(N192.00)
PSO: DECIPHER (see Clause 14.8.3),
PSO: TRANSCIPHER (see Clause 14.8.7).
is done according to the use cases described in Clause 14.9.6.9.
(N193.00)
A private key object MUST support an attribute keyAvailable of Boolean type. This at-
tribute is used in the context of the commands
GENERATE ASYMMETRIC KEY PAIR (see Clause 14.9.2.5) and
PSO: COMPUTE DIGITAL SIGNATURE (see (N911.00)).
The value True indicates, that the attribute privateKey can be used.
The value False indicates, that the attribute privateKey cannot be used.
(N194.00)
In Generation 1 for the purpose of signature computation algorithmIdentifier MUST be
an element of the set (see Table 188 (N1218.00)): {
sign9796_2_DS2, (see Clause 14.8.1.2 and (N912.00)a)
signPKCS_V1_5, (see Clause 14.8.1.1 and (N912.00)b)
signPSS, (see Clause 14.8.1.1 and (N912.00)c)
}.
(N195.00)
GENERATE ASYMMETRIC KEY PAIR (see Clause 14.9.2),
PSO: COMPUTE DIGITAL SIGNATURE (see Clause 14.8.1)
is done according to the use cases described in Clause 14.9.6.7.
8.5.4 Public Key Object
A public key object is the generic term for

public objects for signature verification (Clause 8.5.4.1)
public objects for authentication (Clause 8.5.4.2)
The specifications of applications have to comply with the following rules for public key ob-
jects:

(N196.00)
A public key object MUST have an attribute keyIdentifier.
(N197.00)
A public key object MUST have exactly one attribute publicKey according to Clause
8.2.4.
(N198.00)
A public key object MUST have exactly one attribute oid which defines the purpose for
which it may be used.
(N199.00)
A COS MAY support access rules for public key objects. These access rules MUST
use the access condition ALWAYS for all access types supported by the key object.
(N200.00)
A COS can refuse access conditions for public key objects.
8.5.4.1 Public Objects for Signature Verification
A public object for signature verification is used for the verification of an electronic signature
in a CV-certificate. The specifications of applications have to comply with the following rules
for this key object:
(N201.00)
A public object for signature verification is an extension of a public key object and
MUST comply with the requirements of Clause 8.5.4.
(N202.00)
For the value of the attribute keyIdentifier any octet string with a length of eight octets
MUST be possible.
A COS MAY support additional lengths for keyIdentifier.
A COS MAY refuse additional lengths for keyIdentifier.
(N203.00)
For a public object for signature verification in Generation 1 the value of oid MUST be
an element of the set {
sigS_ISO9796-2Withrsa_sha256, (see Table 6 (N48.50))
}.
A COS MAY support additional values for oid.
A COS MAY refuse additional values for oid.
(N204.00)
A public object for signature verification MUST support the following command:
PSO: VERIFY CERTIFICATE (see Clause 14.8.8)
Before these commands can work with the public object for signature verification it has
to be selected. This is done according to the use cases described in Clause 14.9.6.8.
A public object for signature verification MAY support additional commands.
A public object for signature verification MAY refuse additional commands.
8.5.4.2 Public Authentication Object
A public authentication object is used for the authentication of another technical component
to this component. The specifications of applications have to comply with the following rules
for this key object:
(N205.00)
A public authentication object is an extension of a public key object and MUST comply
with the requirements of Clause 8.5.4.

(N206.00)
For the value of the attribute keyIdentifier any octet string with a length of twelve octets
MUST be possible.
A COS MAY support additional lengths for keyIdentifier.
A COS MAY refuse additional lengths for keyIdentifier.
(N207.00)
For a public authentication object in Generation 1 the value of oid MUST be an element
of the set {
authS_ISO9796-2Withrsa_sha256_mutual, (see Table 6 (N48.50))
}.
A COS MAY support additional values for oid.
A COS MAY refuse additional values for oid.
(N208.00)
If publicKey is of the type
a. publicRsaKey, then a public authentication object MUST have exactly one attribute
of the type CHA according to Clause 7.1.1.4.
b. publicElcKey, then (relevant from Generation 2 on).
(N209.00)
A public authentication object MUST support the following commands:
EXTERNAL AUTHENTICATE (see Clause 14.7.1),
INTERNAL AUTHENTICATE (see (N895.00)f)
Before these commands can work with the public authentication object it has to be se-
lected. This is done according to the use cases described in Clause 14.9.6.5.
A public authentication object MAY support additional commands.
A public authentication object MAY refuse additional commands.
8.6 Data objects (informative)
According to [ISO7816-4] the access for data objects is done with the commands GET DATA
and PUT DATA. These commands are not mandatory for this version of the specification;
therefore they will not be regarded.
8.7 Security Environment (informative)
According to [ISO7816-4] Clause 6.3.3 there is a wide variety of interpretations possible for
the term Security Environment. Therefore it is the intention not to use this term in the nor-
mative parts of this document. For the same reason only the indisputable principle of security
environments will be touched shortly in this informative (but not normative) Clause.
Security environments (SEs) offer the possibility to allocate in dependence of the environ-
ment concrete values to attributes of objects. For example this is used in this document for
the attribute type accessRuleList (Clause 8.1.4). Using SEs additional possibilities will result
for the design of applications.
An example: An HPC may be used in two different environments and in both environments
qualified electronic signatures can be created using the command PSO: COMPUTE DIGITAL
SIGNAURE.
1. In the environment 1 only single signatures can be created, i.e. user verification with
the signature PIN (PIN.QES) is required for each signature creation. Signature crea-
tion is also possible in signature environments other than the telematics environment
of the health professional. The access rule of the signature key simply demands the
entry of PIN.QES.
2. In the environment 2 stack and comfort signatures can be created. In addition to the
user verification with PIN.QES, a device authentication of the signature environment
of the helath professional must be performed towards the HPC. The device authenti-
cation is a CVC-based role authentication of the signature application component
(SAK). Furthermore, the the data to be signed must be transfered in a protected
mode (with Secure Messaging).
Each environment has its own set of access conditions:
1. Environment_1:
a. Signature Key PSO: COMPUTE DS for single signatures:
User verification with PIN.QES
b. QES Certificate READ BINARY: always possible
2. Environment_2
a. Signature Key PSO: COMPUTE DS for stack and comfort signatures:
User verification with PIN.QES and
Authentication of SAK and
Secure Messaging
b. QES Certificate READ BINARY: always possible
The set of access rules to be used is defined by the environment. A concrete security envi-
ronment is selected by the use case in Clause 14.9.6.1.
On the other hand security environments will be used to select keys and other parameters for
cryptographic operations. The approach is different than for passwords. The specific pass-
word to be used by a command from Clause 14.6. will be determined by a parameter of this
command.
The procedure for keys is comparable with the procedure for files: The attribute currentEF
determines the file being affected. This attribute has to be chosen with the command SE-
LECT before the final command is executed. The file-oriented commands can only work with
one file per command; therefore one single attribute currentEF per folder is sufficient (see
(N322.00)b).
For some cryptographic commands it is possible that several cryptographic objects are af-
fected, like
Session keys for confidentiality
Session keys for authenticity
Use case specific keys, e.g. PSO: COMPUTE DIGITAL SIGNATURE

Instead of passing all key parameters with such a command (as it is done with commands for
passwords), it is defined in [ISO7816-4] that these parameters will be set upfront with the
command MSE (see Clause 14.9.6). Such selections have an effect on the attribute key-
ReferenceList (see (N321.00)c).
Note 1: The normative rules of this document allow storing channel-specific attributes (see Clause 12)
in the RAM to achieve a better performance. The named attributes are allocated as shown to
simplify the description.

Note 2: The normative rules of this document allow storing the channel-specific folder-attributes in
(N322.00) only for currentFolder and all its ancestors inclusive root instead for all folders in the
object-system to achieve an optimization of the memory. The named attributes are allocated to
each folder to simplify the description.
8.8 Security Status (informative)
According to [ISO7816-4] Clause 5.4.1 there is a wide variety of interpretations possible for
the term Security Status. Therefore it is the intention not to use this term in the normative
parts of this document. For the same reason only the indisputable principle of security status
will be touched shortly in this informative (but not normative) clause.
According to [ISO7816-4] the following items are part of the security status
1. Global security status which can be modified by user verification or component authenti-
cation with objects in the folder root (see (N210.00))
2. Application-specific security status which can be modified by user verification or compo-
nent authentication with objects in any folder
3. File specific status (not regarded in this document)
4. Command-specific status, which is allowed for the evaluation of access rules
In respect to global and application specific states one security status is assumed in this
document. In addition
a. user verification is covered by (N321.00)i, (N321.00)j and (N321.00)k. The mini-
mum number of security states per folder to be supported for user authentication
is also defined there.
b. component authentication is covered by (N321.00)e, (N321.00)f and (N321.00)g.
The minimum number of security states to be supported for component authenti-
cation is also defined there.
Note: In this document the normative rules allow to store the attributes globalSecurityList, dfSpecific-
SecurityList, globalPasswordList and dfSpecificPasswordList (including the password attribute
securityStatusEvaluationCounter) in the RAM to achieve a better performance. The mentioned
attributes were assigned simply for the sake of clear description.

9 Object System (normative)
In this document a smartcard will be regarded as a secure data storage unit, the accentua-
tion being on both parts.
Data storage unit: a smartcard stores any information, in line with a hard disk in a
computer (see Clause 8.3.2).
Security: The access to data being stored in files is defined by specific rules. The
compliance with these rules is guaranteed by the operating system. Typically rules
contain access restrictions so that access is only allowed after a successful user au-
thentication or component authentication. Furthermore a confident and authentic data
exchange is enforced.
Data, i.e. information, is usually stored hierarchically.
In this document the rules are defined to allow the building of a hierarchical system with at
least four layers of files (root contains DF2, DF2 contains DF3, DF3 contains DF 4, DF4 con-
tains no additional folders).
Private and symmetric keys as well as passwords can be searched by backtracking. That
means, at first they will be searched in the current file. If not found there, the search will be
continued recursive in the next higher level.
A search being DF-specific never includes root.
Public keys are regarded as centrally stored objects. Usually, such keys belong to an exter-
nal component and are imported by means of a certificate (see Clause 14.8.8)).
9.1 Design and depth of the structure
This clause defines the hierarchical structure as seen at the interface. It is not subject of this
document how the corresponding information and structure is stored internally in the smart-
card. Furthermore the term file system is not used. Instead the term object system is used
because beside files other object types are regarded, such as passwords and keys.
The following rules apply for the specification of applications:
(N210.00)
The COS MUST support a hierarchical object system with several layers.
a. The object system MUST have an attribute root with the following characteristics:
i. The attribute root MUST be of the type application (see Clause 8.3.1.1)
ii. The access condition for the command DELETE (see Clause 14.2.4) MUST
be NEVER (see (N236.00)).
b. The object system MUST have an attribute answerToReset of the type octet string.
The allowed values for this attribute are defined in Clause 11.2.1.
c. The object system MUST have an attribute iccsn8 of the type octet string. For iccsn8
any values with eight octets MUST be possible.
d. The object system MUST have an attribute persistentPublicKeyList.
i. The COS MUST support any number of list elements. A limitation is only given
by the available memory space.
ii. The object type public object for signature verification MUST be supported
as a list element (see Clause 8.5.4.1), together with a reference to a file to
which this key object is assigned (see (N228.00) and (N1019.00)a.vii).
A COS MAY support additional public key object types.
A COS MAY refuse additional public key object types.
iii. Elements of this list MUST be stored in a persistent way.
e. The object system MUST support an attribute publicKeyList.
i. The COS MUST support a list length of one.
A COS MAY support greater numbers for the list length.
A COS MAY refuse greater numbers for the list length.
ii. The object type public key object MUST be supported as a list element (see
Clause 8.5.4), together with a reference to a file to which this key object is as-
signed (see (N228.00) and (N1019.00)a.viii).
iii. Elements of the list MAY be stored on a persistent base.
Elements of the list MAY be stored on a volatile base.
f. The hierarchical object system MUST support an attribute persistentIntroduction-
KeyList
i. The COS MUST support any number of list elements up to the maximum
number of elements which is set during card manufacturing.
The COS MAY support a dynamic adjustment of the list length.
The COS MAY refuse a dynamic adjustment of the list length.
ii. The object type symmetric introduction object (see Clause 8.5.2) MUST be
supported as list element together with a reference to a directory which the ob-
ject is assigned to (see (N340.00)b.vii).
iii. Elements of the list MUST be persistently stored
g. From generation 2 on: the object system MUST support an attribute domainParama-
terList.
i. The COS MUST support any number of list elements. A limitation is only given
by the available persistent memory space.
ii. As list elements MUST (to be completed for generation 2)
iii. Changes of the list, downloads, deletion.., secured with AC,. (to be com-
pleted for generation 2)
(N211.00)
The folder root is part of layer_0. Layer_0 is named the highest level of the object sys-
tem.
(N212.00)
If a folder is part of layer_i, then all elements of the list children of this layer are part of
layer_(i+1).
Layer_i is the next higher level to layer_(i+1).
Layer_(i+1) is the next lower layer to layer_i.
(N213.00)
According to Clause 8.3.1.1 applications have no attribute fileIdentifier. Therefore they
cannot be selected with the command SELECT and parameter selectionMode = 01.
An application being not root,
a. MUST be part of layer_1
b. MAY be taken as an element of the list children (according to (N101.00)) of root.
c. MAY be stored somewhere else in the smartcard.
(N214.00)
Folders being part of layer_0 (root), layer_1 (DF1) or layer_2 (DF2) MUST allow the
objecttypes Dedicated File (Clause 8.3.1.2) and Application Dedicated File
(Clause 8.3.1.3) as list elements in the attribute children.
(N215.00)
Folders being part of layer_3,
a. MAY support folders in the attribute children,
b. MAY refuse folders in the attribute children
Additional channel-specific attributes are assigned to the object system. Typically these at-
tributes are assigned to a channel context (see (N321.00)) stored in a volatile way (in the
RAM). Typically these attributes will be changed during the selection of the folder.
According to Clause 8.3.1, Clause 8.3.2 and Clause 8.1.5 the object types folder, file and
record have an attribute lifeCycleStatus. According to (N211.00) and (N212.00) the instances
of all object types can be assigned to layers. Records will be regarded as the next lower level
compared to the file, to which they belong. It will only be distinguished between the physical
and the logical value of lifeCycleStatus.
(N216.00)
The value belonging to the corresponding attribute of the object is named the physical
value of lifeCycleStatus. In this document only folders, files and records have such an
attribute.
(N217.00)
The combined view on the physical value of the lifeCycleStatus of an object and the
logical values of lifeCycleStatus in all higher layers is referred to as the logical value of
lifeCycleStatus. The following recursion applies:
a. For the object root the logical value and the physical value MUST be identical.
b. For an object with an attribute lifeCycleStatus, being different from root it MUST ap-
ply: If the logical value of the object in the next higher layer is
i. Operational state (activated), then and only then the logical and the physical
value of lifeCycleStatus for this object MUST be identical.
ii. Operational state (deactivated), then and only then the logical value of life-
CycleStatus for this object MUST be Operational state (deactivated) as well.
c. For an object having no own attribute lifeCycleStatus (in the context of this docu-
ment: password objects and key objects), the logical value of lifeCycleStatus MUST
be identical to the logical value of the next higher layer.
9.2 Object Search
According to Clause 9.1 a hierarchical object system is visible at the interface of the smart-
card. This clause defines how an object will be searched and which rules apply in order to
find it.
9.2.1 File Search
The search for files, i.e. folders and data files, takes place only in the context of a selection.
Therefore the explicit search is described in Clause 14.2.6. Additionally, the commands refer-

ring to files support variations with the parameter shortFileIdentifier. The search for a file for
this case is described together with the respective commands.
9.2.2 Password Search
Passwords are used in the context of commands defined in Clause 14.6, but also for the
evaluation of access rules (see (N237.00)). The search for passwords is a functionality of the
smartcard itself for which many implementation details are playing a role. At the interface
Interpreter (see Figure 1 (N270.50)) the characteristics defined in the following will become
clear:
Input: passwordReference According to (N753.00)
startFolder Folder, at which the search for a password starts
Output: password Contains the password found
Errors: pwdNotFound For the given input parameters no appropriate password

was found
Notation: password = searchPwd( startFolder, passwordRefer-

ence )
(N218.00)
The input parameter passwordReference is divided into parts according to (N753.00):
a. identifier = passwordReference mod 128
b. location = passwordReference - identifier
(N219.00)
If location has the value 00 = 0 addressing a global password, then it will be searched
for a password in the root layer root of the object system whose attribute pwdIdentifier
is identical to identifier. If such a password
a. exists, then it is used as the output parameter for password..
b. does not exist, then the error pwdNotFound will be returned.
(N220.00)
If location has the value 80 = 128 addressing a DF-specific password, then the local
variable folder is set to startFolder.
(N221.00)
If folder
a. points to the root directory root, then the error pwdNotFound will be returned.
b. Otherwise it will be searched in folder for a password whose attribute pwdIdentifier
is identical to identifier. If such a password object
i. exists, then it is used as the output parameter for password.
ii. does not exist, then folder is set to the next higher folder and the algorithm is
continued with step (N221.00)a.

9.2.3 Search for a Key Object
The function described here is a generalization of the other functions for key search and
therefore represents the general entry point for key search as used at different passages in
this document.
Input: startFolder directory which the search starts in
identifier The following value ranges are possible for this parameter:
- an octet keyReference according to (N1089.00)
- 8 octets keyIdentifier according to (N196.00) and (N202.00)
- 12 octets keyIdentifier according to (N196.00) and (N206.00)
- 12 octets keyIdentifier of an introductionkey acc. to (N176.00)
- manufacturer-specific acc. to (N339.00)b.ii or(N339.00)b.iii
algID Cryptographic method, which is supported by the key to be

searched for, or wildcard
Output: key contains the searched key object
Errors: keyNotFound No key object matching the given input parameters was found
notSupported The key does not support the algorithm required by algID
Notation: key = SearchKey( startFolder, identifier, algID)
(N222.00)
If the parameter identifier contains a key reference according to
a. (N1089.00), then it applies:
key = SearchPrivateOrSecretKey( startFolder, identifier, algID )
b. (N202.00) or (N206.00), then it applies:
key = SearchPublicKey ( startFolder, identifier, algID )
c. (N176.00), then it applies:
key = SearchIntroductionKey( startFolder, identifier, algID )
d. (N339.00)b.ii or(N339.00)b.iii, then it applies:
The search aims at session keys that are used in the context of PSO commands for
trusted channel support. As long as the security status exists (compare (N328.00)c),
that has been set during negotiation of the session keys, these keys are available
and MUST be found.
9.2.3.1 Search for a private or secret Key Object using keyReference
In this clause symmetric key objects according to Clause 8.5.1 and private key objects ac-
cording to Clause 8.5.3 are described together, because the search for both objects is done
in the same way. These objects are used in the context of several cryptographic operations.
Symmetric key objects will also be used during the evaluation of access rules (see
(N238.00)). This kind of search for keys is a functionality of the smartcard itself for which
many implementation details are playing a role. At the interface Interpreter (see Figure 1
(N270.50)) the characteristics defined in the following will become clear:
Input: startFolder Folder, at which the search for a key starts
identifier keyReference according to (N1089.00)
algID cryptographic method being supported by the key to be

searched, or Wildcard
Output: key Contains the key object found
Errors: keyNotFound For the given input parameters no appropriate key was found
notSupported The key does not support the algorithm asked for by algID
Notation: key = SearchPrivateOrSecretKey( startFolder, keyReference,

algID )
(N223.00)
The input parameter keyReference is divided according to (N1089.00) into the parts
a. identifier = keyReference mod 128
b. location = keyReference - identifier
(N224.00)
If location has the value 00 = 0 addressing a global key object, then the root layer root
of the object system is searched for a key object whose attribute keyIdentifier is identi-
cal to identifier. If such a key object
a. exists, then it is used as the output parameter for key.
b. does not exist, then the error keyNotFound will be returned.
(N225.00)
If location has the value 80 = 128 addressing a DF-specific password, then the local
variable folder is set to startFolder.
(N226.00)
If folder
a. points to the root directory root, then the error keyNotFound will be returned.
b. Otherwise it will be searched in folder for a password whose attribute keyIdentifier is
identical to identifier. If such a password object
i. exists, then it is used as the output parameter for key.
ii. does not exist, then folder is set to the next higher folder and the algorithm is
continued with step (N226.00)a.
(N227.00)
If the output parameter key is a
a. symmetric key having an attribute algorithmIdentifier mismatching with the parame-
ter algID, then the error notSupported will be returned.

b. private key, then the attribute listAlgorithmIdentifier is searched for an element,
whose seIdentifier (see (N187.00)b.i) is identical to the attribute seIdentifier (see
(N322.00)a) of the folder, which contains key as child. The error notSupported will
be returned, if such an element
i. does not exist, or
ii. exists, but the set setAlgorithmIdentifier (N187.00)b.ii) does not contain the
element algID.
9.2.3.2 Search for a public key object using keyIdentifier
Public key objects are used for the import of keys via card verifiable certificates. For this pur-
pose, the attributes of the key object are set to the corresponding values of the certificate,
e.g. the attribute keyIdentifier is set to the CHR value (see (N196.00) and (N1019.00)). The
attributes of a public key object may as well be set to constant values during personalization.
Public key objects are used in the context of authentication protocols and can be referenced
via keyIdentifier. The sub-class public authentication objects will also be used during the
evaluation of access rules (see (N239.00) and (N240.00)). This kind of search for keys is a
functionality of the smartcard itself for which many implementation details are playing a role.
At the interface Interpreter (see Figure 1 (N270.50)) the characteristics defined in the fol-
lowing will become clear:
Input: startFolder Folder, at which the search for a key starts
identifier keyIdentifier according to (N196.00), (N202.00) and

(N206.00)
algID cryptographic method being supported by the key to be

searched
Output: key Contains the key object found
Errors: keyNotFound For the given input parameters no appropriate key was found
Notation key = SearchPublicKey( startFolder, identifier, algID)
(N228.00)
The local variable folder is set to startFolder. Then the following steps will be executed:
a. In the attributes persistentPublicKeyList and publickeyList of the object system it will
be searched for a key object,
i. whose attribute keyIdentifier is identical to identifier and
ii. whose attribute oid according to (N198.00) matches with the given algID (see
(N229.00)) and
iii. which is assigned to the folder folder.
b. If such a key object
i. exists, then it is used as the output parameter for key.
ii. does not exist and folder
1. equals the folder root, then the errorkeyNotFound is returned.
2. does not equal the folder root, then folder is set to the next higher folder
and the algorithm is continued with step (N228.00)a.

(N229.00)
To the OID
a. sigS_ISO9796-2Withrsa_sha256 (see Table 6 (N48.50)) exactly algID verifyCertifi-
cate (siehe Table 188 (N1218.00))) MUST match.
b. authS_ISO9796-2Withrsa_sha256_mutual (see Table 6 (N48.50)) exactly the algIDs
from the following set MUST match (siehe Table 186 (N1216.00)):
{rsaRoleCheck, rsaSessionkey4SM, rsaSessionkey4Intro, rsaSessionkey4TC}.
Note 1: According to Clause 7.1.1.5, Table 6 (N48.50)), (N203.00) and (N207.00) for this document
only OIDs from the following set are relevant:
{sigS_ISO9796-2Withrsa_sha256, authS_ISO9796-2Withrsa_sha256_mutual}.
Note 2: According to (N859.00), (N870.00), (N895.00) and (N1018.00) in connection with (N1111.00),
(N1101.00) and (N1125.00) for this document only algIDs from the following set are relevant:
{rsaRoleCheck, rsaSessionkey4SM, rsaSessionkey4Intro, rsaSessionkey4TC, verifyCertificate}
9.2.3.3 Search for a Symmetric Introduction Object
Symmetric introduction objects are used for authentication purposes. Furthermore, they are
used during evaluation of access rules (see (N239.00) and (N240.00)). This kind of key
search is an internal functionality of the card depending on many implementation details. At
the interpretation interface however, the behavior becomes obvious as defined in the follow-
ing:
Input: startFolder directory which the search starts in

identifier keyIdentifier according to (N176.00)
algID Cryptographic method, which is supported by the key to be
searched for, or wildcard
Output: key contains the searched key object
Errors: keyNotFound No key object matching the given input parameters was
found
notSupported The key does not support the algorithm required by algID
Notation: key = SearchIntroductionKey( startFolder, identifier, algID)
(N230.00)
The local variable folder is set to startFolder. Then the following steps are performed:
a. The attribute persistentIntroductionKeyList is searched for a key object of which the
attribute keyIdentifier is equal to identifier and which is assigned to the directory
folder. If such a key object
b. exists, then it will be used as output parameter key
c. does not exist and folder
i. equals root, then the error keyNotFound will be returned.
ii. does not equal root, then folder will be set to the next higher directory and the
algorithm continued with step (N230.00)a.

(N231.00)
If the attribute key.listAlgorithmIdentifier does not contain the value algID, then the error
"notSupported" is returned.

10 Access Control (normative)
Nearly all commands described in Clause 14 are protected by access rules. That means that
the card operating system controls whether the security status is sufficient to execute a spe-
cific operation. The rules in this clause are a subset of the rules defined in [ISO7816-4]
Clause 5.4.3.2 Expanded format.
10.1 Access Mode
The access mode indicates whether the access rules assigned to an access mode should be
evaluated in the context of the validation of access rules. The specifications of applications
have to comply with the following rules:
(N232.00)
An access mode MUST be a list of descriptions of commands
(N233.00)
Being a subset of [ISO7816-4] Table 22 for each list element it MUST apply:
a. a list element MUST contain according to Clause 14 the name of a command being
equivalent to exactly one combination of CLA Byte (see Clause 11.5.1) and INS
Byte (see Clause 11.5.2)
b. Within a list element the parameter P1 (see Clause 11.5.3) is optional. That means:
It MUST be possible that a list element contains
i. exactly one parameter P1.
ii. no parameter P1.
c. Within a listen element the parameter P2 (see Clause 11.5.4) is optional. That
means: It MUST be possible that a list element contains
i. exactly one parameter P2.
ii. no parameter P2.
d. A COS MAY support additional descriptions of commands.
A COS MAY refuse additional descriptions of commands.
(N234.00)
Definition: During evaluation the access mode MUST match with the current command
APDU, if the integral parts of the access mode are identical to the integral parts of the
command APDU at the interface Interpreter (see Figure 1 (N270.50)).
10.2 Access Condition
An access condition is a Boolean term. The specifications of applications have to comply

with the following rules, whereas the following definitions are used in the description:
startFolder If this access rule belongs to an object
of the type folder, than startFolder is equal to this folder
Of a different type, than startFolder is equal to the folder whose attrib-

ute children contains this object.
path(folder) Path of a folder with the name folder. Due to this definition the folder folder
belongs to this path as well as all higher layers according to Clause 9.1 (in-
cluding root).
(N235.00)
The Boolean element ALWAYS MUST always return the value True.
(N236.00)
The Boolean element NEVER MUST always return the value False.
(N237.00)
The Boolean element PWD(passwordReference) MUST
a. return True if and only if the search for a password according to Clause 9.2.2 with
the input parameters passwordReference and startFolder finds a password and at
least one of the following conditions is fulfilled:
i. This password object is contained in either globalPasswordList (see
(N321.00)i) or dfSpecificPasswordList (see (N321.00)j, and the attribute secu-
rityStatusEvaluationCounter of this password is unequal zero. The attribute
securityStatusEvaluationCounter MUST be decremented by one. In case the
value has reached zero this way, the entry in the list
1. MAY remain in the list or
2. MAY be deleted from the list.
ii. The attribute flagEnabled of this password has the value False.
b. In all other cases return False.
(N238.00)
The Boolean element AUT(keyReference) MUST
a. return True, if and only if the key search according to Clause 9.2.3.1 with the input
parameters keyReference, Wildcard and startFolder finds a key object key and ex-
actly this key object is part of either globalSecurityList (see (N321.00)e) or dfSpeci-
ficSecurityList (see (N321.00)f).
(N239.00)
From generation 2 on it applies: the Boolean element AUT(acBitList) MUST (to be
completed for generation 2).
(N240.00)
The Boolean element AUT(CHA) MUST
a. return True, if and only if CHA is part of globalSecurityList (see e) or dfSpecificSe-
curityList (see (N321.00)f).
(N241.00)
Secure messaging according to Clause 13 is used in access conditions as follows:
a. The Boolean element SmMac MUST return
i. True, if and only if the attribute SessionkeyContext.flagSessionEnabled has
the value SK4SM.
ii. False at all other values of SessionkeyContext.flagSessionEnabled.

b. The Boolean element SmCmdEnc MUST return the value of SessionkeyCon-
text.flagCmdEnc.
c. The Boolean element SmRspEnc MUST always return the value True.
d. SessionkeyContext.flagRspEnc MUST be set to True, if and only if the access
condition contains the element SmRspEnc.
e. Commands, which perform operations of a trusted channel, may directly access
session keys that are referred to in channelContext.KeyReferenceList.dataDecipher
and channelContext.KeyReferenceList.macCalculation (see (N339.00)b. The access
condition of session keys for trusted channel is a manufacturer-specific Boolean ele-
ment, which MUST return "True" if and only if SessionkeyContext.flagSession-
Enabled has the value SK4TC.
(N242.00)
It MUST be possible to combine the defined Boolean elements to a Boolean term.
The Boolean term MUST support the AND-operator.
The Boolean term MUST support the OR-operator.
The Boolean term MUST NOT HAVE another operator.
(N243.00)
The Boolean value of the access condition is the result of the Boolean term.
Note: The normative rules of this document, in particular the rules in respect to
attributes of a password (see Clause 8.4)
changes of the status after a successful user authentication (see (N771.00) and (N854.00))
the Boolean element PWD (see (N237.00)) is designed so that after successful user verification
exactly one operation (e.g. signature) is possible (startSSEC = 1, see (N161.00)b.ii), or
exactly n operations are possible (startSSEC = n > 1), or
any number of operations is possible (startSSEC = infinite).
10.3 Access Rules
An access rule combines access mode and access condition and returns a Boolean result
after execution. The specifications of applications have to comply with the following rules:
(N244.00)
An access rule is a list with at least one element.
(N245.00)
A list element MUST contain exactly one access mode according to Clause 10.1 and
one access condition according to Clause 10.2.
(N246.00)
A list element MUST
a. return exactly the Boolean value True if and only if
i. the access mode matches according to (N234.00) and
ii. the Boolean value of the access condition has the value True.
b. In all other cases return False (implicit NEVER).
(N247.00)
An access rule MUST be regarded as
a. fulfilled if at least one list element returns the value True.
b. not fulfilled in all other cases.

(N248.00)
An access rule fulfilling all other requirements of Clause 10 MUST NOT need more
than 240 octets for the coding according to [ISO7816-4] Clause 5.4.3.2.
10.4 Evaluation of Access Rules
This sub-clause describes how the COS checks whether a specific command is allowed or
forbidden.
Input: obj Instance of an object of the type folder, file, password object, sym-
metric authentication object or private key object.
CLA CLA Byte

INS INS Byte
P1 parameter P1
P2 parameter P2
Output: b Boolean, True means command allowed, False means command

forbidden
Errors:
Notation: b = AccessRuleEvaluation( obj, CLA , INS, P1, P2 )
(N249.00)
Step 1: If obj is
a. a folder, then it MUST be se = seIdentifier of this folder (see (N322.00)a).
b. otherwise it MUST be se = seIdentifier of the folder (see (N322.00)a), which con-
tains obj in its attribute children (see (N101.00)).
(N250.00)
Step 2: The adequate access rule will be selected from obj.accessRuleList under con-
sideration of the logical value of obj.lifeCycleStatus (see (N217.00)) and se (see
Clause 8.1.4).
(N251.00)
Step 3: On the basis of CLA, INS, P1 and P2 it will be determined whether the selected
access condition (N250.00) is fulfilled (see Clause 10.3).
(N252.00)
Step 4: If the selected access rule
a. is fulfilled, then it MUST be b = True.
b. otherwise it MUST be b = False.
Note: If the access condition PWD1 OR PWD2 contains both password objects with SSEC unequal to
infinity then it is manufacturer-specific whether both SSECs or only one (and in this case which of
them) will be decremented.

11 Communication (normative)
11.1 Request Response
For smartcards it is state of the art to exchange information with an external communication
partner using a channel with half-duplex transfer mode. In addition they work similar to a
server. That means that the external communication partner sends a message (command)
across the channel. This message (command) will be executed by the smartcard. Afterwards
the smartcard sends a message (response) back across the same channel. Only after the
external communication partner has received the complete smartcard-message it will be able
to send the next message.
11.2 Electrical Interface
11.2.1 Activation
(N253.00)
The external communication partner MUST activate the smartcard according to
[ISO7816-3] Clause 6.2.1.
(N254.00)
Following the activation according to (N253.00) the external communication partner
MUST execute a Cold Reset according to [ISO7816-3] Clause 6.2.2.
(N255.00)
The smartcard MUST support a Warm Reset according to [ISO7816-3] Clause 6.2.3.
(N256.00)
A Cold Reset according to (N254.00) and a Warm Reset according to (N255.00) can
be understood as special messages of the external communication partner. The
smartcard returns an Answer-to-Reset (ATR) according to [ISO7816-3] Clause 8.2. The
ATR MUST be sent according to [ISO7816-3] Clause 8.1.
(N257.00)
The communication MUST be done using direct convention (see [ISO7816-3]
Clause 8.1). That means that initial character TS in Answer-To-Reset MUST have the
value 3B.
(N258.00)
For the value of the TA1 byte in the ATR it MUST apply: After a
a. Cold Reset, the value MUST be of the set {'18', '95', '96', '97'}.
b. Warm Reset, the value MUST be of the set {'18', '95', '96'}.
(N259.00)
The ATR SHOULD contain a TC1. If TC1 is present, its value MUST be FF.
(N260.00)
In TD1 the ATR MUST indicate the protocol T=1.
(N261.00)
The ATR MUST NOT contain TA2. It follows that the smartcard MUST support the ne-
gotiable mode (see Clause 11.2.4).

(N262.00)
The ATR MUST contain a class indicator according to [ISO7816-3] Table 10. The
class indicator MUST be a value of the set {3, 7}.
11.2.2 Deactivation
(N263.00)
The external communication partner SHOULD deactivate the smartcard according to
[ISO7816-3] Clause 6.4.
(N264.00)
The deactivation MAY be done in a different way.
(N265.00)
When the deactivation is started while a transaction-protected write operation is exe-
cuted (see Clause 14.1) the COS has to guarantee that it follows the rules in
Clause 14.1.1 resp. 14.1.2, before the next command APDU is accepted by the com-
ponent Cmd Interpreter in Figure 1 (N270.50).
11.2.3 Character Frame
(N266.00)
At the physical interface (see Figure 1 (N270.50) characters according to [ISO7816-3]
Clause 7 MUST be used.
11.2.4 Protocol and Parameter Selection
(N267.00)
According to (N261.00) the smartcard MUST show the negotiable mode. Therefore
the smartcard MUST support Protocol and Parameter Selection according to
[ISO7816-3] Clause 9.
(N268.00)
If TA1 in ATR has the value 18, then the smartcard MUST accept a value of the set
{12, 13, 18} in PPS1.
(N269.00)
{92, 93, 94, 95} in PPS1.
(N270.00)
{92, 93, 94, 95, 96} in PPS1.
(N270.10)
{92, 93, 94, 95, 96, 97} in PPS1.
11.3 OSI Reference Model (informative)
According to the ISO reference model, several layers will be defined in this document. These
layers are involved in the processing of the messages sent by an external communication
partner. It is pointed out that the content of this clause does not define details of the imple-
mentation. So it is acceptable to design the internal structure of the smartcard operating sys-
tem or its communication behavior differently. But underlying the following the normative
parts of this document can easier be described and understood:
Figure 1 (N270.50) shows exemplarily how a command APDU CmdApdu1 is pieced together
by the external communication partner. According to the conventions of the transmission
protocol (see Clause 11.8) CmdApdu1 will be divided in the physical layer and in the Data
Link Layer into one or possibly more TPDUs. According to Clause 11.5 these will be reas-
sembled to a CmdApdu1 in the I/O of the smartcard.
The next layer manages logical channels (see [ISO7816-4] Clause 5.1.1.2) and transfers the
received command according to the channel number in the CLA Byte to the corresponding
logical channel, in this case channel_0.
If the command is optionally secured by Secure Messaging it will be decrypted in the next
layer SecMes and, then transferred to the command interpreter.
The command interpreter processes the command APDU and generates a corresponding
response APDU. Optionally the response APDU can be secured by Secure Messaging. In
the I/O this optionally secured response is divided into one or more TPDUs which are trans-
ferred to the external communication partner via the physical interface.
External Channel Channel_0 Cmd

I/O
World Switch SecMes Interpreter
TPDU1
Interpreter
TPDU2.
...
TPDUn
Interface physical
CmdApdu1
CmdApdu2
CmdApdu3
Interface SM
Interface I/O
RspApdu1.
RspApdu2.
RspApdu3. Interface
TPDUn+1.
...
TPDUn+2
TPDUm.
Figure 1: (N270.50) Message Sequence Chart for the Command Handling
11.4 Command Handling
This clause describes the handling of a command being sent by an external communication
partner to the COS. Terms defined in Clause 11.3 are used. It will be explicitly indicated that
the content of Clause 11.3 is not normative. In this respect the exact allocation of the norma-
tive declarations of this clause to parts of the COS is not determined. But it is important that
the behavior of the COS at the physical interface complies with the normative specifications.
The COS supports the concept of logical channels according to [ISO7816-4] in order to make
it possible that several health care professionals bound to multitasking work can create stack
signatures almost in parallel.
For the processing of a command APDU and the generation of a response APDU the follow-
ing steps will be performed:

(N271.00) Via the physical interface an external communication partner sends a command
APDU CmdApdu1 which MUST comply with Clause 11.5. For that purpose CmdApdu1
will be transferred at the physical interface as (one or more) TPDU, according other-
wise transmission protocol (see Clause 11.8).
(N272.00)
The I/O of the smartcard reassembles the TPDUs and gets CmdApdu1.
(N273.00)
The error handling at the physical interface MUST comply with [ISO7816-3]
(N274.00)
Afterwards the channel number MUST be extracted from the CLA Byte of CmdApdu1.
(N275.00)
If the channel with the channel number of the CLA Byte is not opened
a. the processing of the command MUST be terminated.
b. In this case RspApdu3 contains no response data and it consists only of the trailer
ChannelClosed = 68 81.
(N276.00)
According to the channel number CmdApdu1 will be transferred unchanged as
CmdApdu2 to the corresponding logical channel.
(N277.00)
The COS MUST support at the same time at least four open logical channels (basic
channel with number zero plus three further logical channels with channel numbers
one, two and three).
The COS MAY accept further channel numbers.
The COS MAY refuse further channel numbers.
(N278.00)
Within the logical channel CmdApdu2 is transferred with the corresponding channel
context to the Secure Messaging Layer (SecMes in Figure 1 (N270.50)) and proc-
essed according to Clause 13.1.2. The result is RspApdu2.
(N279.00)
RspApdu2 MUST be sent unchanged as RspApdu3 to the I/O of the smartcard.
(N280.00)
According to the used transmission protocol the I/O of the smartcard MUST divide
RspApdu3 into one ore more TPDUs and sent these via the physical interface.
11.5 Command APDU
11.5.1 Class Byte
The Class Byte (CLA Byte) contains the command class. In combination with the Instruction
Byte (see Clause 11.5.2) it defines definitely the command to be executed.
In Clause 14 the combinations of CLA, INS, P1 and P2 to be supported will be defined.
(N281.00)
According to [ISO7816-3] the CLA Byte MUST be coded in an octet.

11.5.2 Instruction Byte
The Instruction Byte (INS Byte) contains the coding for the command to be executed. In
combination with the Class Byte (see Clause 11.5.1) it defines definitely the command to be
executed.
(N282.00)
According to [ISO7816-3] the INS Byte MUST be coded in an octet.
11.5.3 Parameter P1
Normally the parameter P1 contains a variable, which is needed for the execution of the
command. Generally the meaning of this parameter depends on the combination of CLA, INS
and P2.
(N283.00)
According to [ISO7816-3] the parameter P1 MUST be coded in an octet.
11.5.4 Parameter P2
Normally the parameter P2 contains a variable, which is needed for the execution of the
command. Generally the meaning of this parameter depends on the combination of CLA and
INS.
(N284.00)
According to [ISO7816-3] the parameter P2 MUST be coded in an octet.
11.5.5 Data Field
The data field of a command APDU is optional. It is possible that it is absent. The data field is
an octet string with the length Nc. According to [ISO7816-3] the definition range of Nc is {1,
, 65535}.
(N285.00)
At the interface Interpreter (see Figure 1 (N270.50)) it applies for Nc:
a. The COS MUST support all values in the interval [1, 543] for Nc.
b. A COS MAY support additional values for Nc.
c. A COS MAY refuse additional values for Nc.
d. A COS MUST NOT refuse an APDU because of a length error, if
i. the command APDU fulfills the requirements of Clause 11.7 and
ii. the data field fulfills the length restriction of (N285.00)a or the entire command
APDU fulfills the length restriction of EF.ATR.
(N286.00)
The sender of a command APDU SHOULD adhere to the length restriction by choosing
an appropriate Nc.
Note 1: If a COS supports additional values for Nc for specific combinations of CLA, INS, P1 and P2
this should be indicated in EF.ATR.

Note 2: The upper limit in (N285.00)a applies for the COS of a smartcard. Because of future expan-
sions, developments and for performance reasons it is recommended for the IFD (card terminal)
to support at least 2048 = 0800.
Note 3: The upper limit in (N285.00)a is calculated from (N1001.00) et sqq. and (N21.00) as follows:
cipherIn = cipher || plainDO

= A6 LA6 cipherDOin || A0 LA0 [algDO || keyDO]
= A6 LA6 [86 L86 (00 Cin)] || A0 LA0 [80 01 XX || 7F49 L7F49 (81 L81 n || 82 04 e)]
1+ 3+ 1+ 3+ 257 + 1+ 3 + 1+1+ 1 + 2+ 3+ 1+ 3+256+1+1+4 = 543
11.5.6 Le Field
The Le field of a command APDU is optional. It is possible that it is absent. The Le field con-
tains a number Ne, defining how many octets are expected in the data field of a response
APDU. In this document the following definitions apply:
WildCardShort This value is used to indicate, that within the upper limit of 256 octets
all available octets have to be inserted into the data field of the re-
sponse message.
WildCardExtended This value is used to indicate, that within the upper limit of 65536 oc-
tets all available octets have to be inserted into the data field of the
response message.
According to [ISO7816-4] the definition range for Ne is: {1, , 65535, WildCardShort, Wild-
CardExtended}
(N287.00)
At the interface Interpreter (see Figure 1 (N270.50)) it applies for Ne:
a. The COS MUST support all values in the interval [1, 543] for Ne
b. The COS MUST support the value WildCardShort for Ne.
c. The COS MUST support the value WildCardExtended for Ne.
d. A COS MAY support additional values for Ne.
A COS MAY refuse additional values for Ne.
e. A COS MUST NOT refuse an APDU because of a length error, if Ne fulfills the
length restriction of (N287.00)a or the entire response APDU fulfills the length re-
striction of EF.ATR.
(N288.00)
The sender of a command APDU SHOULD adhere to the length restriction by choosing
an appropriate Ne.
Note 1: If a COS supports additional values for Ne for specific combinations of CLA, INS, P1 and P2
this should be indicated in EF.ATR.
Note 2: The upper limit in (N287.00)a applies for the COS of a smartcard and (N288.00) applies for
the external world Because of future expansions, developments and for performance reasons it
is recommended for the IFD (card terminal) to support at least 2048 = 0800.
11.6 Response APDU
For a response APDU it results from the definitions of Clause 11.6.1 and Clause 11.6.2:

(N289.00)
A response APDU MUST be an octet string according to rspData || Trailer,
whereas rspData may be empty.
11.6.1 Data Field
The data field rspData of a response APDU is optional. It is possible that it is absent. The
data field rspData is an octet string of the length Nr. According to [ISO7816-3] the definition
range of Nr is {1, , 65536}.
(N290.00)
At the interface Interpreter (see Figure 1 (N270.50)) it applies for Nr: Nr MUST be
less than or equal to Ne of the corresponding command APDU. If Ne is equal to
a. WildCardShort, then Nr MUST be less than or equal to '100' = 256.
b. WildCardExtended, then Nr MUST be less than or equal to '10000' = 65536.
11.6.2 Trailer
The trailer (see [ISO7816-4] Table 1) consists of two octets. Table 189 (1219.00) shows the
trailers defined in this document. The trailer contains status information about the processing
of the command. Also error indications are part of this information.
11.7 Allowed Command Response Pairs
As described in Clause 11.5.5 and Clause 11.5.6 two elements of the command APDU are
optional. As an outcome of this, four combinations are possible, that are described in the
following.
11.7.1 Case 1 Command Response Pair
In a Case 1 command APDU the data field and the Le field are absent. The command APDU
contains the following information:
Table 10: (N290.50) Case 1 Command APDU
Content Description
CLA XX CLA Byte according to [ISO7816-4]
INS XX Instruction Byte according to [ISO7816-4]
P1 XX first parameter
P2 XX second parameter
According to the rules of Clause 11.5 CLA, INS, P1 and P2 are each coded in an octet.
Therefore it applies for the complete Case 1 command APDU:
(N291.00)
A Case 1 command APDU MUST consist of four octets.
(N292.00)
The four octets of a Case 1 command APDU MUST be concatenated as follows:
CLA || INS || P1 || P2.

The response APDU belonging to a Case 1 command APDU consists of the trailer only.
Table 11: (N292.50) Case 1 Response APDU
Content Description
trailer Status bytes SW1 and SW2
In a Case 2 command APDU the data field is absent. The Le field is present. Depending on
the value of Ne being part of the Le field, the cases short and extended will be distin-
guished.
11.7.2.1 Case 2 Short command
In this case the data field of the response message will never contain more than 256 octets.
The command APDU contains the following information for a Case 2 Short:
Table 12: (N292.60) Case 2 Short command APDU
Content Description
INS XX Instruction Byte according [ISO7816-4]
Ne XX Ne of the set {1, , 255, WildCardShort}
Therefore it applies for the complete Case 2 Short command APDU:
(N293.00)
A Case 2 Short command APDU MUST consist of five octets.
(N294.00)
The value of Ne is coded as follows in an octet named the Le field:
a. If Ne is in the interval [1, 255], then this integer MUST be coded in an octet:
LeField = I2OS( Ne, 1 ).
b. If Ne otherwise has the value WildCardShort, then the Le field MUST be 00.
(N295.00)
The five octets of a Case 2 Short command APDU MUST be concatenated as follows:
CLA || INS || P1 || P2 || LeField
11.7.2.2 Case 2 Extended command
In this case the data field of the response message possibly contains more than 256 octets.
The command APDU for Case 2 Extended contains the following information:

Table 13: (N295.50) Case 2 Extended command APDU
Content Description
Ne XX Ne of the set {256, , 65535, WildCardExtended}
Therefore it applies for the complete Case 2 Extended command APDU:
(N296.00)
A Case 2 Extended command APDU MUST consist of seven octets.
(N297.00)
The value of Ne is coded as follows in two octets forming the Le field:
a. If Ne is in the interval [256, 65535], then this integer MUST be coded in two octets:
LeField = I2OS( Ne, 2 ).
b. If Ne has the value WildCardExtended, then the Le field MUST be 0000.
(N298.00)
The seven octets of a Case 2 Extended command APDU MUST be concatenated as
follows:
CLA || INS || P1 || P2 || 00 || LeField.
Note: The octet 00 after the parameter P2 can be understood as an indicator for extended length.
11.7.2.3 Case 2 Response
The response APDU belonging to a Case 2 command APDU consists of an optional data
field and the trailer.
Content Description
Data Optional part of the response APDU; if present, the rules of
Clause 11.6.1 apply
Trailer Status bytes SW1 and SW2
In a Case 3 command APDU the Le field is absent. The data field is present. Depending on
the number of octets in the data field the cases short and extended will be distinguished.
11.7.3.1 Case 3 Short Command
In this case the data field of the response message will never contain more than 255 octets.
The command APDU contains the following information for a Case 3 Short:

Table 15: (N298.60) Case 3 Short command APDU
Content Description
Data XXYY Data field with any octets, number of octets within the set [1, 255]
(N299.00)
A Case 3 Short command APDU MUST consist of five octets plus the octets of the data
field.
(N300.00)
The number Nc of the octets of the data field MUST be coded in an octet named the Lc
field: LcField = I2OS( Nc, 1 ).
(N301.00)
The five plus Nc octets of a Case 3 Short command APDU MUST be concatenated as
follows:
CLA || INS || P1 || P2 || LcField || Data field.
11.7.3.2 Case 3 Extended Command
In this case the data field of the command message contains more than 255 octets. The
command APDU for Case 3 Extended contains the following information:
Table 16: (N301.50) Case 3 Extended command APDU
Content Description
(N302.00)
A Case 3 Extended command APDU MUST consist of seven octets plus the octets of
the data field.
(N303.00)
The number Nc of the octets of the data field MUST be coded in two octets named the
Lc field: LcField = I2OS( Nc, 2 ).
(N304.00)
The seven plus Nc octets of a Case 3 Extended command APDU MUST be concate-
nated as follows:
CLA || INS || P1 || P2 || 00 || LcField || Data Field.
The response APDU belonging to a Case 3 command APDU consists of the trailer only.
Content Description
A Case 4 command contains all optional parts. Depending on the number of octets in the
data field of the command message and depending on the value of Ne being part of the Le
field, the cases short and extended will be distinguished.
11.7.4.1 Case 4 Short Command
In this case the data field of the command message will never contain more than 255 octets
and the data field of the response message will never contain more than 256 octets. The
command APDU contains the following information for a Case 4 Short:
Table 18: (N304.60) Case 4 Short Command APDU
Content Description
Ne XX Ne of the set {1, , 255, WildCardShort}
Notation CmdApdu = Case4S( CLA, INS, P1, P2, Data, Ne )
(N305.00)
A Case 4 Short command APDU MUST consist of six octets plus the octets of the data
field.
(N306.00)
The number Nc of the octets of the data field MUST be coded in an octet named the Lc
field: LcField = I2OS( Nc, 1 ).
(N307.00)
The value of Ne is coded as follows in an octet forming the Le field:
a. If Ne is in the interval [1, 255], then this integer MUST be used in an octet as Le
field: LeField = I2OS( Ne, 1 ).
b. If Ne otherwise has the value WildCardShort, then the Le field MUST be 00.
(N308.00)
The six plus Nc octets of a Case 4 Short command APDU MUST be concatenated as
follows:
CLA || INS || P1 || P2 || LcFeld || Data Field || LeField.

11.7.4.2 Case 4 Extended Command
In this case the data field of the command message contains more than 255 octets or possi-
bly the data field of the response message contains more than 256 octets. The command
APDU contains the following information for a Case 4 Extended:
Table 19: (N308.50) Case 4 Extended Command APDU
Content Description
Ne XX Ne of the set {1, , 65535, WildCardExtended}
Notation CmdApdu = Case4E( CLA, INS, P1, P2, Data, Ne )
(N309.00)
A Case 4 Extended command APDU MUST consist of nine octets plus the octets of the
data field.
(N310.00)
The number Nc of the octets of the data field MUST be coded in two octets named the
Lc field: LcField = I2OS( Nc, 2 ).
(N311.00)
The value of Ne is coded as follows in two octets forming the Le field:
a. If Ne is in the interval [1, 65535], then this integer MUST be coded in two octets: Le-
Field = I2OS( Ne, 2 ).
b. If Ne otherwise value WildCardExtended, then the Le field MUST be 0000.
(N312.00)
The nine plus Nc octets of a Case 4 Extended command APDU MUST be concate-
nated as follows:
CLA || INS || P1 || P2 || 00 || LcFeld || Data Field || LeField.
The response APDU belonging to a Case 4 command APDU consists of an optional data
field and of the trailer.
Content Description
Data Optional part of the response APDU; if present, the rules of
Clause 11.6.1 apply

11.8 Transmission Protocol
(N313.00)
At the physical interface T = 1 (see Figure 1 (N270.50)) MUST be used as transmission
protocol according to [ISO7816-3] Clause 11.
(N314.00)
For the Information Field Size IFSC (see [ISO7816-3] Clause 11.4.2) the value
FE = 254 MUST be used.
(N315.00)
For the Information Field Size IFSD the value FE = 254 MUST be set via IFSD re-
quest (see [ISO7816-3] Clause 11.4.2).
(N316.00)
The NAD Octet in the TPDU to the smartcard MUST have the value 00.
The COS MAY accept other values.
The COS MAY refuse other values.
(N317.00)
S-Block ABORT MAY be used by the COS, if the I/O-buffer size was ignored.
11.9 Command Chaining
According to [ISO7816-4] Clause 5.1.1.1 Command Chaining allows for chaining consecutive
command-response pairs, which belong together. For this purpose the mechanism is used to
indicate the substeps that all together form a multi-step process. Whereas in [ISO7816-4]
Clause 5.1.1.1 some details are left open, the following behaviour applies for this document:
(N318.00)
Command Chaining is a sequence of command-response pairs with the following char-
acteristics:
a. Except bit b5 in the CLA byte all command APDUs of a chain have identical values
for CLA, INS, P1 and P2.
b. The bit b5 in the CLA Byte of the last commmand APDU of a Command Chaining
sequence has the value 0, the bits b5 of all other CLA bytes of a Command Chain-
ing sequence have the value 1.
c. The statements in (N318.00)a and (N318.00)b apply for command APDU at the "In-
terface I/O" in Figure 1 (N270.50).
(N319.00)
A Command Chaining sequence MUST NOT be interrupted at the "Interface I/O" in
Figure 1 (N270.50)
a. by commands, which do not belong to the sequence.
b. by a deactivation (see Clause 11.2.2).
(N320.00)
If the the external entity does not adhere to the requirement in (N319.00), i.e. the
Command Chaining sequence is interrupted by an interrupting command, then
a. the COS MUST accept the interupting command.
b. the COS MAY accept to continue the interrupted sequence.
c. the COS SHALL refuse to continue the interrupted sequence.

Note: All commands of a chain deliberately have the same channel number and identical Secure Mes-
saging bits according to (N318.00)a. From the combination with (N319.00) it follows that Com-
mand Chaining is not interruptible by commands in other logical channels.

12 Channel Context (normative)
The object system described in Clause 9 bundles the information which is stored in the
smartcard in a persistent way and is available similarly for all logical channels. In this clause
the information will be regarded which is only available in the time between the opening and
the closing of a logical channel therefore being channel-specific. The channel-specific attrib-
utes are combined in the object channelContext.
Typically the attributes mentioned in the following are assigned to a security environment
(see Clause 8.7) or a security status (see Clause 8.8) stored in a volatile memory (in the
RAM), or they will be changed by the command MSE (see Clause 14.9.6).
12.1 Attributes of a Logical Channel
At the physical interface (see Figure 1 (N270.50)) the COS acts as if an object channelCon-
text exists per logical channel, having the following attributes:
(N321.00)
The following attributes of channelContext are assigned to the object system: the
channelContext MUST
a. contain exactly one attribute currentFolder, which points to an object of the type
folder
b. contain exactly one attribute RND.ICC, which stores a random number generated by
the COS (see (N1073.00)).
c. contain exactly one list keyReferenceList. Each list element MUST support a value
indicating that it is empty. The list keyReferenceList MUST consist of the following
parts:
i. externalAuthenticate, with the components keyReference and algorithm-
Identifier
ii. internalAuthenticate, with the components keyReference and algorithm-
Identifier
iii. verifyCertificate, with the component keyReference
iv. signatureCreation, with the components keyReference and algorithmIdenti-
fier.
v. dataDecipher, with the components keyReference and algorithmIdentifier
vi. macCalculation, with the components keyReference and algorithmIdentifier
d. contain exactly one attribute SessionkeyContext containing the following elements:
i. flagSessionEnabled is an attribute with the following values:
1. SK4SM indicates that the rest of the attributes contain cryptographic mate-
rial usable for secure messaging.
2. SK4TC indicates that the rest of the attributes contain cryptographic mate-
rial usable for trusted channel support.
3. noSK indicates that no session keys were negotiated.
ii. Kenc is a symmetrical key for encryption and decryption.

iii. SSenc is an integer being not negative which is used as Send Sequence
Counter in combination with Kenc.
iv. Kmac is a symmetric key being used for MAC calculation and MAC verifica-
tion.
v. SSCmac is an integer being not negative, which is used as Send Sequence
Counter in combination with Kmac.
vi. flagCmdEnc is a variable of Boolean type which indicates whether a secured
command APDU contains a data object with encrypted command data. This
flag will be provided with a value in (N342.00) and evaluated in (N241.00)b.
vii. flagRspEnc is a variable of Boolean type which indicates whether the data of a
response APDU are transferred in encrypted form. This flag will be provided
with a value in (N241.00)c and evaluated in (N348.00) and (N349.00).
e. contain exactly one list globalSecurityList
i. The COS MUST support all values in the interval [0, 3] for the length of this
list.
A COS MAY support longer lists.
f. contain exactly one list dfSpecificSecurityList
i. The COS MUST support all values in the interval [0, 3] for the length of this
list.
g. Each element of the list globalSecurityList and each element of the list dfSpecific-
SecurityList MUST
i. either be a CHA according to (N208.00)a in combination with a reference to a
folder indicating that a successful component authentication according to
(N870.00)g, (N870.00)h, (N870.00)i or (N870.00)j has happened with a key
object assigned to the aforementioned folder (see (N228.00) and (N1019.00)
a.ix), or
ii. be a reference to a symmetric authentication object (see Clause 8.5.1) indicat-
ing that a successful component authentication according to (N870.00)a,
(N870.00)b, (N870.00)c, (N870.00)d, (N870.00)e, (N870.10)a or (N870.10)b
has happened.
h. contain exactly one list bitSecurityList (to be completed for generation 2)
i. contain exactly one list globalPasswordList.
i. The COS MUST support all values of the interval [0, 2] for the length of this
list.
j. contain exactly one list dfSpecificPasswordList.
i. The COS MUST support all values of the interval [0, 2] for the length of this
list.
k. Each element of the list globalPasswordList and each Element of the list dfSpeci-
ficPasswordList MUST be exactly one attribute securityStatusEvaluationCounter in
combination with a reference to a password object. This indicates that a successful
user authentication according to Clause 14.6.6.1 has taken place with this password
object. The range of values of securityStatusEvaluationCounter MUST include all
values of startSsec (see (N161.00)b.ii). It MAY include the value of zero.

(N322.00)
The following attributes of channelContext are assigned to a folder: For each folder in
the object system channelContext MUST
a. contain exactly one attribute seIdentifier according to (N79.00).
b. contain exactly one attribute currentEF which is
i. either undefined,
ii. or points at a list element of currentFolder.children of the type file
12.2 Reset Behavior
A new channel context according to Clause 12.1 will be established if a reset is executed,
or if a new logical channel is opened. Then it applies:
(N323.00)
If the logical channel with the number zero (basic channel) is opened by (N254.00) or
(N255.00), or another logical channel is opened according to Clause 14.9.5, then the
following MUST apply for the new channel being opened:
a. A channel context according to Clause 12.1 will be assigned exclusively to this new
channel being opened.
b. The attribute currentFolder MUST be set to root.
c. The attribute RND.ICC MAY be handled in a manufacturer-specific way.
d. The attribute keyReferenceList MUST be set so that all elements are empty.
e. The attribute SessionkeyContext.flagSessionEnabled MUST be set to noSK.
f. The list globalSecurityList MUST be empty.
g. The list dfSpecificSecurityList MUST be empty.
h. The attribute bitSecurityList (to be completed for generation 2)
i. The list globalPasswordList MUST be empty.
j. The list dfSpecificPasswordList MUST be empty.
k. For all folders it applies:
i. seIdentifier MUST be set to the value 1.
ii. currentEF MUST be set to the value undetermined.
12.3 Set of a Security Status
The routine described here sets the security status of the authentication key handed over as
a parameter.
Input: obj a key object
Output: no return value
Notation: setSecurityStatus( obj )

(N324.00)
If obj
a. is part of the list children in the folder root (see (N210.00)a), then it applies
tmpList = globalSecurityList (see (N321.00)e).
b. is part of a different folder, then it applies
tmpList = dfSpecificSecurityList (see (N321.00)f).
(N325.00)
If obj
a. is a symmetric authentication object (see Clause 8.5.2) and obj
i. already exists in the list tmpList, then terminate this algorithm.
ii. does not exist yet in the list tmpList, then obj MUST be inserted at the begin-
ning of tmpList
b. is a public authentication object (see Clause 8.5.4.2) and obj.publicKey is a RSA key
and obj.CHA (see (N208.00)a)
i. already exists in the list tmpList, then terminate this algorithm.
ii. does not exist yet in the list tmpList, then obj.CHA MUST be inserted at the
beginning of tmpList together with a reference to the directory, which the ob-
ject is also assigned to, thus assigning the security status of obj.CHA to the
same directory as obj.
c. is a symmetric introduction object (see Clause 8.5.1) and obj.CHA (see (N181.00))
i. already exists in the list tmpList, then stop this algorithm.
ii. does not exist yet in the list tmpList, then obj.CHA MUST be inserted at the
beginning of tmpList together with a reference to the directory, which the ob-
ject is also assigned to, thus assigning the security status of obj.CHA to the
same directory as obj.
d. If by additional entries tmpList will become longer than accepted by the COS, then
the COS MUST delete the last list element by means of clearSecurityStatus(...)
(FIFO = first in first out).
(N326.00)
If obj is a public authentication object (see Clause 8.5.4.2) and obj.publicKey is an ELC
key, then (N208.00)b (to be completed for generation 2)
12.4 Deletion of a Security Status
The routine described here deletes the security status of the authentication key passed as a
parameter.
Input: obj a key object
Output: no return value
Notation: clearSecurityStatus( obj )
(N327.00)
If obj

a. is part of the list children in the folder root (see (N210.00)a), then it applies tmpList =
globalSecurityList (see (N321.00)e).
b. is part of a different folder, then it applies tmpList = dfSpecificSecurityList (see
(N321.00)f).
(N328.00)
If obj
a. is a symmetric authentication object (see Clause 8.5.1) and obj in the list tmpList is
i. not existing, then terminate this algorithm.
ii. still existing, then obj MUST be removed from tmpList
b. is a public authentication object (see Clause 8.5.4.2) and obj.publicKey is a RSA key
and obj.CHA (see (N208.00)a) in the list tmpList is
i. not existing, then terminate this algorithm.
ii. still existing, then obj.CHA MUST be removed from tmpList
c. If the security status of a key was deleted, that was involved in the negotiation of
session keys, then flagSessionEnabled (see (N321.00)d.i) MUST be set to noSK.
(N329.00)
If obj is a public authentication object (see Clause 8.5.4.2) and obj.publicKey is a ELC
key, then (N208.00)b (to be completed for generation 2).
12.5 Set of a Password Status
The routine described here sets the security status of the password handed over as a pa-
rameter.
Input: obj A password object
Output: No return value
Notation: setPasswordStatus( obj )
(N330.00)
If obj
a. is part of the list children in the folder root (see (N210.00)a), then it applies tmpList =
globalPasswordList (see (N321.00)i).
b. is part of a different folder, then it applies tmpList = dfSpecificPasswordList (see
(N321.00)j).
(N331.00)
If obj is not present in the list tmpList, then obj MUST be entered at the beginning of
tmpList.
(N332.00)
If by additional entries tmpList will become longer than accepted by the COS, then the
COS MUST delete the last list element (FIFO = first in first out).
(N333.00)
In the entry of obj in tmpList the attribute securityStatusEvaluationCounter MUST be
set to the value of obj.startSsec.

12.6 Deletion of a Password Status
The routine described here deletes the security status of the authentication key handed over
as a parameter.
Input: obj A password object
Output: No return value
Notation: clearPasswordStatus( obj )
(N334.00)
If obj
a. is part of the list children in the folder root (see (N210.00)a), then it applies
tmpList = globalSecurityList (see (N321.00)i).
b. is part of a different folder, then it applies
tmpList = dfSpecificSecurityList (see (N321.00)j).
(N335.00)
If obj is
a. not part of the list tmpList, then stop this algorithm.
b. still part of the list tmpList, then obj MUST be removed from tmpList.

13 Secured Communication (normative)
13.1 Secure Messaging Layer
This clause describes the functionality of layer SecMes in Figure 1 (N270.50). In addition to
the information defined in (N321.00), this layer uses the following further attributes:
KD.i is an octet string which stores a random number generated by the COS. This random
number is used for the derivation of session keys.
KD.e is an octet string which stores an externally generated random number. This random
number is used for the derivation of session keys.
(N336.00)
All normative requirements defined in Chapter 13 and its sub-clauses MUST apply to
HPC, SMC-A and SMC-B. Only the following exception is permitted:
An HPC MAY support the algorithms desSessionkey4TC and rsaSessionkey4TC.
An HPC MAY not support the algorithms desSessionkey4TC and rsaSessionkey4TC.
13.1.1 Derivation of Session Keys
Input: the required input is taken from channelContext

Output: no Output available
Errors: none
Notation: SessionkeyDerivation()
The following definitions apply in this document:

algID = channelContext.keyReferenceList.externalAuthenticate.algorithmIdentifier
PrK = private key that was involved in the authentication referred to in
channelContext.keyReferenceList.internalAuthenticate.keyReference
chr = channelContext.keyReferenceList.externalAuthenticate.keyReference
keyId = chr, after the value has been assigned in keyId
the most significant octet has to be changed according to Clause 8.5.2
(N175.00)
(in this case to be set to the value 02)
cha = attribute CHA (see (N208.00)a) of the key with reference chr
bitList = (to be completed for generation 2)
(N337.00)
If algID indicates the agreement on 3TDES keys, then the following applies:
a. for the attributes of SessionkeyContext:
(Kenc, SSCenc, Kmac, SSCmac) = KeyDerivation_3TDES (KD.i XOR KD.e).
b. the MSByte in keyId is replaced by the octet 02.
(N338.00)
If algID indicates the negotiation of AES-128 keys, then (to be completed for gen-
meration 2)
(N339.00)
If algID indicates that the session keys
a. have to be used in the context of Secure Messaging, then set
SessionkeyContext.flagSessionEnabled = SK4SM.
b. have to support the operation of a trusted channel, then
i. set SessionkeyContext.flagSessionEnabled = SK4TC and
ii. enter a card manufacturer-specific keyReference in channelContext.key-
ReferenceList.dataDecipher and set algorithmReference = desSession-
key4TC.
iii. enter a card manufacturer-specific keyReference in channelContext.keyRefe-
renceList.macCalculation and set algorithmReference = desSessionkey4TC.
c. are to be stored persistently, then set
SessionkeyContext.flagSessionEnabled = noSK
(N340.00)
If algID indicates that the session keys are to be persistently stored, then it applies:
a. obj = SearchKey( currentFolder, keyId, algID ). If the search was not successful,
then obj MUST be set to any element of persistentIntroductionkeyList.
b. The attributes of the list element referred by obj are set to the following values:
i. obj.keyIdentifier = keyId.
ii. obj.accessRuleList = PrK.accessRuleList.
iii. obj.encKey = Kenc.
iv. obj.macKey = Kmac.
v. obj.cha = cha.
vi. For the attribute listAlgorithmIdentifier applies
1. Step 1: obj.listAlgorithmIdentifier = {desRoleCheck}
2. Step 2: If PrK.listAlgorithmIdentifier contains values of the set { rsaClientAu-
thentication, rsaRoleAuthentication}, then it applies:
obj.listAlgorithmIdentifier += desRoleAuthentication
3. Step 3: If PrK.listAlgorithmIdentifier contains the value rsaSessionkey4SM,
then it applies:
obj.listAlgorithmIdentifier += desSessionkey4SM
4. Step 4: If PrK.listAlgorithmIdentifier contains the value rsaSessionkey4TC,
then it applies:
obj.listAlgorithmIdentifier += desSessionkey4TC
vii. If the private key which algID belongs to, is assigned to the same or a lower
level than the public key which is referred by chr, then obj MUST be assigned
to the directory of the private key.
viii. Otherwise obj MUST be assigned to the directory of the public key.
c. clearSecurityStatus (obj) MUST be executed.

13.1.2 Processing an APDU command
(N341.00)
If no Secure Messaging is indicated in the CLA byte (see [ISO7816-4] Clause 5.1.1)
and SessionkeyContext.flagSessionEnabled has the value
a. SK4SM, then
i. the security status of the key that was involved in the negotiation of the ses-
sion keys MUST be deleted by means of clearSecurityStatus(...).
ii. CmdApdu3 = CmdApdu2 MUST be set.
b. Otherwise CmdApdu3 = CmdApdu2 MUST be set.
(N342.00)
If Secure Messaging is indicated in the CLA byte and flagSessionEnabled has the
value
a. SK4SM, then
i. the secured CmdApdu2 MUST comply to the normative requirements in
Clause 13.2. If a DO with Tag = 87 is present in CmdApdu2, flagCmdEnc
MUST be set to True, otherwise to False.
The COS MAY accept further Secure Messaging formats.
The COS MAY refuse further Secure Messaging formats.
ii. the secured CmdApdu2 MUST be released according to the rules defined in
Clause 13.2 resulting in CmdApdu3. If and only if an error occurs in the proc-
ess, then
1. the security status of the key that was involved in the negotiation of the
session keys MUST be deleted (see Clause 12.4) by means of clearSecuri-
tyStatus(...).
2. the processing of the command MUST terminate.
3. In this case RspApdu2 does not contain any response data but solely con-
sists of the trailer IncorrectSmDo = 69 88.
b. otherwise
i. the command processing MUST terminate.
ii. In this case RspApdu2 does not contain any response data but solely consists
of the trailer IncorrectSmDo = 69 88.
(N343.00)
The CmdApdu3 that was forwarded by the Secure Messaging layer (SecMes in
Figure 1 (N270.50)) MUST be processed according to the requirements defined in this
document. This will result in a response RspApdu1. It is assumed that the Secure Mes-
saging layer pre-processes the CmdApdu3 in such a way that Secure Messaging will
not be indicated in the CLA Byte and the channel number will be set to zero.
(N344.00)
If flagSessionEnabled has the value
a. SK4SM, then the unsecured RspApdu1 MUST be transformed according to Clause
13.3 into the secured RspApdu2.
b. SK4TC or noSK, then RspApdu2 = RspApdu1 MUST be set.
(N345.00)
If KD.i as well as KD.e are present (i.e. one or both values were set in the command
that was processed just before), then

a. SessionkeyContext MUST be changed using SessionkeyDerivation() (see Clause
13.1.1) and afterwards
b. KD.i and KD.e MUST be set to not available.
13.2 Securing a Command APDU
This sub-clause describes how a command APDU has to be secured according to

Clause 11.5. The rules described here are addressed to the entity sending the command
APDUs (whereas the COS of the smartcard that processes the commands sent with Secure
Messaging will execute the corresponding reverse operations) as well as to the COS of the
smartcard, which supports the trusted channel by creating and verifying Secure Messaging
data objects (usually an SMC). The COS of the SMC uses parts of the processes defined in
the following while executing the commands PSO: COMPUTE CC (see Clause 14.8.2) and
PSO: ENCIPHER (see Clause 14.8.4). The optional ENVELOPE command (see Clause
14.9.1) successively uses the processes from (N346.00) to (N355.00).
Generally a subset of the rules from [ISO7816-4] Clause 6 will be described here, whereas
all command APDUs will be transferred with integrity protection,
the command headers will be transferred always with integrity protection,
command data will be transferred as plaintext or as cipher text.

It should be pointed out that usually the sender has the choice to send the command data as
plaintext or as cryptogram, but the access condition may enforce an encrypted transfer.
From a generic point of view a command APDU consists of the octets CLA, INS, P1 and P2
as well as of the optional data field and the optional LeField as described in Clause 11.5.
Therefore the following definitions apply:
Input: CLA Octet according to (N281.00)
INS Octet according to (N282.00)
P1 Octet according to (N283.00)
P2 Octet according to (N284.00)
Data Optional octet string according to Clause 11.5.5
LeField Optional octet string according to Clause 11.5.6, which contains a

number Ne according to (N294.00) or (N297.00).
Kenc Symmetric key for encryption, see (N321.00)d.ii
SSCenc any number being not negative, to be used as Send Sequence

Counter for encryption, see (N321.00)d.iii
Kmac Symmetric key for MAC calculation, see (N321.00)d.iv
SSCmac any number being not negative, to be used as Send Sequence

Counter for MAC calculation, see (N321.00)d.v
Output: CmdApdu Secured command APDU

Errors: none
To secure a generic command APDU, the following steps have to be executed:

(N346.00)
If the optional data field Data is not present, then ProtectedData = (empty octet
string).
(N347.00)
If the optional data field Data is present and is transferred in plaintext, then
a. Set lenPDO = OctetLength( Data ), if lenPDO is in the interval
i. [1, 127], then it applies: LenP = I2OS(lenPDO, 1)
ii. [128, 255], then it applies: LenP = 81 || I2OS(lenPDO, 1)
iii. [256, 65535], then it applies: LenP= 82 || I2OS(lenPDO, 2)
b. Set ProtectedData = 81 || LenP || Data
(N348.00)
If the optional data field Data is present and is transferred in encrypted form
(flagRspEnc is True, see (N321.00)d.vii and (N241.00)d) and Kenc is a 3TDES key,
then it applies:
a. SSCenc = SSCenc + 1
b. C = 3TDES_CBC_ENC( Kenc, SSCenc, PaddingIso( Data, 8 ) )
c. Set lenCDO = OctetLength( C ) + 1, if lenCDO is in the interval
i. [1, 127], then it applies: LenC = I2OS(lenCDO, 1)
ii. [128, 255], then it applies: LenC = 81 || I2OS(lenCDO, 1)
iii. [256, 65535], then it applies: LenC = 82 || I2OS(lenCDO, 2)
d. Set ProtectedData = 87 || LenC || 01 || C
(N349.00)
(flagRspEnc is True, see (N321.00)d.vii and (N241.00)d) and Kenc is an AES key,
then it applies:
a. ( C, SSCenc ) = AES_CTR_ENC( Kenc, SSCenc, Data )
b. Set lenCDO = OctetLength( C ) + 1, if lenCDO is in the interval
iii. [256, 65535], then it applies: LenC = 82 || I2OS(lenCDO, 2)
c. Set ProtectedData = 87 || LenC || 02 || C
(N350.00)
If the optional LeField
a. is not present, then it applies: LeDO = , (empty octet string).
b. is present, then it applies: LeDO = 97 || I2OS(OctetLength(LeField), 1) || LeField
(N351.00)
If the channel number in the CLA Byte is in the interval

a. [0,3], then set: CLA' = CLA OR '0C', the bits b4 and b3 in CLA byte are set.
b. [4,19], then set: CLA' = CLA OR '20', the bit b6 in the CLA byte is set.
(N352.00)
If the channel number in the CLA Byte is in the interval
a. [0,3], then set: head = CLA' || INS || P1 || P2
b. [4,19], then set: head = '89 04' || CLA' || INS || P1 || P2
(N353.00)
Set: SSCmac = SSCmac + 1
(N354.00)
It applies: tmpData = ProtectedData || LeDO
If Kmac is
a. a 3TDES key, then it applies:
i. MACin = I2OS( SSCmac, 8 )
ii. If OctetLength( tmpData )
1. equals 0, then it applies:
MACin = MACin || head
2. does not equal 0, then it applies:
MACin = MACin || PaddingIso( head, 8 ) || tmpData
iii. MAC = CALCULATE_Retail_MAC( Kmac, MACin )
b. a AES key, then it applies:
ii. If OctetLength( tmpData )
1. equals 0, then it applies:
MACin = MACin || head
2. does not equal 0, then it applies:
MACin = MACin || PaddingIso( head, 16 ) || tmpData
iii. MAC = CALCULATE_CMAC( Kmac, MACin )
(N355.00)
Set: MDO = 8E || I2OS(OctetLength(MAC), 1) || MAC
(N356.00)
Set: newD = ProtectedData || LeDO || MDO
(N357.00)
Case 1: If Data and LeField are absent, then set:
CmdApdu = Case4S(CLA, INS, P1, P2, newD, WildCardShort)
(N358.00)
Case 2: If Data is absent and LeField is present, then set:
CmdApdu = Case4E(CLA, INS, P1, P2, newD, WildCardExtended)
(N359.00)
Case 3: If Data is present and LeField is absent and OctetLength( newD )
a. is less than or equal to 255, then it applies:
CmdApdu = Case4S(CLA, INS, P1, P2, newD, WildCardShort)
b. is greater than or equal to 256, then it applies:

(N360.00)
Case 4: If Data and LeField are present, then set:
Note 1: For (N357.00) and (N359.00)a: According to Clause 11.7.1 (11.7.3) the corresponding re-
sponse APDU to a Case 1 (Case 3) command APDU will never have answering data. In addition
only symmetric processes will be used in Clause 13.3. The consequence: a secured response
APDU to a unsecured Case 1 (Case 3) APDU will never have more than 256 Byte response data.
Therefore a Case 4 Short command APDU will be used here instead of the secured Case 1
(Case 3) command APDU.
Note 2: For (N358.00) and (N360.00): According to Clause 11.7.2.1 (11.7.4.1) the corresponding re-
sponse APDU to a Case 2 Short (Case 4 Short) command APDU has up to 256 octets response
data. Therefore - according to Clause 13.3 - it is possible that a secured response APDU to an
unsecured Case 2 Short (Case 4 Short) APDU has more than 256 Byte response data. Therefore
also for the secured Case 2 Short (Case 4 Short) command APDU a Case 4 Extended command
APDU is used.
13.3 Securing a Response APDU
This sub-clause describes how a response APDU has to be secured according to

Clause 11.6. The rules described here are addressed to the COS of the smartcard, which
processes the Secure Messaging commands (usually HPC and SMC-B). The COS of the
smartcard, which processes SM data objects of the response APDU (usually an SMC), exe-
cutes the reverse operations of the processes defined in the following. For this purpose the
commands PSO: DECIPHER (see Clause 14.8.3) and PSO: VERIFY CC (see Clause
14.8.5) are used. The optional ENVELOPE command (see Clause 14.9.1) uses the reverse
operations of the processes defined in (N361.00) through (N369.00).
Generally a subset of the rules from [ISO7816-4] Clause 6 will be described here, whereas
all response APDUs will be transferred with integrity protection,
the trailer will be transferred always with integrity protection,
response data will be transferred as plaintext or as cipher text

It should be noted that - based on the used access rules - the COS of the smartcard, which
processes the Secure Messaging commands, decides whether the response data are sent
as plaintext or as a cryptogram.
From a generic point of view a command APDU consists of the optional data field and the
trailer as described in Clause 11.6. Therefore the following definitions apply:
Input: Data Optional octet string according to 11.6.1
Trailer Octet string according to 11.6.2
Kenc Symmetric key for encryption, (N321.00)d.ii
SSCenc Any number being not negative to be used as Send Sequence

Counter for encryption, (N321.00)d.iii
Kmac Symmetric key for MAC calculation, (N321.00)d.iv
SSCmac Any number being not negative to be used as Send Sequence

Counter for MAC calculation, (N321.00)d.v

Output: RspApdu Secured response APDU
Errors: none
To secure a generic response APDU, the following steps have to be executed:

(N361.00)
If the optional data field Data is not present, then ProtectedData = (empty octet
string).
(N362.00)
If the optional data field Data is present and is transferred in plaintext, then
a. Set lenPDO = OctetLength( Data ), if lenPDO is in the interval
i. [1, 127], then it applies: LenP = I2OS(lenPDO, 1)
ii. [128, 255], then it applies: LenP = 81 || I2OS(lenPDO, 1)
iii. [256, 65535], then it applies LenP= 82 || I2OS(lenPDO, 2)
b. Set ProtectedData = 81 || LenP || Data
(N363.00)
(flagRspEnc is True; see (N321.00)d.vii and (N241.00)d) and Kenc is a 3TDES key,
then it applies:
a. SSCenc = SSCenc + 1
b. C = 3TDES_CBC_ENC( Kenc, SSCenc, PaddingIso( Data, 8 ) )
c. Set lenCDO = OctetLength( C ) + 1, if lenCDO is in the interval
iii. [256, 65535], then it applies LenC = 82 || I2OS(lenCDO, 2)
d. Set ProtectedData = 87 || LenC || 01 || C
(N364.00)
(flagRspEnc ist True; see (N321.00)d.vii and (N241.00)d) and Kenc is an AES key,
then it applies:
a. ( C, SSCenc ) = AES_CTR_ENC( Kenc, SSCenc, Data )
b. Set lenCDO = OctetLength( C ) + 1, if lenCDO is in the interval
iii. [256, 65535], then it applies LenC = 82 || I2OS(lenCDO, 2)
c. Set ProtectedData = 87 || LenC || 02 || C
(N365.00)
Set TDO = 99 02 || Trailer
(N366.00)
Set SSCmac = SSCmac + 1

(N367.00)
If Kmac is
a. a 3TDES key, then it applies:
ii. MACin = MACin || ProtectedData
iii. MACin = MACin || TDO
iv. MAC = CALCULATE_Retail_MAC( Kmac, MACin )
b. an AES key, then it applies:
ii. MACin = MACin || ProtectedData
iii. MACin = MACin || TDO
iv. MAC = CALCULATE_CMAC( Kmac, MACin )
(N368.00)
Set: MDO = 8E || I2OS(OctetLength(MAC), 1) || MAC
(N369.00)
It applies for the secured response APDU RspApdu:
a. RspApdu.RspData = ProtectedData || TDO || MDO
b. RspApdu.Trailer = Trailer

14 Commands (normative)
(N370.00)
The COS MAY support combinations of CLA, INS, P1 and P2 which are not listed in
this chapter.
14.1 Roll-Back and Roll-Forward
In the following clauses it is casually mentioned that the persistent memory has to be
changed with Roll-Forward or Roll-Back. As a generic term transaction protection is
used to show that Roll-Forward or Roll-back is meant. In short this implies the following:
for technical reasons the persistent storage of information will last some milliseconds. Smart-
cards are not able to buffer the loss of electric power. So it may be that this loss of electric
power happens in a moment in which the status of the memory is undefined. The transaction
protection defines how to deal with an undefined status of the memory.
Figure 2: (N370.50) Timeline of a Roll-Back command
For the execution of a command with transaction protection the following points of time will
be defined, as shown in Figure 2 (N370.50):
At time t0 the first bit of the command APDU is sent via the physical interface to the smart-
card (see Figure 1 (N270.50)).
At time t1 the execution of the command has reached the status that the temporary buffer
is ready to be filled.
At time t2 the temporary buffer is completely filled, but the content is not yet marked as
valid.
At time t3 the content is marked as valid and the actual persistent change is going to be
started.
At time t4 the actual persistent change is finished but the content of the temporary buffer is
still marked as valid.
At time t5 the content of the temporary buffer is marked as invalid.
At time te (not shown in Figure 2 (N370.50)) the smartcard has sent the last bit of the re-
sponse APDU via the physical interface.
(N371.00)
This Document does not define in which chronological relationship te is in respect to the
other time points. Therefore, te MAY be at any time time after t0.

14.1.1 Roll-Back
Roll-Back determines how an operation which has been interrupted by a loss of electric
power will be reversed when the electric power is back. Typically before a change the origi-
nal content of the memory will be written to a temporary memory. Then the change will be
executed. Afterwards the content of the temporary memory will be marked as invalid.
(N372.00)
If the loss of electric power occurs
a. before t4:, then either the change has not been executed or the content of the tem-
porary memory has definitely been set to valid. The (original) content of the tempo-
rary memory MUST be recovered after the electric power is back again.
b. after t5:, then the content of the temporary memory is definitely set to invalid. The
recovery of the original content is impossible.
c. between t4 and t5:, then the status of the temporary memory is by chance either
valid or invalid (physical memories definitely show no time- or valued-discrete
behavior).
In this case the original status MAY be restored.
In this case the new status MAY be kept.
14.1.2 Roll-Forward
Roll-Forward determines how an operation which has been interrupted by a loss of electric
power will be reversed when the electric power is back. Typically before a change the new
content of the memory will be written to a temporary memory. Then the change will be exe-
cuted. Afterwards the content of the temporary memory will be marked as invalid.
(N373.00)
If the loss of electric power occurs
a. before t2:, then the content of the temporary memory has definitely not been set to
valid. The change to the new status is impossible.
b. after t3:, then the content of the temporary memory is definitely set to valid. The
content (being new) of the temporary memory MUST be recovered after the electric
power is back.
c. between t2 and t3:, then the status of the temporary memory is by chance either
valid or invalid (physical memories definitely show no time- or valued-discrete
behavior).
In this case the original status MAY be kept.
In this case the new status MAY be set.
14.2 Management of the Object System
14.2.1 ACTIVATE
The command ACTIVATE activates a file in a reversible way. The file being affected will be
chosen before the execution of the command. This is done by a select-operation (command
SELECT or command with shortFileIdentifier) before the command ACTIVATE is sent.
14.2.1.1 Use Case Activation of a Folder or a File
In this variant the APDU of the command ACTIVATE contains no parameter:

(N374.00)
A case 1 command APDU MUST be sent via the interface Interpreter of Figure 1
(N270.50), according to Clause 11.7.1. For the construction of this case 1 command
APDU the instructions of Table 21 (N374.40) MUST be used.
Table 21: (N374.40) ACTIVATE current File
Description
CLA 00 CLA Byte according to [ISO7816-4]
INS 44 Instruction Byte according to [ISO7816-4]
P1 00
P2 00
14.2.1.2 Response of the Smartcard to the Activation of a File

Table 22: (N374.50) ACTIVATE response APDU in the case of success
Trailer Content Description

90 00 NoError Successful activation
63 Cx UpdateRetryWarning like NoError, but problems with writing
Table 23: (N374.60) ACTIVATE response APDU in case of failure

69 82 SecurityStatusNotSatisfied Access rule not fulfilled
65 81 MemoryFailure Writing not successful
Note: This table contains no errors, which are detected in the components I/O, ChannelSwitch and
SecMes from Figure 1 (N270.50).
(N375.00)
A COS MAY use additional trailers.
14.2.1.3 Command processing inside the smartcard

(N376.00)
The COS MUST support the variant for ACTIVATE from 14.2.1.1.
The COS MAY support additional variants for ACTIVATE.
The COS MAY refuse additional variants for ACTIVATE.
(N377.00)
If currentEF
a. points to a file, then affectedObject MUST be set equal to currentEF
b. otherwise affectedObject MUST be set equal to currentFolder.
(N378.00)
If and only if AccessRuleEvaluation( affectedObject, CLA, INS, P1, P2 ) returns False,
then the command MUST be terminated with the trailer SecurityStatusNotSatisfied
(N379.00)
If the physical value of lifeCycleStatus of affectedObject has the value Operational
state (activated) the trailer NoError MUST be used.

(N380.00)
The physical value of lifeCycleStatus of affectedObject MUST be set to the value Op-
erational state (activated) by the transaction protection.
(N381.00)
If and only if the COS has realized that the writing operation has not been successful
with the first try the COS MAY choose UpdateRetryWarning as trailer.
(N382.00)
If and only if a writing operation has not been successful, MemoryFailure MUST be
used as trailer.
(N383.00)
Otherwise NoError MUST be used as trailer.
(N384.00)
The following applies for the priority of the trailers:
a. The priority of the trailers in Table 23 (N374.60) is manufacturer-specific.
b. Each trailer in Table 23 (N374.60) MUST have a higher priority than UpdateRetry-
Warning.
c. UpdateRetryWarning MUST have a higher priority than NoError.
14.2.2 CREATE
(N385.00)
The COS MAY support this command according to [ISO7816-9].
The COS MAY refuse this command according to [ISO7816-9].
Note: Within this document the functionality of this command will be provided by the command LOAD
APPLICATION (see Clause 14.2.5).
14.2.3 DEACTIVATE
The command DEACTIVATE deactivates a file in a reversible way. The file being affected
will be chosen before the execution of the command. This is done by a select-operation
(command SELECT or command with shortFileIdentifier) before the command DEACTIVATE
is sent.
14.2.3.1 Use Case Deactivation of a Folder or a File
In this variant the APDU of the command DEACTIVATE contains no parameter.

(N386.00)
Table 24: (N386.40) DEACTIVATE current File
Content Description
P1 00
P2 00

14.2.3.2 Response of the smartcard to the Deactivation of a File
Table 25: (N386.50) DEACTIVATE response APDU in the case of success

90 00 NoError Deactivation successful
Table 26: (N386.60) DEACTIVATE response APDU in case of failure

69 82 SecurityStatusNotSatisfied Access rule not fulfilled
65 81 MemoryFailure Writing not successful
(N387.00)

(N388.00)
The COS MUST support the variant for DEACTIVATE from 14.2.3.1.
The COS MAY support additional variants for DEACTIVATE.
The COS MAY refuse additional variants for DEACTIVATE.
(N389.00)
If currentEF
a. points to a file, then affectedObject MUST be set equal to currentEF.
b. otherwise affectedObject MUST be set equal to currentFolder.
(N390.00)
then the command MUST be terminated with the trailer SecurityStatusNotSatisfied.
(N391.00)
If the physical value of lifeCycleStatus of affectedObject has already the value Opera-
tional state (deactivated) the trailer NoError MUST be used.
(N392.00)
The physical value of lifeCycleStatus of affectedObject MUST be set to the value Op-
erational state (deactivated) by the transaction protection.
(N393.00)
If and only if the COS has realized internally that the writing operation has not been
successful with the first try the COS MAY choose UpdateRetryWarning as trailer.
(N394.00)
used as trailer.
(N395.00)
(N396.00)

Warning.
14.2.4 DELETE
The command DELETE deletes objects of the type file from the object system. The file being
affected will be chosen before the execution of the command. This is done by a select-
operation (command SELECT or command with shortFileIdentifier) before the command DE-
LETE is sent.
14.2.4.1 Use Case Deletion of a Folder or a File

(N397.00)
If more than one logical channel is opened, then
a. a DELETE command MUST NOT be sent.
b. the COS MAY accept a DELETE command.
c. the COS MAY refuse a DELETE command.
In this variant the APDU of the command DELETE contains no parameter:
(N398.00)
Table 27: (N398.40) DELETE current File
Content Description
INS E4 Instruction Byte according to [ISO7816-4]
P1 00
P2 00
14.2.4.2 Response of the smartcard to the Deletion of a File

Table 28: (N398.50) DELETE Response APDU in case of success

90 00 NoError Delete operation successful
Table 29: (N398.60) DELETE Response APDU in case of failure

69 82 SecurityStatusNotSatisfied Access condition not satisfied
65 81 MemoryFailure Writing operation not successful

(N399.00)

(N400.00)
The COS MUST support the variant for DELETE from 14.2.1.1.
The COS MAY support additional variants for DELETE.
The COS MAY refuse additional variants for DELETE.
(N401.00)
If currentEF
a. points to a file, then affectedObject MUST be set equal to currentEF
b. otherwise affectedObject MUST be set equal to currentFolder
(N402.00)
(N403.00)
The delete operation MUST be executed with transaction protection.
(N404.00)
If affectedObject is of the type
a. folder, then
i. currentEF MUST be set to the value undefined and
ii. currentFolder MUST be set to the father of affectedObject and
iii. affectedObject MUST be deleted including sub-tree
b. file, then
i. currentEF MUST be set to the value undefined and
ii. affectedObject MUST be deleted.
(N405.00)
The memory allocated for affectedObject MUST be deallocated so that it could be used
to define other objects
(N406.00)
successful with the first try the COS MAY choose UpdateRetryWarning as trailer
(N407.00)
used as trailer.
(N408.00)
(N409.00)
a. The priority of the trailers in Table 29 (N398.60) is manufacturer-specific
Warning
c. UpdateRetryWarning MUST have a higher priority than NoError
(N410.00)
In case of failure currentFolder and currentEF MUST remain unchanged with the val-
ues they had before the command was executed.
14.2.5 LOAD APPLICATION
The command LOAD APPLICATION is used to create new files to the object system. It is
possible to create
- a new folder including a sub-tree
- a new file including content (transparent or structured).
The created file is stored in currentFolder. Typically the amount of data to be transferred to
the smartcard is too large to be sent with a single command APDU. Therefore this command
supports Command Chaining.
14.2.5.1 Use Case Creation of a new Object, not end of the command sequence
This variant has to be chosen if the amount of data cannot be transferred with only one
command APDU. It is used from the first to the last command APDU. The last command
APDU will be transferred according to 14.2.5.2. In the variant described here the APDU of
the command LOAD APPLICATION contains two parameters.
(N411.00)
The CLA-byte shows that this command APDU is not the last one of a command chain.
This is coded by the value CLA = 10.
(N412.00)
The parameter cmdData contains data describing the file to be created. The parameter
cmdData is an octet string with any content which is manufacturer-specific. The length
of cmdData is subject to the restrictions of Clause 11.5.5.
(N413.00)
Table 30: (N413.50) LOAD APPLICATION with Command Chaining
Content Description
CLA 10 CLA Byte according to [ISO7816-4], Chaining Bit b5 is set
INS EA Instruction Byte according to [ISO7816-4],
P1 00
P2 00
Data XXYY cmdData
14.2.5.2 Use Case Creation of a new Object, End of Command Chain
This variant has to be chosen if the amount of data can be transferred with only one com-
mand APDU, or if it is the last command of a command chain. In this variant the APDU of the
command LOAD APPLICATION contains one parameter.
(N414.00)
The parameter cmdData contains data describing the file to be created. The parameter

cmdData is an octet string with any content which is manufacturer-specific. The length
of cmdData is subject to the restrictions of Clause 11.5.5.
(N415.00)
Table 31: (N415.40) LOAD APPLICATION without Command Chaining
Content Description
INS EA Instruction Byte according to [ISO7816-4]
P1 00
P2 00
Data XXYY cmdData
14.2.5.3 Response of the Smartcard to the Creation of a new object

Table 32: (N415.50) LOAD APPLICATION Response APDU in case of success

90 00 NoError Download successful
Table 33: (N415.60) LOAD APPLICATION Response APDU in case of failure

6A 8A DfNameExists AID of the new object already used
6A 89 DuplicatedObject Identifier of the new object already used
6A 84 OutOfMemory Not enough memory space for the new object
(N416.00)

(N417.00)
The COS MUST support the variant for LOAD APPLICATION from 14.2.5.1 and
14.2.5.2.
The COS MAY support additional variants for LOAD APPLICATION.
The COS MAY refuse additional variants for LOAD APPLICATION.
(N418.00)
currentFolder MUST be used as affectedObject.
(N419.00)
(N420.00)
The command and therefore a command chain eventually being active MAY be ac-
cepted or refused if the file to be created
a. is a folder and has an attribute applicationIdentifier and this applicationIdentifier is
already dedicated to another folder in the object system, or
b. is a folder and has an attribute fileIdentifier and this fileIdentifier is dedicated to an-
other file in affectedObject, or
c. is a file and has an attribue fileIdentifier which is already dedicated to another file in
affectedObject, or
d. is a file and has an attribue shortfileIdentifier which is already dedicated to another
file in affectedObject.
(N421.00)
The command MUST be accepted if the object to be created
a. is a folder and has an attribute applicationIdentifier and this applicationIdentifier is
not assigned to another folder in the object system,
b. is a folder and has an attribute fileIdentifier and this fileIdentifier is not assigned to
another file in affectedObject, or
c. is a file and has an attribute fileIdentifier and this fileIdentifier is not assigned to an-
other file in affectedObject, or
d. is a file and has an attribute shortfileIdentifier and this shortfileIdentifier is not as-
signed to another file in affectedObject.
(N422.00)
If altogether enough but not enough consecutive memory space is available, then the
COS MUST internally reallocate memory so that the operation can be executed suc-
cessfully. Typically this operation is named defragmentation.
Note: It is possible to test request (N422.00) as follows:
a) Starting point is a smartcard with an object system with only a very small (minimal) number of
objects.
b) In a first step a file (transparent or structured chosen by accident) will be created with 200 byte
user data.
c) Step b will be repeated until the command LOAD APPLICATION terminates with the trailer Ou-
tOfMemory.
d) In a second step two of these created files are chosen by accident and deleted. Then a new
file (transparent or structured chosen by accident) is created with LOAD APPLICATION. If the
sum of user data of the files being deleted in this step is x, then the size of the user data of the
file being newly created should also be x. It is expected that the command LOAD APPLICATION
will not be terminated with OutOfMemory.
e) Step d) will be repeated until only one file remains, which is created by this algorithm, or the
remaining files have the maximum possible file size according to (N118.00) and (N133.00).
(N133.00) relates to linear variable EF, but the same applies to other linear EF.
(N423.00)
If and only if not enough memory space is available to create a new object, then the
COS MUST terminate the command with the trailer OutOfMemory.
(N424.00)
successful with the first try, then the COS MAY choose UpdateRetryWarning as trailer.
(N425.00)
If and only if a writing operation has not been successful, then MemoryFailure MUST
be used as trailer.

(N426.00)
(N427.00)
Warning.
(N428.00)
If this is the only or the last command of a command chain and the newly created ob-
ject is
a. a folder, then currentFolder MUST be set to the newly created folder in the case of
success. Thereby the rules to set the channel context have to be considered (see
(N509.00)b).
b. a file, then currentEF MUST be set to the newly created file in the case of success.
(N429.00)
If the command was not executed successfully, then currentFolder and currentEF
MUST NOT be changed.
(N430.00)
If this command LOAD APPLICATION is terminated with a trailer from Table 33
(N415.60), then a Command Chaining being possibly active must be aborted.
(N431.00)
The object being newly created respectively to be created MUST be deleted from the
object system including the possibly allocated memory space (complete Roll-Back of
the chain), if
a. the command LOAD APPLICATION terminates with a trailer from Table 33
(N415.60), or
b. the command LOAD APPLICATION is terminated during execution by a reset, or
c. a command chain is aborted.
14.2.6 SELECT
The command SELECT searches for a file (folder or file) in the object system and selects it.
In many cases the selection is the condition for other use cases (read, write) to be executed
successfully. Optionally the main attributes of the files can be reported in the response data.
The file to be selected is determined by the parameters of the command-APDU.
14.2.6.1 Use Case Selection without AID, first occurence, no response data
This variant selects the root directory of the object system. In this variant the APDU of the
command SELECT contains three parameters:
(N432.00)
The parameter selectionMode determines the kind of search. For this use case selec-
tionMode = 04 MUST be set.

(N433.00)
The parameter fileOccurrence determines which file will be selected in a list of appro-
priate files. For this use case fileOccurrence = 0 MUST be set.
(N434.00)
The parameter responseType determines the kind of response data. For this use case
responseType = 0C MUST be set.
(N435.00)
Table 34: (N435.50) SELECT, no AID, first occurrence, no response data
Content Description
INS A4 Instruction Byte according to [ISO7816-4]
P1 04 selectionMode = selection of folder with applicationIdentifier (in this case
empty)
P2 0C fileOccurrence + responseType = first occurrence, no response data
14.2.6.2 Use Case Selection without AID, first occurrence, Response Data with FCP
This variant selects the root directory of the object system. In this variant the APDU of the
command SELECT contains four parameters:
(N436.00)
(N437.00)
(N438.00)
responseType = 04 MUST be set.
(N439.00)
The parameter length determines the length of the response data being expected. The
value of length MUST be chosen from the range defined in Clause 11.5.6.
(N440.00)

Table 35: (N440.50) SELECT, no AID, first occurrence, response data with FCP
Content Description
empty)
P2 04 fileOccurrence + responseType = first occurrence, response data with
FCP
Ne length Expected number of octets in the response data
14.2.6.3 Use Case Selection without AID, next occurrence, no response data
The repeated execution of this variant selects all folders consecutively having the attribute
applicationIdentifier (applications according to Clause 8.3.1.1 and ADF according to Clause
8.3.1.3). In this variant the APDU of the command SELECT contains three parameters:
(N441.00)
(N442.00)
(N443.00)
(N444.00)
Table 36: (N444.50) SELECT, no AID, next occurrence, no response data
Content Description
empty)
P2 0E fileOccurrence + responseType = next occurrence, no response data
14.2.6.4 Use Case Selection without AID, next occurrence, response data with FCP
The repeated execution of this variant selects all folders consecutively having the attribute
applicationIdentifier (applications according to Clause 8.3.1.1 and ADF according to Clause
8.3.1.3). In this variant the APDU of the command SELECT contains four parameters:
(N445.00)

(N446.00)
(N447.00)
(N448.00)
(N449.00)
Table 37: (N449.50) SELECT, no AID, next occurrence, response data with FCP
Content Description
empty)
P2 06 fileOccurrence + responseType = next occurrence, FCP response data
14.2.6.5 Use Case Selection per AID, first occurrence, no response data
In this variant the APDU of the command SELECT contains four parameters:
(N450.00)
(N451.00)
(N452.00)
The parameter aid contains an octet string according to (N104.00) or its first part. In the
object system it will be searched for a folder with matching attribute applicationIdenti-
fier.
(N453.00)
(N454.00)
(N270.50), according to Clause 11.7.3.1. For the construction of this case 3 command

Table 38: (N454.50) SELECT, AID, first occurrence, no response data
Content Description
P1 04 selectionMode = Selection of folder with applicationIdentifier
Data XXYY aid, octet string, number of octets in the interval [1, 16]
14.2.6.6 Use Case Selection per AID, first occurrence, response data with FCP
In this variant the APDU of the command SELECT contains five parameters:
(N455.00)
(N456.00)
(N457.00)
fier.
(N458.00)
(N459.00)
The parameter length determines the length of the response date being expected. The
(N460.00)
Table 39: (N460.50) SELECT, AID, first occurrence, response data with FCP
Content Description
FCP
Data XXYY aid, Octet string, number of octets in the interval [1, 16]
14.2.6.7 Use Case Selection per AID, next occurrence, no response data
(N461.00)
(N462.00)
(N463.00)
fier.
(N464.00)
(N465.00)
A case 3 command APDU MUST be sent via the interface Interpreter Figure 1
Table 40: (N465.50) SELECT, AID, next occurrence, no response data
Content Description
P2 0E fileOccurrence + responseType = next occurrence, no response data
14.2.6.8 Use Case Selection per AID, next occurrence, response data with FCP
(N466.00)
(N467.00)
(N468.00)
fier.
(N469.00)
(N470.00)
(N471.00)

Table 41: (N471.50) SELECT, AID, next occurrence, response data with FCP
Content Description
P2 06 fileOccurrence + responseType = next occurrence, response data with
FCP
14.2.6.9 Use Case Selection, DF or ADF, no response data
(N472.00)
(N473.00)
(N474.00)
The parameter fid contains an octet string according to (N67.00). In currentFolder it will
be searched for a folder with matching attribute fileIdentifier.
(N475.00)
(N476.00)
Table 42: (N476.50) SELECT, DF or ADF with FID, no response data
Content Description
P1 01 selectionMode = Selection of folder with fileIdentifier
Data XXYY fid
14.2.6.10 Use Case Selection, DF or ADF, response data with FCP
(N477.00)

(N478.00)
(N479.00)
(N480.00)
(N481.00)
(N482.00)
Table 43: (N482.50) SELECT, DF or ADF with FID, response data with FCP
Content Description
P1 01 selectionMode = Selection of folder with fileIdentifier
FCP
Data XXYY fid
14.2.6.11 Use Case Selection of a higher ranking directory without FCP
This variant selects the folder of a layer being one level higher (see (N211.00) and
(N212.00)). In this variant the APDU of the command SELECT contains five parameters:
(N483.00)
(N484.00)
(N485.00)

Table 44: (N485.50) SELECT, higher layer, no response data
Content Description
P1 03 selectionMode = selection of the folder in the layer one level higher
P2 0C responseType = no response data
14.2.6.12 Use Case Selection of a higher-ranking directory with FCP
This variant selects the folder of a layer being one level higher (see (N211.00) and
(N212.00)). In this variant the APDU of the command SELECT contains three parameters:
(N486.00)
(N487.00)
(N488.00)
(N489.00)
Table 45: (N489.50) SELECT, higher layer, response data with FCP
Content Description
P1 03 selectionMode = selection of the folder in the layer one level higher
P2 04 responseType = response data with FCP
14.2.6.13 Use Case Selection of a file, no response data
(N490.00)
(N491.00)
(N492.00)

(N493.00)
(N494.00)
Table 46: (N494.50) SELECT, EF with FID, no response data
Content Description
P1 02 selectionMode = Selection of file with fileIdentifier
Data XXYY fid
14.2.6.14 Use Case Selection of a file, response data with FCP
(N495.00)
(N496.00)
(N497.00)
(N498.00)
(N499.00)
(N500.00)

Table 47: (N500.30) SELECT, EF with FID, response data with FCP
Content Description
P1 02 selectionMode = Selection of file with fileIdentifier
P2 04 fileOccurrence + responseType = first occurrence, FCP response data
Data XXYY fid
14.2.6.15 Summary of the variants for the command SELECT
To get an overview all variants of this command are shown in the following table. It shall be
mentioned that not all combinations listed are described in the preceding clauses. Therefore
the combinations not being described are not mandatory.
Table 48: (N500.40) SELECT, command parameters, overview
Content Description
P1 01 Selection of a folder with fileIdentifier
02 Selection of a file with fileIdentifier
03 selection of the folder in the layer one level higher
04 selection of a folder with (possibly empty) applicationIdentifier
P2 04 first occurrence, response data with FCP
06 next occurrence, response data with FCP
0C first occurrence, no response data
0E next occurrence, no response data
Data XXYY P1 = 01: two bytes fid
P1 = 02: two bytes fid
P1 = 03: absent
P1 = 04: absent, or up to 16 Octets aid
Ne length P2 = 04: Expected number of octets in the response data
P2 = 06: Expected number of octets in the response data
P2 = 0C: absent
P2 = 0E: absent
14.2.6.16 Response of the smartcard to the selection of a file

Table 49: (N500.50) SELECT Response APDU in case of success
Data Content Description

XXYY FCP absent, or File Control Parameter
90 00 NoError Successful selection of a file
62 83 FileDeactivated Selected file is deactivated on a logical or a physical
base

Table 50: (N500.60) SELECT Response APDU in case of failure
Trailer Contente Description

6A 82 FileNotFound File to be selected not found
(N501.00)
The following definitions will be used to describe the command processing:
oldFolder This is the name of currentFolder before the execution of this SELECT
command.
newFile This is the name of the file (folder or file) which is chosen in the context of
this selection.
path(folder) Path of a folder with the name folder. By this definition the folder folder as
well as all higher ranking directories including root are part of this path.
(N502.00)
The COS MUST support the variants of SELECT from 14.2.6.1, 14.2.6.2, 14.2.6.5,
14.2.6.6, 14.2.6.9, 14.2.6.10, 14.2.6.11, 14.2.6.12, 14.2.6.13 and 14.2.6.14.
The COS MAY support additional varaiants of SELECT.
The COS MAY refuse additional varaiants of SELECT
(N503.00)
The access condition for all variants of SELECT MUST be ALWAYS.
(N504.00)
If the parameter P1 has the value 01, then it MUST be searched in oldFolder.children
for a folder with an attribute fileIdentifier, whose value matches with the parameter fid
being part of the command data. If such a folder exists, then newFile MUST be set to
this folder. If not, the search has been unsuccessful.
(N505.00)
If the parameter P1 has the value 02, then it MUST be searched in oldFolder.children
for a file with an attribute fileIdentifier, whose value matches with the parameter fid be-
ing part of the command data. If such a file exists, then newFile MUST be set to this
file. If not, the search has been unsuccessful
(N506.00)
If the parameter P1 has the value 03, and currentFolder
a. is identical with root, then the command MUST terminate with the trailer FileNot-
Found.
b. is not root, then newFile is a folder being one level higher in comparison with cur-
rentFolder (see (N211.00) and (N212.00)).
(N507.00)
If the parameter P1 has the value 04, then the command message contains a (possi-
bly empty) parameter aid.
a. in the whole object system it will be searched for folders having an attribute applica-
tionIdentifier matching with aid. An attribute applicationIdentifier matches with aid, if
i. applicationIdentifier is identical to aid, or
ii. aid is empty.
b. All matching folders are grouped in a list.
i. It root part of the list, then it MUST be the first element of the list.
ii. For an identical aid always the same list has to be generated as long as the
object system is not changed (DELETE or LOAD APPLICATION).
c. If P2 has a value of the set {04, 0C}, then newFile MUST be set to the first list
element.
d. If P2 has a value of the set {06, 0E} and
i. oldFolder is also part of the list and oldFolder is
1. not the last list element, then newFile MUST be set to the next list element.
2. the last list element, then the search MUST be unsuccessful.
ii. oldFolder is not part of the list, then
1. newFile MAY be set to any list element, or
2. the search MAY be unsuccessful.
(N508.00)
If and only if the search has been unsuccessful then the command MUST terminate
with the trailer FileNotFound. CurrentFolder, currentEF as well as the channel context
(see Clause 12) MUST NOT be changed in this case.
(N509.00)
If newFile is
a. a file, then currentEF will be set to newFile.
b. a folder, then
i. currentFolder MUST be set equal to newFile.
ii. currentEF MUST be set to the value undefined.
iii. in all folders being part of path(oldFolder) as well as part of path(newFile)
seIdentifier MUST remain unchanged.
iv. in all other folders seIdentifier MUST be set to the value 1.
v. all entries MUST be deleted from dfSpecificSecurityList using clearSecurityS-
tatus(), which do not belong to path(newFile).
vi. all entries MUST be deleted from dfSpecificPasswordList using clearPass-
wordStatus(), which do not belong to path(newFile).
vii. each element of keyReferenceList MUST be set to the value empty.
(N510.00)
For the data field of the response message it applies:
a. If and only if P2 has a value of the set {04, 06}, then the data field of the re-
sponse message MUST contain the File Control Parameter according to
Clause 8.3.3.
b. Otherwise the data field is absent in the response message.

(N511.00)
If and only if the logical value of newFile.lifeCycleStatus (see (N217.00)) has the value
Operational state (deactivated), then FileDeactivated MUST be used as trailer.
(N512.00)
Otherwise NoError MUST be used as Trailer.
(N513.00)
b. Each trailer in Table 50 (N500.60) MUST have a higher priority than FileDeacti-
vated.
c. FileDeactivated MUST have a higher priority than NoError.
Note: According to the rules of this document it is allowed to select sub-folders or files in a deactivated
folder with the command SELECT.
14.2.7 TERMINATE CARD USAGE
(N514.00)
14.2.8 TERMINATE DF
(N515.00)
14.2.9 TERMINATE EF
(N516.00)
14.3 Access to Data in a transparent EF
It is possible to access data in the body of a transparent EF with READ BINARY (reading) or
UPDATE BINARY (writing).
The commands in this sub-clause support two variants:
1. Variant without shortFileIdentifier: This variant is characterized by the fact that for a suc-
cessful command execution currentEF must be a transparent EF.
2. Variant with shortFileIdentifier: This variant is characterized by the fact, that the EF af-
fected by the command is set during command execution. A command SELECT is not
necessary prior to the command.
14.3.1 ERASE BINARY
The command ERASE BINARY replaces data existing in the body of a transparent EF with
octets with the value 00. The appropriate transparent EF is selected prior to the erase op-
eration. This is done either by a select operation (command SELECT) prior to the execution
of the command ERASE BINARY or as part of the command ERASE BINARY, if a short-
FileIdentifier is a parameter of this command. The offset being part of the command mes-
sage determines which information will be erased in body.
14.3.1.1 Use Case Erase without shortFileIdentifier in a transparent EF
In this variant the APDU of the command ERASE BINARY contains one parameter:
(N517.00)
The parameter offset determines the position where the erasure starts. The value of
offset MUST be an integer from the interval [0, 32767] = [`0000, 7FFF] (compare
(N118.00)).
(N518.00)
Table 51: (N518.50) ERASE BINARY without shortFileIdentifier
Content Description
INS 0E Instruction Byte according to [ISO7816-4]
P1 XX (offset P2) / 256, MSByte of offset
P2 XX offset mod 256, LSByte of offset
14.3.1.2 Use Case Erase with shortFileIdentifier in a transparent EF
In this variant the APDU of the command ERASE BINARY contains two parameters:
(N519.00)
The parameter shortFileIdentifier selects an EF during the command execution. The
value of shortFileIdentifier MUST be in the interval defined in (N70.00).
(N520.00)
The parameter offset determines the position where the erasure starts. The value of
offset MUST be an integer from the interval [0, 255] = [`0000, FF].
(N521.00)
Table 52: (N521.40) ERASE BINARY with shortFileIdentifier
Content Description
INS 0E Instruction Byte according to [ISO7816-4]
P1 XX 128 + shortFileIdentifier = 80 + shortFileIdentifier
P2 XX offset

14.3.1.3 Response of the smartcard to erasure in a transparent EF
Table 53: (N521.50) ERASE BINARY Response APDU in case of success

90 00 NoError Erasure successful
Table 54: (N521.60) ERASE BINARY Response APDU in case of failure

6A 82 FileNotFound EF adressed by shortFileIdentifier not found
69 86 NoCurrentEF no EF selected
69 81 WrongFileType selected EF is not transparent
6B 00 OffsetTooBig Parameter offset in command APDU too large
(N522.00)

(N523.00)
The COS MUST support the variants for ERASE BINARY from 14.3.1.1 and 14.3.1.2.
The COS MAY support additional variants for ERASE BINARY.

The COS MAY refuse additional variants for ERASE BINARY.
(N524.00)
If the APDU of the command ERASE BINARY contains
a. a shortFileIdentifier, then it will be searched for an EF with this shortFileIdentifier in
currentFolder.children. If the search
i. is successful, then the affectedObject MUST be set to this EF.
ii. is unsuccessful, then the command MUST be terminated with the trailer
FileNotFound.
b. no shortFileIdentifier
i. and currentEF (see (N322.00)b) is undefined, then the command MUST be
terminated with the trailer NoCurrentEF, otherwise
ii. affectedObject MUST be set equal to currentEF.
(N525.00)
If and only if AccessRuleEvaluation( affectedObject, CLA, INS, P1, P2 ) returns the
value False, then the command MUST be terminated with the trailer SecurityStatus-
NotSatisfied.
(N526.00)
If and only if affectedObject is not of the type transparent EF, then the command MUST
be terminated with the trailer WrongFileType.

(N527.00)
If and only if offset is greater than or equal to affectedObject.numberOfBytes, then the
command MUST be terminated with the trailer OffsetTooBig.
(N528.00)
If affectedObject.flagTransactionMode has the value
a. True, then affectedObject.body MUST be changed with transaction protection.
b. False, then the COS MUST decide whether affectedObject.body is changed with
or without transaction protection (see Clause 14.1).
(N529.00)
Starting at the position marked by offset all octets in affectedObject.body MUST be set
to the value 00.
(N530.00) If and only if the COS has realized that the writing operation has not been suc-
cessful with the first try the COS MAY choose UpdateRetryWarning as trailer.
(N531.00)
If and only if a writing operation has not been successful, then the trailer MemoryFail-
ure MUST be used.
(N532.00)
Otherwise the trailer NoError MUST be used.
(N533.00)
Warning.
(N534.00)
In the case of success currentEF MUST be set equal to affectedObject.
(N535.00)
In the case of an error
a. currentEF SHOULD be set equal to affectedObject,
b. otherwise currentEF MUST keep the value being present before the execution of the
command.
14.3.2 READ BINARY
The command READ BINARY is used to read information from body of a transparent EF.
Therefore the data field of the response message contains (parts of) body. The transparent
EF affected will be selected ahead the read operation. This is done either by a select opera-
tion (command SELECT) before the command READ BINARY is sent, or as part of the
command READ BINARY, if a shortFileIdentifier is sent as a parameter of the command. The
command parameters offset and length determine, which information is read from body.
14.3.2.1 Use Case Read without shortFileIdentifier in a transparent EF
In this variant the APDU of the command READ BINARY contains two parameters:
(N536.00)
The parameter offset determines the starting position for the read operation. The value

of offset MUST be an integer in the interval [0, 32767] = [`0000, 7FFF], (compare
(N118.00)).
(N537.00)
The parameter length determines the length of the expected response data. The value
of length MUST be chosen from the range defined in Clause 11.5.6.
(N538.00)
Table 55: (N538.50) READ BINARY without shortFileIdentifier
Content Description
INS B0 Instruction Byte according to [ISO7816-4]
14.3.2.2 Use Case Read with shortFileIdentifier in a transparent EF
In this variant the APDU of the command READ BINARY contains three parameters:
(N539.00)
(N540.00)
The parameter offset determines the starting position for the read operation. The value
of offset MUST be an integer in the interval [0, 255] = [`00, FF].
(N541.00)
(N542.00)
Table 56: (N542.40) READ BINARY with shortFileIdentifier
Content Description
P2 XX offset

14.3.2.3 Response of the smartcard to the command read in a transparent EF
Table 57: (N542.50) READ BINARY Response APDU in case of success
Daten Content Description

XXYY Data being read
90 00 NoError Read operation successful
62 82 EndOfFileWarning Less data than requested with Ne
62 81 CorruptDataWarning Possibly the response data are corrupt
Table 58: (N542.60) READ BINARY Response APDU in case of failure

69 86 NoCurrentEF No EF selected
69 81 WrongFileType selected EF not transparent
6B 00 OffsetTooBig Parameter offset in command APDU too large
(N543.00)

(N544.00)
The COS MUST support the variants of the command READ BINARY from 14.3.2.1
and 14.3.2.2.
The COS MAY support additional variants of READ BINARY.
The COS MAY refuse additional variants of READ BINARY.
(N545.00)
If the APDU of the command READ BINARY contains
a. a shortFileIdentifier, then in currentFolder.children it will be searched for an EF with
this shortFileIdentifier. If and only if the search
i. was successful, then affectedObject MUST be set to this EF
ii. was not successful, then the command MUST terminate with the trailer
FileNotFound.
i. and currentEF (see (N322.00)b) is undefined, then the command MUST ter-
minate with the trailer NoCurrentEF, otherwise
(N546.00)
then the command MUST be terminate with the trailer SecurityStatusNotSatisfied
(N547.00)

(N548.00)
(N549.00)
If and only if affectedObject.flagChecksum has the value True and the data of affect-
edObject.body are inconsistent to the checksum, then the trailer CorruptDataWarning
MUST to be chosen.
(N550.00)
If and only if the Le field of the command APDU contains no WildCard and (offset +
length) is greater than affectedObject.numberOfBytes, then the trailer EndOfFileWarn-
ing MUST be chosen.
(N551.00)
Otherwise NoError MUST be chosen as trailer.
(N552.00)
a. Starting from the position defined by offset the next octet strings MUST be taken
from the octet string affectedObject.body.
b. NOT more octets MUST be taken than defined by Ne.
c. The takeover of the octets MUST be stopped at the end of affectedObject.body.
(N553.00)
b. Each trailer in Table 58 (N542.60) MUST have a higher priority than Cor-
ruptDataWarning.
c. CorruptDataWarning MUST have a higher priority than EndOfFileWarning.
d. EndOfFileWarning MUST have a higher priority than NoError.
(N554.00)
In case of success currentEF MUST be set equal to affectedObject.
(N555.00)
b. otherwise currentEF MUST remain unchanged with the value being present before
the execution of the command.
14.3.3 SEARCH BINARY
(N556.00)
14.3.4 UPDATE BINARY
The command UPDATE BINARY replaces data being present in body of a transparent EF by
data, which are present in the data field of the command message. The transparent EF af-
fected will be selected ahedad of the write operation. This is done either by a select opera-
tion (command SELECT) before the command UPDATE BINARY is sent, or as part of the
command UPDATE BINARY, if a shortFileIdentifier is sent as a parameter of the command.
The command parameters offset and newData determine which information is changed from
body.
14.3.4.1 Use Case Update without shortFileIdentifier in a transparent EF
In this variant the APDU of the command UPDATE BINARY contains two parameters:
(N557.00)
The parameter offset determines the starting position for the update operation. The
value of offset MUST be an integer in the interval [0, 32767] = [`0000, 7FFF], (com-
pare (N118.00)).
(N558.00)
The parameter newData contains the new data which replace the data being present in
body starting at the position marked by offset. The parameter newData is an octet
string with any content. The length of newData is only limited by the restrictions of
Clause 11.5.5.
(N559.00)
Table 59: (N559.50) UPDATE BINARY without shortFileIdentifier
Content Description
INS D6 Instruction Byte according to [ISO7816-4]
Data XXYY newData
14.3.4.2 Use Case Update with shortFileIdentifier in a transparent EF
In this variant the APDU of the command UPDATE BINARY contains three parameters:
(N560.00)
(N561.00)
The parameter offset determines the starting position for the update operation. The
value of offset MUST be an integer in the interval [0, 255] = [`00, FF].
(N562.00)
The parameter newData contains the new data which replace the data being present in
body starting at the position marked by offset. The parameter newData is an octet
string with any content. The length of newData is only limited by the restrictions of
Clause 11.5.5.
(N563.00)

Table 60: (N563.40) UPDATE BINARY with shortFileIdentifier
Content Description
INS D6 Instruction Byte according to [ISO7816-4]
P2 XX offset
Data XXYY newData
14.3.4.3 Response of the smartcard to the command Update Binary in a transparent EF

Table 61: (N563.50) UPDATE BINARY Response APDU in case of success

90 00 NoError Write operation successful
Table 62: (N563.60) UPDATE BINARY Response APDU in case of failure

69 81 WrongFileType selected EF not transparent
6B 00 OffsetTooBig Parameter offset in command APDU too big
6A 84 DataTooBig parameter newData is larger than the file size
(N564.00)

(N565.00)
The COS MUST support the variants of the command UPDATE BINARY from 14.3.2.1
and 14.3.2.2.
The COS MAY support additional variants of UPDATE BINARY.
The COS MAY refuse additional variants of UPDATE BINARY
(N566.00)
If the APDU of the command UPDATE BINARY contains
this shortFileIdentifier. If and only if the search was
i. successful, then affectedObject MUST be set to this EF.
ii. not successful, then the command MUST terminate with the trailer FileNot-
Found.
(N567.00)
then the command MUST be terminate with the trailer SecurityStatusNotSatisfied.
(N568.00)
(N569.00)
(N570.00)
If and only if (offset + OctetLength(newData)) is greater than affectedObject.number-
OfBytes, then the command MUST terminate with the trailer DataTooBig.
(N571.00)
a. True, then affectedObject.body MUST be changed with transaction protection.
b. False, then the COS MUST decide whether affectedObject.body is changed with
or without transaction protection (see Clause 14.1).
(N572.00)
Starting at the position marked by offset the data of affectedObject.body MUST be re-
placed by newData.
(N573.00)
(N574.00)
used as trailer.
(N575.00)
(N576.00)
Warning.
(N577.00)
(N578.00)

14.3.5 WRITE BINARY
(N579.00)
14.4 Access to structured Data
It is possible to access list elements of recordList in structured EFs with a read command
(READ RECORD) or write command (UPDATE RECORD). Additionally new list elements
can be created (APPEND RECORD). List elements cannot be deleted. But it is possible to
erase the content of a list element (ERASE RECORD). List elements can be activated (AC-
TIVATE RECORD) as well as deactivated (DEACTIVATE RECORD), which influences the
use of the content of the record. It is also possible to search in the list for elements whose
content matches with an arbitrary search pattern (SEARCH RECORD).
The commands in this sub-clause support two variants:
1. Variant without shortFileIdentifier: This variant is characterized by the fact that for a suc-
cessful command execution currentEF must be a structured EF.
2. Variant with shortFileIdentifier: This variant is characterized by the fact, that the EF af-
fected is set during command execution. A command SELECT is not necessary prior to
the command.
14.4.1 ACTIVATE RECORD
The command ACTIVATE RECORD activates one ore more list elements from recordList of
a structured EF. The structured EF affected is selected prior to this operation. This is done
either by a select operation (command SELECT) before the command ACTIVATE RECORD
is sent, or as part of the command ACTIVATE RECORD if a shortFileIdentifier is sent as a
parameter of the command. The parameters record number and mode of the command
message determine the list elements to be activated.
14.4.1.1 Use Case Activation of a record without shortFileIdentifier
In this variant the APDU of the command ACTIVATE RECORD contains two parameters:
(N580.00)
The parameter recordNumber determines the list element being affected.The value of
recordNumber MUST be compliant with (N76.00).
(N581.00)
The parameter mode determines the kind of the operation. For this use case mode =
04 MUST be set.
(N582.00)

Table 63: (N582.50) ACTIVATE RECORD, one record, without shortFileIdentifier
Content Description
P1 XX recordNumber
P2 04 mode, coding 04 means use list element P1
14.4.1.2 Use Case activation of a record with shortFileIdentifier
In this variant the APDU of the command ACTIVATE RECORD contains three parameters:
(N583.00)
(N584.00)
recordNumber MUST be confom to (N76.00).
(N585.00)
04 MUST be set.
(N586.00)
Table 64: (N586.50) ACTIVATE RECORD, one record, with shortFileIdentifier
Content Description
P1 XX recordNumber
P2 XX 8 * shortFileIdentifier + mode
i.e. (bit left-shift operation shortFileIdentifier << 3) + 04
coding 04 means use list element P1
14.4.1.3 Use Case Activation of all records from P1 without shortFileIdentifier
In this variant the APDU of the command ACTIVATE RECORD contains two parameters:
(N587.00)
The parameter recordNumber determines the first list element being affected.The value
of recordNumber MUST be confom to (N76.00).
(N588.00)
05 MUST be set.
(N589.00)

Table 65: (N589.50) ACTIVATE RECORD, all records from P1, without shortFileIdentifier
Content Description
P1 XX recordNumber
P2 05 mode, coding 05 means use list elements from P1
14.4.1.4 Use Case Activation of all records from P1 with shortFileIdentifier
In this variant the APDU of the command ACTIVATE RECORD contains three parameters:
(N590.00)
(N591.00)
(N592.00)
05 MUST be set.
(N593.00)
Table 66: (N593.40) ACTIVATE RECORD, all records from P1, with shortFileIdentifier
Content Description
P1 XX recordNumber
coding 05 means use list elements from P1
14.4.1.5 Response of the smartcard otherwise activation of a record

Table 67: (N593.50) ACTIVATE RECORD Response APDU in case of success

90 00 NoError activation successful

Table 68: (N593.60) ACTIVATE RECORD Response APDU in case of failure

69 81 WrongFileType selected EF is not structured
69 85 NoRecordLifeCycleStatus Records in selected EF have no LCS
6A 83 RecordNotFound List element recordNumber does not exist
(N594.00)

(N595.00)
The COS MUST support the variants of the command ACTIVATE RECORD from
14.4.1.1, 14.4.1.2 14.4.1.3 and 14.4.1.4.
The COS MAY support additional variants of ACTIVATE RECORD.
The COS MAY refuse additional variants of ACTIVATE RECORD.
(N596.00)
If the APDU of the command ACTIVATE RECORD contains
FileNotFound.
minate with the trailer NoCurrentEF.
ii. Then affectedObject MUST be set equal to currentEF.
(N597.00)
(N598.00)
If and only if affectedObject is not of the type structured EF, then the command MUST
(N599.00)
If and only if affectedObject.flagRecordLifeCycleStatus has the value False the com-
mand MUST terminate with the trailer NoRecordLifeCycleStatus.
(N600.00)
If and only if recordNumber is greater than the number of list elements in affectedOb-
ject.recordList, then the command MUST be terminated with the trailer RecordNot-
Found.
(N601.00)

a. True, then and only then lifeCycleStatus MUST be changed with transaction pro-
tection.
b. False, then the COS MUST decide whether lifeCycleStatus is changed with or
without transaction protection (see Clause 14.1).
(N602.00)
If mode = 04 and the physical value of lifeCycleStatus of the record in affectedOb-
ject.recordList addressed by recordNumber has already the value Operational state
(activated), then the trailer NoError MUST be used.
(N603.00)
The physical value of lifeCycleStatus of the record in affectedObject.recordList ad-
dressed by recordNumber MUST be set to the value Operational state (activated). It
applies: If mode has the value
a. 04, then only the list element addressed by recordNumber is affected.
b. 05, then the list element addressed by recordNumber and all following list ele-
ments are affected.
(N604.00)
successful with the first try, then the COS MAY choose UpdateRetryWarning as trailer.
(N605.00)
If and only if a writing operation has not been successful, then MemoryFailure MUST
be used as trailer.
(N605.40)
(N605.60)
Warning.
(N606.00)
(N607.00)
command
14.4.2 APPEND RECORD
The command APPEND RECORD adds a new list element to recordList of a structured EF
an, whereas the data for the octet string of the new list element are part of the data field of
the command message. The structured EF affected is selected prior to this operation. This is
done either by a select operation (command SELECT) before the command APPEND RE-
CORD is sent, or as part of the command APPEND RECORD if a shortFileIdentifier is sent
as a parameter of the command.

14.4.2.1 Use Case Append a new record without shortFileIdentifier
In this variant the APDU of the command APPEND RECORD contains one parameter:
(N608.00)
The parameter recordData contains the data of the new record. The parameter record-
Data is an octet string of any content. The length of recordData is only limited by the
restrictions of (N70.00).
(N609.00)
Table 69: (N609.50) APPEND RECORD without shortFileIdentifier
Content Description
P1 00 Parameter with no meaning
Data XXYY recordData
14.4.2.2 Use Case Append a new record with shortFileIdentifier
In this variant the APDU of the command APPEND RECORD contains two parameters:
(N610.00)
(N611.00)
The parameter recordData contains the data of the new record. The parameter record-
Data is an octet string of any content. The length of recordData is only limited by the
restrictions of (N77.00).
(N612.00)
Table 70: (N612.40) APPEND RECORD with shortFileIdentifier
Content Description
P2 XX 8 * shortFileIdentifier
i.e. bit left-shift operation shortFileIdentifier << 3
Data XXYY recordData

14.4.2.3 Response of the smartcard to append a new record
Table 71: (N612.50) APPEND RECORD Response APDU in case of success

90 00 NoError Appending successful
Table 72: (N612.60) APPEND RECORD Response APDU in case of failure

6A 82 FileNotFound EF addressed by shortFileIdentifier not found
67 00 WrongRecordLength recordData has the wrong length
6A 84 OutOfMemory Too many octets in recordData
6A 84 FullRecordList Record list does not allow additional elements
(N613.00)

(N614.00)
The COS MUST support the variants of the command APPEND RECORD from
14.4.2.1 and 14.4.2.2.
The COS MAY support additional variants of APPEND RECORD.
The COS MAY refuse additional variants of APPEND RECORD
(N615.00)
If the APDU of the command APPEND RECORD contains
this shortFileIdentifier. If and only if the search was
i. successful, then affectedObject MUST be set to this EF
ii. not successful, then the command MUST terminate with the trailer FileNot-
Found.
(N616.00)
(N617.00)

(N618.00)
If and only if affectedObject is of the type
a. linear fix EF and the number of octets in recordData is not equal to affectedOb-
ject.maximumRecordLength, then the command MUST terminate with the trailer
WrongRecordLength.
b. cyclic EF and the number of octets in recordData is not equal to affectedOb-
WrongRecordLength.
c. linear variable EF and
i. the number of octets in recordData is greater than affectedObject.maximum-
RecordLength, then the command MUST terminate with the trailer WrongRe-
cordLength.
ii. the number of octets in the octet strings of all record of recordList would be
greater as affectedObject.numberOfBytes after the extension of the list, then
the command MUST terminate with the trailer OutOfMemory.
(N619.00)
If and only if the number of list elements in affectedObject.recordList is equal to affect-
edObject.maximumNumberOfRecords and affectedObject is of the type linear fix EF or
linear variable EF, then the command MUST terminate with the trailer FullRecordList.
(N620.00)
a. True, then affectedObject.recordList MUST be changed with transaction protec-
tion.
b. False, then the COS MUST decide whether affectedObject.recordList is changed
with or without transaction protection (see Clause 14.1).
(N621.00)
If and only if affectedObject is of the type
a. linear fix EF or linear variable EF, then a new record will be added at the end of af-
fectedObject.recordList.
b. cyclic EF, then a new record will be added at the beginning of affectedOb-
ject.recordList. If through this operation the number of list elements will be greater
than affectedObject.maximumNumberOfRecord, then and only then the last element
in affectedObject.recordList MUST be deleted.
(N622.00)
As octet string of the new record recordData will be used.
(N623.00)
If affectedObject.flagRecordLifeCycleStatus has the value True, then the physical
value of lifeCycleStatus of the new record is set to Operational state (activated).
(N624.00)
(N625.00)
ure MUST be used.
(N626.00)

(N627.00)
Warning.
(N628.00)
(N629.00)
command.
14.4.3 DEACTIVATE RECORD
The command DEACTIVATE RECORD deactivates one ore more list elements from record-
List of a structured EF. The structured EF affected is selected prior to this operation. This is
done either by a select operation (command SELECT) before the command DEACTIVATE
RECORD is sent, or as part of the command DEACTIVATE RECORD if a shortFileIdentifier
is sent as a parameter of the command. The parameters record number and mode of the
command message determine the list elements to be deactivated.
14.4.3.1 Use Case Deactivation of a record without shortFileIdentifier
In this variant the APDU of the command DEACTIVATE RECORD contains two parameters:
(N630.00)
(N631.00)
04 MUST be set.
(N632.00)
Table 73: (N632.50) DEACTIVATE RECORD, one record, without shortFileIdentifier
Content Description
P1 XX recordNumber
P2 04 mode, coding 04 means use list element P1

14.4.3.2 Use Case Deactivation of a record with shortFileIdentifier
In this variant the APDU of the command DEACTIVATE RECORD contains three parame-
ters:
(N633.00)
(N634.00)
(N635.00)
04 MUST be set.
(N636.00)
Table 74: (N636.50) DEACTIVATE RECORD, one record, with shortFileIdentifier
Content Description
P1 XX recordNumber
14.4.3.3 Use Case Deactivation of all records from P1 without shortFileIdentifier
In this variant the APDU of the command DEACTIVATE RECORD contains two parameters:
(N637.00)
The parameter recordNumber determines the first list element being affected. The
value of recordNumber MUST be confom to (N76.00).
(N638.00)
05 MUST be set.
(N639.00)

Table 75: (N639.50) DEACTIVATE RECORD, all records from P1, without shortFileIdentifier
Content Description
P1 XX recordNumber
P2 05 mode, coding 05 means use list elements from P1
14.4.3.4 Use Case Deactivation of all records from P1 with shortFileIdentifier
In this variant the APDU of the command DEACTIVATE RECORD contains three parame-
ters:
(N640.00)
(N641.00)
(N642.00)
05 MUST be set.
(N643.00)
Table 76: (N643.40) DEACTIVATE RECORD, all records from P1, with shortFileIdentifier
Content Description
P1 XX recordNumber
14.4.3.5 Response of the smartcard to the deactivation of a record

Table 77: (N643.50) DEACTIVATE RECORD Response APDU in case of success

90 00 NoError Deactivation successful

Table 78: (N643.60) DEACTIVATE RECORD Response APDU in case of failure

69 85 NoRecordLifeCycleStatus Records in selected EF have no LCS
(N644.00)

(N645.00)
The COS MUST support the variants of the command DEACTIVATE RECORD from
14.4.3.1, 14.4.3.2, 14.4.3.3 and 14.4.3.4.
The COS MAY support additional variants of DEACTIVATE RECORD.
The COS MAY refuse additional variants of DEACTIVATE RECORD.
(N646.00)
If the APDU of the command DEACTIVATE RECORD contains
FileNotFound.
(N647.00)
(N648.00)
(N649.00)
If and only if affectedObject.flagRecordLifeCycleStatus has the value False, then the
command MUST terminate with the trailer NoRecordLifeCycleStatus.
(N650.00)
Found.
(N651.00)
a. True, then lifeCycleStatus MUST be changed with transaction protection.
b. False, then the COS MUST decide whether lifeCycleStatus is changed with or
without transaction protection (see Clause 14.1).
(N652.00)
If mode = 04 and the physical value of lifeCycleStatus of the record in affectedOb-
ject.recordList addressed by recordNumber has already the value Operational state
(deactivated), then the trailer NoError MUST be used.
(N653.00)
The physical value of lifeCycleStatus of the record in affectedObject.recordList ad-
dressed by recordNumber MUST be set to the value Operational state (deactivated).
It applies: If mode has the value
a. 04, then only the list element addressed by recordNumber is affected.
b. 05, then the list element addressed by recordNumber and all following list ele-
ments are affected.
(N654.00)
(N655.00)
used as trailer.
(N656.00)
(N657.00)
Warning.
(N658.00)
(N659.00)
a. currentEF SHOULD be set equal to affectedObject.
command.
14.4.4 ERASE RECORD
The command ERASE RECORD replaces the octet string of an already existing list element
of recordList of a structured EF by an octet string having only octets with the value 00. The
structured EF affected is selected prior to this operation. This is done either by a select op-
eration (command SELECT) before the command ERASE RECORD is sent, or as part of the
command ERASE RECORD if a shortFileIdentifier is sent as a parameter of the command.
Which list element is affected is defined by the record number being a parameter of the
command message.

14.4.4.1 Use Case Erase of the content of a record, without shortFileIdentifier
In this variant the APDU of the command ERASE RECORD contains one parameter:
(N660.00)
(N661.00)
Table 79: (N661.50) ERASE RECORD without shortFileIdentifier
Content Description
INS 0C Instruction Byte according to [ISO7816-4]
P1 XX recordNumber
P2 04 coding 04 means use list element P1
14.4.4.2 Use Case Erase of the content of a record, with shortFileIdentifier
In this variant the APDU of the command ERASE RECORD contains two parameters:
(N662.00)
(N663.00)
(N664.00)
Table 80: (N664.40) ERASE RECORD with shortFileIdentifier
Content Description
P1 XX recordNumber
P2 XX 8 * shortFileIdentifier + 4

14.4.4.3 Response of the smartcard to the erasure of the content of a record
Table 81: (N664.50) ERASE RECORD Response APDU in case of success

90 00 NoError Erasure of the content of a record successful
Table 82: (N664.60) ERASE RECORD Response APDU in case of failure

62 87 RecordDeactivated Adressed record is deactivated
SecMes from Figure 1(N270.50).
(N665.00)

(N666.00)
The COS MUST support the variants of the command ERASE RECORD from 14.4.4.1
and 14.4.4.2.
The COS MAY support additional variants of ERASE RECORD.
The COS MAY refuse additional variants of ERASE RECORD.
(N667.00)
If the APDU of the command ERASE RECORD contains
FileNotFound.
(N668.00)
(N669.00)
(N670.00)
Found.
(N671.00)
If and only if the physical value of lifeCycleStatus of the addressed record has the state
Operational state (deactivated), then the command MUST terminate with the trailer
RecordDeactivated.
(N672.00)
a. True, then and only then the content of the record MUST be changed with transac-
tion protection.
b. False, then the COS MUST decide whether the content of the record is changed
(N673.00)
All octets in the octet string of the record addressed by recordNumber in affectedOb-
ject.recordList are set to the value 00.
(N674.00)
(N675.00)
used as trailer.
(N676.00)
(N677.00)
Warning.
(N678.00)
(N679.00)
14.4.5 READ RECORD
The command READ RECORD is used to read (the beginning) of a list element from record-
List of a structured EF. The structured EF affected is selected prior to this operation. This is
done either by a select operation (command SELECT) before the command READ RECORD
is sent, or as part of the command READ RECORD if a shortFileIdentifier is sent as a pa-
rameter of the command. The parameters record number and length of the command mes-
sage determine which list element (or the beginning of it) will be read.

14.4.5.1 Use Case Read without shortFileIdentifier in a structured EF
In this variant the APDU of the command READ RECORD contains two parameters:
(N680.00)
(N681.00)
(N682.00)
Table 83: (N682.50) READ RECORD without shortFileIdentifier
Content Description
P1 XX recordNumber
P2 04 coding for use list element P1
14.4.5.2 Use Case Read with shortFileIdentifier in a structured EF
In this variant the APDU of the command READ RECORD contains three parameters:
(N683.00)
(N684.00)
(N685.00)
(N686.00)
(N270.50), according to Clause. 11.7.2.1 For the construction of this case 2 command

Table 84: (N686.40) READ RECORD with shortFileIdentifier
Content Description
P1 XX recordNumber
14.4.5.3 Response of the smartcard to read in a structured EF

Table 85: (N686.50) READ RECORD Response APDU in case of success

XXYY Data being read
90 00 NoError Read operation successful
62 82 EndOfRecordWarning more data requested with Ne than present
Table 86: (N686.60) READ RECORD Response APDU in case of failure

69 81 WrongFileType selected EF not structured
(N687.00)

(N688.00)
The COS MUST support the variants of the command READ RECORD from 14.4.5.1
and 14.4.5.2.
The COS MAY support additional variants of READ RECORD.
The COS MAY refuse additional variants of READ RECORD.
(N689.00)
If the APDU of the command READ RECORD contains

FileNotFound.
(N690.00)
(N691.00)
(N692.00)
Found.
(N693.00)
RecordDeactivated.
(N694.00)
If and only if affectedObject.flagChecksum has the value True and the data of the ad-
dressed list element are inconsistent to the checksum, then the trailer CorruptData-
Warning MUST to be chosen.
(N695.00)
If the Le field of the command APDU does not contain a WildCard and length is greater
than the length of the addressed list element affectedObject.numberOfBytes, then the
trailer EndOfRecordWarning MUST be chosen.
(N696.00)
(N697.00)
a. Starting at the first octet all subsequent octets MUST be taken from the octet string
of the addressed record.
b. More octets than indicated by Ne MUST NOT be taken.
c. The transfer MUST stop at the end of record.
(N698.00)
ruptDataWarning.
c. CorruptDataWarning MUST have a higher priority than EndOfRecordWarning.
d. EndOfRecordWarning MUST have a higher priority than NoError.
(N699.00)

(N700.00)
a. currentEF SHOULD be set equal to affectedObject.
command.
14.4.6 SEARCH RECORD
The command SEARCH RECORD is used to search in the list elements of recordList of a
structured EF for a pattern which is part of the data field of the command message. The re-
sponse data include the numbers of the records containing the pattern. The structured EF
affected is selected prior to this operation. This is done either by a select operation (com-
mand SELECT) before the command SEARCH RECORD is sent, or as part of the command
SEARCH RECORD if a shortFileIdentifier is sent as a parameter of the command. The pa-
rameter record number of the command message determines at which list element of re-
cordList the search starts.
14.4.6.1 Use Case Search without shortFileIdentifier in a structured EF
In this variant the APDU of the command SEARCH RECORD contains three parameters:
(N701.00)
The parameter recordNumber determines the list element which is the first one being
affected by the search.The value of recordNumber MUST be compliant with (N76.00).
(N702.00)
The parameter searchString contains the pattern, for which it is searched in the octet
strings of the list elements. The parameter searchString is an octet string with any con-
tent. The length of searchString is only limited by the restrictions of (N77.00).
(N703.00)
(N704.00)
Table 87: (N704.50) SEARCH RECORD without shortFileIdentifier
Content Description
P1 XX recordNumber
P2 04 Coding for search in list element P1 and all following list elements
Data XXYY searchString
14.4.6.2 Use Case Search with shortFileIdentifier in a structured EF
In this variant the APDU of the command SEARCH RECORD contains four parameters:

(N705.00)
(N706.00)
The parameter recordNumber determines the list element which is the first one being
affected by the search.The value of recordNumber MUST be compliant with (N76.00).
(N707.00)
The parameter searchString contains the pattern, for which it is searched in the octet
strings of the list elements. The parameter searchString is an octet string with any con-
tent. The length of searchString is only limited by the restrictions of (N77.00).
(N708.00)
(N709.00)
Table 88: (N709.40) SEARCH RECORD with shortFileIdentifier
Content Description
P1 XX recordNumber
Coding 04 means search in list element P1 and all following list ele-
ments
Data XXYY searchString
14.4.6.3 Response of the smartcard to the search in a structured EF

Table 89: (N709.50) SEARCH RECORD Response APDU in case of success

Daten XXYY Numbers of list elements containing the data pattern
90 00 NoError Search operation successful
62 82 UnsuccessfulSearch Unsuccessful search in adressed records

Table 90: (N709.60) SEARCH RECORD Response APDU in case of failure

69 81 WrongFileType selected EF not structured
(N710.00)

(N711.00)
The COS MUST support the variants of the command SEARCH RECORD from
14.4.6.1 and 14.4.6.2.
The COS MAY support additional variants of SEARCH RECORD.
The COS MAY refuse additional variants of SEARCH RECORD.
(N712.00)
If the APDU of the command SEARCH RECORD contains
ii. was not successful, then the command MUST terminate with the trailer File-
NotFound.
(N713.00)
(N714.00)
(N715.00)
If and only if recordNumber is greater than the number of list elements in affected-
Object.recordList, then the command MUST be terminated with the trailer RecordNot-
Found.
(N716.00)
It MUST be searched for the pattern searchString in the octet string of the record which
is addressed by recordNumber in affectedObject.recordList and in all subsequent ele-
ments.
(N717.00)
The search in a list element MUST be successful if and only if

a. the physical value of lifeCycleStatus of the list element has the status Operational
state (activated) AND
b. searchString is completely part of the octet string of the list element.
(N718.00)
If the search in a list element was successful, then the number of the record (see
(N76.00)) coded in an octet (according to I2OS(recordNumber, 1)) MUST be added to
the data field of the response message.
(N719.00)
The octets in the data field MUST be sorted in ascending order.
(N720.00)
If and only if affectedObject.flagChecksum has the value True and the data of at least
one addressed list element are inconsistent to the checksum, then the trailer Cor-
ruptDataWarning MUST to be chosen.
(N721.00)
If and only if the data field is empty - that means that the search was unsuccessful in all
addressed list elements -, then UnsuccessfulSearch MUST be used as trailer.
(N722.00)
(N723.00)
ruptDataWarning.
c. CorruptDataWarning MUST have a higher priority than UnsuccessfulSearch.
d. UnsuccessfulSearch MUST have a higher priority than NoError.
(N724.00)
(N725.00)
command
14.4.7 UPDATE RECORD
The command UPDATE RECORD is used to replace the octet string of an already existing
list element of recordList of a structured EF with data which are part of the data field of the
command message. The structured EF affected is selected prior to this operation. This is
done either by a select operation (command SELECT) before the command UPDATE RE-
CORD is sent, or as part of the command UPDATE RECORD if a shortFileIdentifier is sent
as a parameter of the command. The parameter record number of the command message
determines which list element of recordList will be replaced.
14.4.7.1 Use Case Update without shortFileIdentifier in a structured EF
In this variant the APDU of the command UPDATE RECORD contains two parameters:
(N726.00)
(N727.00)
The parameter newData contains the new data which replace the octet string of the
addressed record. The parameter newData is an octet string with any content. The
length of newData is only limited by the restrictions of (N77.00).
(N728.00)
Table 91: (N728.50) UPDATE RECORD without shortFileIdentifier
Content Description
INS DC Instruction Byte according to [ISO7816-4]
P1 XX recordNumber
P2 04 coding 04 means use list element P1
Data XXYY newData
14.4.7.2 Use Case Update with shortFileIdentifier in a structured EF
In this variant the APDU of the command UPDATE RECORD contains three parameters:
(N729.00)
(N730.00)
(N731.00)
The parameter newData contains the new data which replace the octet string of the
addressed record. The parameter newData is an octet string with any content. The
length of newData is only limited by the restrictions of (N77.00).
(N732.00)

Table 92: (N732.40) UPDATE RECORD with shortFileIdentifier
Content Description
INS DC Instruction Byte according to [ISO7816-4]
P1 XX recordNumber
Data XXYY newData
14.4.7.3 Response of the smartcard to the update in a structured EF

Table 93: (N732.50) UPDATE RECORD Response APDU in case of success

90 00 NoError Update successful
Table 94: (N732.60) UPDATE RECORD Response APDU in case of failure

67 00 WrongRecordLength newData has the wrong length
6A 84 OutOfMemory Too many octets in newData
(N733.00)

(N734.00)
The COS MUST support the variants of the command UPDATE RECORD from
14.4.7.1 and 14.4.7.2
The COS MAY support additional variants of UPDATE RECORD.
The COS MAY refuse additional variants of UPDATE RECORD.
(N735.00)
If the APDU of the command UPDATE RECORD contains

FileNotFound.
(N736.00)
(N737.00)
(N738.00)
Found.
(N739.00)
RecordDeactivated.
(N740.00)
a. linear fix EF and the number of octets in newData is not equal to affectedOb-
WrongRecordLength.
b. cyclic EF and the number of octets in newData is not equal to affectedOb-
WrongRecordLength.
c. linear variable EF and
i. the number of octets in newData is greater than affectedObject.maximumRe-
cordLength, the command MUST terminate with the trailer WrongRecord-
Length.
ii. after the replacement the number of octets in the octet strings of all elements
record of affectedObject.recordList would be greater than affectedOb-
ject.numberOfBytes, then and only then the command MUST terminate with
the trailer OutOfMemory.
(N741.00)
a. True, then the content of the record MUST be changed with transaction protection.
b. False, then the COS MUST decide whether the content of the record is changed
(N742.00)
The octet string of the record addressed by recordNumber in affectedObject.recordList
will be replaced by newData.
(N743.00)
If affectedObject is of the type linear variable EF, then all the following cases MUST be
supported: Compared to record being addressed by recordNumber newData contains
a. less octets,
b. the same number of octets, or
c. more octets.
(N744.00)
(N745.00)
ure MUST be used.
(N746.00)
(N747.00)
Warning.
(N748.00)
(N749.00)
command
14.4.8 WRITE RECORD
(N750.00)
14.5 Access to data objects
Note: According to Clause 8.6 the commands of this clause are not mandatory.
14.5.1 GET DATA
(N751.00)
The COS MAY refuse this command according to [ISO7816-4]

14.5.2 PUT DATA
(N752.00)
The COS MAY refuse this command according to [ISO7816-4]
14.6 User Verification
All commands of this clause use password objects according to Clause 8.4 during the proc-
essing of the commands. The affected password object will be defined by a password refer-
ence which is a parameter of the command data. For this password reference it applies:
(N753.00)
The parameter passwordReference has two parts: location and identifier. location indi-
cates whether a global or a DF-specific password is affected by the operation. The
value of location MUST be an element of the set {0, 128} = {00, 80}. It applies:
a. The value location = 00 MUST be used if a global password is affected (see
(N219.00)).
b. The value location = 80 MUST be used if a DF-specific password is affected (see
(N220.00)).
c. The parameter identifier defines the affected password object. The value of identifier
MUST be chosen according to (N153.00).
d. The parameter passwordReference MUST be coded in one octet with the following
value: passwordReference = location + identifier.
14.6.1 CHANGE REFERENCE DATA
The command CHANGE REFERENCE DATA replaces the attribute secret of a password
object by data being part of the command message. The affected password object will be
defined by a password reference which is a parameter of the command message. This
document specifies the following variants:
The command data field contains the old and the new user secret.
The command data field contains only the new user secret.
The command CHANGE REFERENCE DATA does not set a security status (see (N771.00)).
14.6.1.1 Use Case Change of a user secret
In this variant the APDU of the command CHANGE REFERENCE DATA contains three pa-
rameters:
(N754.00)
The parameter passwordReference references the password affected by the operation
and MUST be chosen according to (N753.00).
(N755.00)
The parameter oldSecret contains the old user secret.
(N756.00)
The parameter newSecret contains the new user secret.
(N757.00)
The parameters oldSecret and newSecret MUST be coded according to (N81.00).

(N758.00)
Table 95: (N758.50) CHANGE REFERENCE DATA with old and new user secret
Content Description
P1 00 Data contains old and new user secret
P2 XX passwordReference
Data XXYY oldSecret || newSecret
14.6.1.2 Use Case Setting a user secret
In this variant the APDU of the command CHANGE REFERENCE DATA contains two pa-
rameters:
(N759.00)
(N760.00)
(N761.00)
The parameter newSecret MUST be coded according to (N81.00).
(N762.00)
Table 96: (N762.40) CHANGE REFERENCE DATA, only new user secret
Content Description
P1 01 Data contains the new user secret
Data XXYY newSecret
14.6.1.3 Response of the smartcard to the change of the user secret

Table 97: (N762.50) CHANGE REFERENCE DATA Response APDU in case of success

90 00 NoError Change of the user secret successful
63 Cx WrongSecretWarning oldSecret is wrong

Table 98: (N762.60) CHANGE REFERENCE DATA Response APDU in case of failure

6A 88 PasswordNotFound Adressed password not found
69 83 PasswordBlocked Retry counter down to zero
69 85 ShortPassword newData contains a password which is too short
(N763.00)

(N764.00)
The COS MUST support the variant of CHANGE REFERENCE DATA from 14.6.1.1.
(N765.00)
Note: The content of this paragraph has been changed and moved to (N767.50).
(N766.00)
The COS MAY support additional variants of CHANGE REFERENCE DATA.
The COS MAY refuse additional variants of CHANGE REFERENCE DATA.
(N767.00)
It applies: affectedObject = searchPwd( currentFolder, passwordReference ). If and
only if the search for the password stops with an error, then the command MUST be
terminated with the trailer PasswordNotFound.
(N767.50)
If the affectedObject.transportStatus has the value Empty_PIN_1 (see (N95.00)), then
the COS MUST support the variant of CHANGE REFERENCE DATA from 14.6.1.2.
(N768.00)
(N769.00)
If and only if affectedObject.retryCounter has the value zero, then the command MUST
be terminated with the trailer PasswordBlocked.
(N770.00)
If and only if the sequence of numbers coded in newSecret for the attribute secret of
the password object has a length which is less than affectedObject.minimumLength,
then the command MUST be terminated with the trailer ShortPassword.
(N771.00)
By means of clearPasswordStatus( affectedObject ) the security status MUST be set to
zero.
Note: The processing sequence of (N768.00), (N769.00), (N770.00) and (N771.00) is manufacturer-
specific. Therefore, it is manufacturer-specific whether in certain error cases the security status of
affectedObject is deleted or not.
(N772.00)
If and only if the data field of the command message contains oldSecret, then the at-
tribute affectedObject.secret MUST be compared with oldSecret.
a. If and only if the comparison fails
i. affectedObject.retryCounter MUST be decremented by one and
ii. the command MUST terminate with the trailer WrongSecretWarning. The
lownibble of the trailer MUST be set to the value F, if affectedOb-
ject.retryCounter is greater than 15, otherwise to the value of affectedOb-
ject.retryCounter.
b. If and only if the comparison is successful
i. the attribute affectedObject.retryCounter MUST be set to the value of affecte-
dObject.startRetryCounter and
ii. the attribute affectedObject.secret MUST be set to the value coded in newSe-
cret and
iii. the attribute affectedObject.transportStatus MUST be changed to the value
regularPassword (see Table 9 (N98.50)).
c. If the comparison operation is terminated by a reset, then affectedOb-
ject.retryCounter MUST be decremented by one.
(N773.00)
All persistent changes in (N772.00)b MUST be executed with transaction protection.
(N774.00)
(N775.00)
used as trailer.
(N776.00)
(N777.00)
b. Each trailer in Table 98 (N762.60) MUST have a higher priority than WrongSecret-
Warning.
c. WrongSecretWarning MUST have a higher priority than UpdateRetryWarning.
d. UpdateRetryWarning MUST have a higher priority than NoError.
(N778.00)
If the execution of this command is terminated by a reset, then it applies for the change
of affectedObject.transportStatus and affectedObject.secret:
a. both attributes SHOULD be changed together in one transaction.
b. secret MAY be changed in a separate transaction being executed before transport-
Status.
c. transportStatus MUST NOT be changed in a persitent way if secret is not also
changed in a persistent way.
14.6.2 DISABLE VERIFICATION REQUIREMENT
The command DISABLE VERIFICATION REQUIREMENT changes the attribute flagEnabled

of a password object (see Clause 8.4) so that the COS acts as if the security status of the

password is permanently set. The affected password object will be defined by a password
reference which is a parameter of the command message.
14.6.2.1 Use Case Disable user verification
In this variant the APDU of the command DISABLE VERIFICATION REQUIREMENT con-
tains one parameter:
(N779.00)
(N780.00)
Table 99: (N780.40) DISABLE VERIFICATION REQUIREMENT without verification data
Content Description
P1 01 No verification data
14.6.2.2 Response of the smartcard to disable of user verification

Table 100: (N780.50) DISABLE VERIFICATION REQUIREMENT Response APDU in case of suc-
cess

90 00 NoError Disabling of the password object successful
63 Cx UpdateRetryWarning Like NoError, but problems with writing
Table 101: (N780.60) DISABLE VERIFICATION REQUIREMENT Response APDU in case of fail-
ure

(N781.00)

(N782.00)
The COS MAY support the variant of the command DISABLE VERIFICATION RE-
QUIREMENT from 14.6.2.1.
The COS MAY support additional variants of DISABLE VERIFICATION REQUIRE-
MENT.
The COS MAY refuse all variants of DISABLE VERIFICATION REQUIREMENT.
(N783.00)
It applies affectedObject = searchPwd( currentFolder, passwordReference). If and only
if the search for the password stops with an error, then the command MUST be termi-
nated with the trailer PasswordNotFound.
(N784.00)
(N785.00)
If affectedObject.flagEnabled has the value False, then the command MUST termi-
nate with the trailer NoError.
(N786.00)
The attribute affectedObject.flagEnabled MUST be set to the value False with trans-
action protection.
(N787.00)
(N788.00)
used as trailer.
(N789.00)
(N790.00)
Warning.
14.6.3 ENABLE VERIFICATION REQUIREMENT
The command ENABLE VERIFICATION REQUIREMENT changes the attribute flagEnabled

of a password object (see Clause 8.4) so that the security status of the password can only be
set by successful user verification. The affected password object will be defined by a pass-
word reference which is a parameter of the command message.
14.6.3.1 Use Case Enable user verification
In this variant the APDU of the command ENABLE VERIFICATION REQUIREMENT con-
tains one parameter:
(N791.00)
(N792.00)

APDU the instructions of Table 102 (N792.40) MUST be used
Table 102: (N792.40) ENABLE VERIFICATION REQUIREMENT without verification data
Content Description
P1 01 No verification data
14.6.3.2 Response of the smartcard to enable user verification

Table 103: (N792.50) ENABLE VERIFICATION REQUIREMENT Response APDU in case of suc-
cess

90 00 NoError Enabling of the password object successful
Table 104: (N792.60) ENABLE VERIFICATION REQUIREMENT Response APDU in case of failure

(N793.00)

(N794.00)
The COS MAY support the variant of the command ENABLE VERIFICATION RE-
QUIREMENT from 14.6.3.1.
The COS MAY support additional variants of ENABLE VERIFICATION REQUIRE-
MENT.
The COS MAY refuse all variants of ENABLE VERIFICATION REQUIREMENT.
(N795.00)
(N796.00)
(N797.00)
If affectedObject.flagEnabled has the value True, then the command MUST terminate
with the trailer NoError
(N798.00)
The attribute affectedObject.flagEnabled MUST be set to the value True with transac-
tion protection.
(N799.00)
(N800.00)
used as trailer.
(N801.00)
(N802.00)
Warning.
14.6.4 GET PIN STATUS

Note: This command is not contained in ISO/IEC 7816. It could be combined with the command VER-
IFY (empty command data). Due to a vote of DIN NIA17.4 such a combination will not be used.
The command GET PIN STATUS indicates in the response data,
whether a security status of the password object has been set,
the value of the attribute retryCounter.
whether a password object is protected by a transport PIN and if so, which transport PIN
process is used by the password object.
The affected password object will be defined by a password reference which is a parameter
of the command message.
14.6.4.1 Use Case Read the status of a password object
In this variant the APDU of the command GET PIN STATUS contains one parameter:
(N803.00)
(N804.00)
APDU the instructions Table 105 (N804.40) MUST be used.

Table 105: (N804.40) GET PIN STATUS
Content Description
CLA 80 CLA Byte according to [ISO7816-4] indicated here as proprietary
INS 20 Instruction Byte
P1 00
14.6.4.2 Response of the smartcard to GET PIN Status

Table 106: (N804.50) GET PIN STATUS Response APDU in case of success

90 00 NoError Verification not necessary
62 Cx: TransportStatus: Password object is a transport PIN,
62 C1 Transport_PIN_random transport PIN details in Least Significant Nibble (see
62 C2 Transport_PIN_derived also Clause 8.2.5)
62 C4 Empty_PIN_2
62 C5 Transport_PIN_fixedValue
62 C7 Empty_PIN_1
62 CF Transport_PIN_0000
63 Cx RetryCounter Password object without transport PIN (that means
regularPassword), value for retry counter in Least Sig-
nificant Nibble
Table 107: (N804.60) GET PIN STATUS Response APDU in case of failure

(N805.00)

(N806.00)
The COS MUST support the variant of the command GET PIN STATUS from 14.6.4.1
The COS MAY support additional variants of GET PIN STATUS.
The COS MAY refuse additional variants of GET PIN STATUS.
(N807.00)
(N808.00)

(N809.00)
If the attribute affectedObject.flagEnabled (see (N160.00)) has the value False, then
the command MUST terminate with the trailer NoError.
(N810.00)
If affectedObject is contained in globalPasswordList (see (N321.00)i) or in dfSpeci-
ficPasswordList (see (N321.00)j) and there the attribute securityStatusEvaluationCoun-
ter (see (N321.00)k) has a value which is not equal to zero, then the trailer NoError
MUST be used.
(N811.00)
If and only if the attribute affectedObject.transportStatus (see (N159.00)) has a value
not equal to regularPassword, then the trailer TransportStatus MUST be used with
transportStatus = 62 Cx. x has to be replaced by the coding of affectedObject.trans-
portStatus, according to Table 9 (N98.50).
(N812.00)
If and only if the attribute affectedObject.transportStatus (see (N159.00)) has the value
regularPassword, then RetryCounter MUST be used as trailer with RetryCounter = 63
Cx. x has to be replaced by the minimum of the two numbers 15 = F and affected-
Object.retryCounter.
(N813.00)
b. Each trailer in Table 107 (N804.60) MUST have a higher priority than NoError.
c. NoError MUST have a higher priority than TransportStatus.
d. TransportStatus MUST have a higher priority than RetryCounter.
Note: According to (N811.00), (N812.00) and (N813.00) it is not possible to retrieve the value of the
retry counter while there is transport protection.
14.6.5 RESET RETRY COUNTER
The command RESET RETRY COUNTER sets the attribute retryCounter of a password ob-
ject to the initial value startRetryCounter. The affected password object will be defined by a
password reference which is a parameter of the command message. This command exists in
the variants
with and without PUK
with and without a new value for the attribute secret of the password object.
Typically the variant with PUK is used, if a non-technical entity (e.g. the cardholder) has
the right to execute this operation.
Typically the variant without PUK is used, if a technical entity (e.g. the CMS) has to execute
this operation. In this case at least a role authentication is mandatory in the access condi-
tions.
Typically the variant with new secret is used, if the cardholder has definitely forgotten his
password.
Typically the variant without new secret is used, if it is forbidden for the entity being author-
ized to reset the retry counter to execute operations protected by the password. This is
mainly used in the context of applications for qualified electronic signatures and the signature
password.

The command RESET RETRY COUNTER does not set a security status (see (N834.00)).
14.6.5.1 Use Case Reset with PUK, with new secret
In this variant the APDU of the command RESET RETRY COUNTER contains three parame-
ters:
(N814.00)
(N815.00)
The parameter PUK contains a secret, which authorizes this operation.
(N816.00)
(N817.00)
The parameters PUK and newSecret MUST be coded according to (N81.00).
(N818.00)
Table 108: (N818.50) RESET RETRY COUNTER, with PUK, with newSecret
Content Description
P1 00 Data contains PUK and new user secret
Data XXYY PUK || newSecret
14.6.5.2 Use Case Reset with PUK, without new secret
In this variant the APDU of the command RESET RETRY COUNTER contains two parame-
ters:
(N819.00)
(N820.00)
The parameter PUK contains a secret, which authorizes this operation.
(N821.00)
The parameter PUK MUST be coded according to (N81.00).
(N822.00)

Table 109: (N822.50) RESET RETRY COUNTER, with PUK, without newSecret
Content Description
P1 01 Data contains only the PUK
Data XXYY PUK
14.6.5.3 Use Case Reset without PUK, with new secret
In this variant the APDU of the command RESET RETRY COUNTER contains two parame-
ters:
(N823.00)
(N824.00)
The parameter newSecret contains the new user secret,
(N825.00)
The parameter newSecret MUST be coded according to (N81.00).
(N826.00)
Table 110: (N826.50) RESET RETRY COUNTER, without PUK, with newSecret
Content Description
P1 02 Data contains only the new user secret
Data XXYY newSecret
14.6.5.4 Use Case Reset without PUK, without new secret
In this variant the APDU of the command RESET RETRY COUNTER contains one parame-
ter:
(N827.00)
(N828.00)

Table 111: (N828.40) RESET RETRY COUNTER, without PUK, without newSecret
Content Description
P1 03 Command data field absent
14.6.5.5 Response of the smartcard to the reset of a user secret

Table 112: (N828.50) RESET RETRY COUNTER Response APDU in case of success

90 00 NoError Reset of the retry counter successful
63 Cx WrongSecretWarning PUK is wrong
Table 113: (N828.60) RESET RETRY COUNTER Response APDU in case of failure

69 85 ShortPassword newData contains a password being too short
69 83 CommandBlocked Retry counter down to zero
(N829.00)

(N830.00)
The COS MUST support the variants of the command RESET RETRY COUNTER from
14.6.5.1, 14.6.5.2, 14.6.5.3 and 14.6.5.4.
The COS MAY support additional variants of RESET RETRY COUNTER.
The COS MAY refuse additional variants of RESET RETRY COUNTER.
(N831.00)
(N832.00)
(N833.00)
If and only if the conditional sequence of numbers being coded in newSecret for the at-
tribute secret of the password object has a length which is less than affected-

Object.minimumLength, then the command MUST be terminated with the trailer Short-
Password.
(N834.00)
By means of clearPasswordStatus( affectedObject ) the security status MUST be set to
zero.
(N835.00)
If and only if the command data field contains a parameter PUK, then this parameter
MUST be compared with the attribute affectedObject.PUK.
a. If and only if affectedObject.pukUsage has the value zero, then the command MUST
terminate with the trailer CommandBlocked.
b. affectedObject.pukUsage MUST be decremented by one with transaction protection.
c. If and only if the comparison fails, the command MUST terminate with the trailer
WrongSecretWarning. The Lownibble of the trailer MUST be set to F, if affecte-
dObject.pukUsage is greater than 15, otherwise to the value of affectedObject.puk-
Usage.
Note: The processing sequence of (N832.00), (N833.00), (N834.00) and (N835.00) is manufacturer-
specific.Therefore, it is manufacturer-specific whether in certain error cases the security status is
deleted or not.
(N836.00)
The attribute affectedObject.retryCounter MUST be set to the value of affectedOb-
ject.startRetryCounter.
(N837.00)
If and only if the command data field contains a parameter newSecret, then the attrib-
ute
a. affectedObject.secret MUST be set to the value coded in newSecret.
b. affectedObject.transportStatus MUST be set to the value regularPassword = 6
(see Table 9 (N98.50)).
(N838.00)
The persistent changes in (N835.00), (N836.00) and (N837.00) MUST be executed
with transaction protection.
(N839.00)
(N840.00)
used as trailer.
(N841.00)
(N842.00)
b. Each trailer in Table 113 (N828.60) MUST have a higher priority than WrongSe-
cretWarning.

(N843.00)
If the execution of this command is interrupted by a reset, then it applies for possible
changes of secret, transportStatus and retryCounter:
a. All changes SHOULD be done together in one transaction.
b. All changes MAY be done each in a separate transaction. In this case retryCounter
MUST be changed at the end of the sequence.
14.6.6 VERIFY
The command VERIFY compares the attribute secret of a password object with data being
part of the data field of the command message. If the comparison is successful the security
status of the smartcard is changed. The affected password object will be defined by a pass-
word reference which is a parameter of the command message.
14.6.6.1 Use Case Verification of a user secret
In this variant the APDU of the command VERIFY contains two parameters:
(N844.00)
(N845.00)
The parameter verificationData contains the new user secret.
(N846.00)
The parameter verificationData MUST be coded according to (N81.00).
(N847.00)
Table 114: (N847.40) VERIFY
Content Description
P1 00 Data contains verification data
Data XXYY verificationData
14.6.6.2 Response of the smartcard to the verification of a user secret

Table 115: (N847.50) VERIFY Response APDU in case of success

90 00 NoError Comparison successful
63 Cx WrongSecretWarning verificationData wrong

Table 116: (N847.60) VERIFY Response APDU in case of failure

6A 88 PasswordNotFound Addressed password not found
69 85 PasswordNotUsable Password in status Transport_PIN
(N848.00)

(N849.00)
The COS MUST support the variant of the command VERIFY from 14.6.6.1.
The COS MAY support additional variants of VERIFY.
The COS MAY refuse additional variants of VERIFY.
(N850.00)
(N851.00)
(N852.00)
If and only if affectedObject.retryCounter has the value zero, then the command MUST
be terminated with the trailer PasswordBlocked
(N853.00)
If and only if affectedObject.transportStatus has not the value regularPassword, then
the command MUST terminate with the trailer PasswordNotUsable.
(N854.00)
The attribute affectedObject.secret MUST be compared with verificationData.
a. If the comparison fails,
i. affectedObject.retryCounter MUST be decremented by one and
ii. clearPasswordStatus( affectedObject) MUST be executed and
iii. the command MUST terminate with the trailer WrongSecretWarning. The low-
nibble of the trailer MUST be set to the value F if affectedObject.retryCounter
is greater than 15, otherwise to the value of affectedObject.retryCounter.
b. If the comparison operation is interrupted by a reset, then affectedObject.retry-
Counter MUST be decremented by one.
c. If and only if the comparison is successful, then
i. setPasswordStatus( affectedObject) MUST be executed and
ii. the attribute affectedObject.retryCounter MUST be set to the value affected-
Object.startRetryCounter. These changes MUST be executed with transaction
protection.

(N855.00)
(N856.00)
used as trailer.
(N857.00)
(N858.00)
b. Each trailer in Table 116 (N847.60) MUST have a higher priority than WrongSe-
cretWarning.
14.7 Component Authentication
14.7.1 EXTERNAL AUTHENTICATE / MUTUAL AUTHENTICATE
The command EXTERNAL AUTHENTICATE validates the authenticity of an external entity

with the help of a token generated by the smartcard, using a symmetric or an asymmetric
key. The key is selected prior to the authentication operation. This is done by sending a
command MSE: SET before EXTERNAL AUTHENTICATE is sent, see Clause 14.9.6.4,
Clause 14.9.6.5 and Clause 14.9.6.6. The response of the external entity is part of the com-
mand message as a parameter.
14.7.1.1 Use Case External authentication without response data
In this variant the APDU of the command EXTERNAL AUTHENTICATE contains one pa-
rameter:
(N859.00)
The parameter cmdData contains the response of the external entity. The parameter
cmdData is an octet string with any content. The length of cmdData is depending on
algID, being chosen according to (N1105.00) or (N1111.00). If algID equals
a. aesRoleCheck, then cmdData MUST (to be completed for generation 2).
b. aesSessionkey4SM, then cmdData MUST (to be completed for generation 2)
c. desRoleCheck, then cmdData MUST be 8 octets long.
d. desSessionKey4SM, then cmdData MUST be 104 Octets long.
e. (requirement for SMC-A and SMC-B) desSessionkey4TC, then cmdData MUST be
104 octets long.
f. elcRoleCheck, then cmdData MUST (to be completed for generation 2)
g. rsaRoleCheck, then cmdData MUST contain exactly the number of octets as the
modulus of the authentication key.

h. rsaSessionkey4SM, then cmdData MUST contain as many octets as the modulus of
the authentication key.
i. rsaSessionkey4Intro, then cmdData MUST contain as many octets as the modulus
of the authentication key.
j. (requirement for SMC-A and SMC-B) rsaSessionkey4TC, then cmdData MUST con-
tain as many octets as the modulus of the authentication key
(N860.00)
Table 117: (N860.50) EXTERNAL AUTHENTICATE without response data
Content Description
P1 00 Information in respect to the algorithm already present in the smartcard
P2 00 key reference already present in the smartcard
Data XXYY cmdData
14.7.1.2 Use Case External authentication with response data
In this variant the APDU of the command MUTUAL AUTHENTICATE contains two parame-
ters:
(N861.00)
The parameter cmdData contains the response of the external entity. The parameter
cmdData is an octet string with any content. The length of cmdData is depending on
algID, being chosen according to (N1116.00). If algID equals
a. aesSessionkey4SM, then cmdData MUST (to be completed for generation 2)
b. desSessionkey4SM, then cmdData MUST be 104 octets long.
c. (requirement for SMC-A and SMC-B) desSessionkey4TC, then cmdData MUST be
104 octets long.
(N862.00)
(N863.00)

Table 118: (N863.40) MUTUAL AUTHENTICATE with response data
Content Description
P1 00 Information in respect to the algorithm already present in the smartcard
P2 00 key reference already present in the smartcard
Data XXYY cmdData
14.7.1.3 Response of the smartcard to external authentication

Table 119: (N863.50) EXTERNAL AUTHENTICATE Response APDU in case of success

XXYY authData Authentication data (conditional, depending on algID)
90 00 NoError Authentication successful
Table 120: (N863.60) EXTERNAL AUTHENTICATE Response APDU in case of failure

69 85 NoRandom No random number present, see also Clause 15.1
69 85 NoKeyReference No authentication key selected
6A 88 KeyNotFound authentication key not found
6A 81 UnsupportedFunction Key does not support the selected algorithm
63 00 AuthenticationFailure Authentication failed
69 85 NoPrkReference No decryption key selected
6A 88 PrKNotFound decryption key not found
(N864.00)

(N865.00)
The COS MUST support the variants of the command EXTERNAL AUTHENTICATE
from 14.7.1.1 and 14.7.1.2.
The COS MAY support additional variants of EXTERNAL AUTHENTICATE.
The COS MAY refuse additional variants of EXTERNAL AUTHENTICATE.
(N866.00)
If and only if no RND.ICC is available (see (N1073.00), (N321.00)b and Clause 15),
then the command MUST terminate with the trailer NoRandom.
(N867.00)
If and only if channelContext.keyReferenceList.externalAuthenticate
a. is empty, then the command MUST terminate with the trailer NoKeyReference.

b. is not empty, then affectedObject = SearchKey(
currentFolder,
channelContext.keyReferenceList.externalAuthenticate.keyReference,
channelContext.keyReferenceList.externalAuthenticate.algID
) is set. According to Clause 9.2.3 and (N1136.00) it MAY happen that the search
for the key is not successful. If and only if the key search returns with the error
i. keyNotFound, then the command MUST terminate with the trailer KeyNot-
Found.
ii. notSupported, then the command MUST terminate with the trailer Unsup-
portedFunction.
(N868.00)
The COS MAY delete the security status by means of clearSecurityStatus(affected-
Object) before the access rule (see (N869.00)) or the command data (see (N870.00)
and (N870.10)) are evaluated. In this case the deletion of the security status according
to (N871.00) is not required.
(N869.00)
If and only if affectedObject is a symmetric key and AccessRuleEvaluation( affectedOb-
ject, CLA, INS, P1, P2 ) returns the value False, then the command MUST terminate
with the trailer SecurityStatusNotSatisfied.
(N870.00)
The response of the external entity is contained in cmdData. If the command APDU
does not contain an Le field, i.e. it is a Case 3 according to Clause 11.7.3, then it ap-
plies authData = (empty octet string) and cmdData is processed as follows:
If channelContext.keyReferenceList.externalAuthenticate.algID has the value
a. aesRoleCheck, then it applies
i. ( resp , T ) = AES_CTR_ENC( affectedObject.encKey, 0, RND.ICC )
ii. If resp is not equal to cmdData, then the command MUST terminate with the
trailer AuthenticationFailure.
b. aesSessionkey4SM, then (to be completed for generation 2)
c. desRoleCheck, then it applies
i. resp = 3TDES_CBC_ENC( affectedObject.encKey, 0, RND.ICC )
ii. If resp is not equal to cmdData, then the command MUST terminate with the
d. desSessionkey4SM, then the following steps have to be executed:
i. cmdData is divided as follows:
1. cmdData = C1 || MAC1
2. OctetLength( MAC1 ) = 8.
ii. out = VERIFY_Retail_MAC( affectedObject.macKey, MAC1, C1 )
iii. If out has the value INVALID, then the command MUST terminate with the
iv. S = 3TDES_CBC_DEC( affectedObject.encKey, 0, C1 )
v. S will be divided as follows:
1. S = RND.ext || ICCSN8.ext || RND.int || ICCSN8.int || KD.e
2. It is 8 = OctetLength( RND.ext )

3. It is 8 = OctetLength( ICCSN8.ext )
4. It is 8 = OctetLength( RND.int )
5. It is 8 = OctetLength( ICCSN8.int )
6. It is 64 = OctetLength( KD.e )
vi. The command MUST terminate with AuthenticationFailure if and only if
1. RND.int is unequal to RND.ICC (see (N866.00)) or
2. ICCSN8.int is unequal to iccsn8 (see (N210.00)c).
vii. The octet string KD.e MUST be handed over to the Secure Messaging Layer
(see Clause 13.1).
e. (requirement for SMC-A and SMC-B) desSessionkey4TC, then in the context of the
command execution it MUST be worked in an identical way as for desSessionkey-
4SM.
f. elcRoleCheck, then it applies (to be completed for generation 2)
g. rsaRoleCheck, then it applies with PuK = affectedObject.publicKey
i. Set M2 = RND.ICC || iccsn8
ii. ( out, M ) = RSA_ISO9796_2_DS1_VERIFY( PuK, cmdData, M2 )
If this operation terminates with an error or out has the value False, then the
command MUST terminate with the trailer AuthenticationFailure.
h. rsaSessionkey4SM, then the following steps have to be executed:
i. If and only if channelContext.keyReferenceList.internalAuthenticate
1. Is empty, then the command MUST terminate with the trailer NoPrkRefer-
ence.
2. Is not empty, then tmpObject = SearchKey(
currentFolder,
channelContext.keyReferenceList.internalAuthenticate.keyReference,
channelContext.keyReferenceList.internalAuthenticate.algID
) is set. According to Clause 9.2.3.1 and according to (N1136.00) it MAY
happen that the search for the key is not successful. If the key search re-
turns the error
A. keyNotFound, then the command MUST terminate with the trailer Key-
NotFound.
B. notSupported, then the command MUST terminate with the trailer Un-
supportedFunction.
ii. The COS MAY perform or omit an evaluation of the access rule for the private
key in tmpObject according to AccessRuleEvaluation( tmpObject, CLA, INS,
P1, P2 ).
Note: Authentication sequences are not interruptible according to this specifi-
cation (see (N1149.00)). The authentication protocol rsaSessionkey4SM ac-
cording to Chapter Clause 15.4.3 and 15.4.4 performs an external as well as
internal authentication with evaluating an access rule of the private key at the
internal authentication (see (N894.00)). Therefore, an evaluation of an access
rule according to (N870.00)h.ii is functionally not required. However, it may be
necessary to prove in connection with an evaluation, that an omission of the
access rule evaluation according too (N870.00)h.ii does not compromise se-
curity.

iii. Set tmpData = cmdDataPrK.d mod PrK.n,
with PrK = tmpObject.privateKey
iv. Set M2 = RND.ICC || iccsn8
v. ( out, M ) = RSA_ISO9796_2_DS1_VERIFY( PuK, tmpData, M2 )
command MUST terminate with the trailer AuthenticationFailure.
vi. M is divided in M = M1 || M2. The 64 LSByte in M1 MUST be handed over as
KD.e to the Secure Messaging Layer (see Clause 13.1).
i. rsaSessionkey4Intro, then in the context of the command execution it MUST be
worked in an identical way as for rsaSessionkey4SM.
j. (requirement for SMC-A and SMC-B) rsaSessionkey4TC, then in the context of the
command execution it MUST be worked in an identical way as for rsaSessionkey-
4SM.
(N870.10)
The response of the external entity is contained in cmdData. If the command APDU
contains an Le field, i.e. it is a Case 4 according to Clause 11.7.4, then cmdData is
processed as follows:
If channelContext.keyReferenceList.externalAuthenticate.algID has the value
a. desSessionKey4SM, then the following steps MUST be executed in the specified
order:
i. cmdData is divided as follows:
1. cmdData = C1 || MAC1
2. OctetLength( MAC1 ) = 8.
ii. out = VERIFY_Retail_MAC( affectedObject.macKey, MAC1, C1 )
iii. If out has the value INVALID, then the command MUST terminate with the
iv. S = 3TDES_CBC_DEC( affectedObject.encKey, 0, C1 )
v. S will be divided as follows:
1. S = RND.ext || ICCSN8.ext || RND.int || ICCSN8.int || KD.e
2. It is 8 = OctetLength( RND.ext )
3. It is 8 = OctetLength( ICCSN8.ext )
4. It is 8 = OctetLength( RND.int )
5. It is 8 = OctetLength( ICCSN8.int )
6. It is 64 = OctetLength( KD.e )
vi. The command MUST terminate with the trailer
AuthenticationFailure if and only if
1. RND.int is unequal RND.ICC (see (N866.00)) or
2. ICCSN8.int is unequal iccsn8 (see (N210.00)c).
vii. Set KD.i = RAND( 64 )
viii. Set R = RND.int || ICCSN8.int || RND.ext || ICCSN8.ext || KD.i
ix. Set C2 = 3TDES_CBC_ENC( affectedObject.encKey, 0, R )
x. Set MAC2 = CALCULATE_Retail_MAC(affectedObject.macKey, C2 )

xi. Set authData = C2 || MAC2
xii. The octet strings KD.e and KD.i MUST be handed over to the Secure Messag-
ing Layer (see Clause 13.1).
b. (Requirement for SMC-A and SMC-B) desSessionkey4TC, then in the context of the
command execution it MUST be worked in an identical way as for desSessionkey-
4SM.
(N871.00)
If and only if the command terminates with the trailer AuthenticationFailure, then
clearSecurityStatus( affectedObject ) MUST be executed.
(N872.00)
If and only if the command responds with the trailer NoError, then setSecurityStatus(
affectedObject ) MUST be executed.
(N873.00)
The (maybe empty) octet string authData MUST be used as data field of the response
message.
(N874.00)
NoError MUST be used as trailer.
(N875.00)
The following applies for the priority of the trailers.
14.7.2 GENERAL AUTHENTICATE
(N876.00)
14.7.3 GET SECURITY STATUS KEY

Note 1: This command is not contained in the series of the standards ISO/IEC 7816. It could be com-
bined with the command EXTERNAL AUTHENTICATE.
Note 2: The specification of the command APDU is based on the command MSE: SET.
Note 3: Motivation for the command: Starting with the assumption that a specific command is termi-
nated with the trailer SecurityStatusNotSatisfied, it is not obvious for the controlling software what
to do to get access. Even if the access conditions for the object are known it could only be real-
ised whether the conditions for Secure Messaging are met. If PIN verification is necessary the
corresponding security status can be asked for with the command GET PIN STATUS. If more
than one security status for keys is active, then the controlling software has only two possibilities:
either try and error (which is bad in respect to the performance) or it has an emulation of the fi-
nite state machine of the COS (and hopes that internal and external status stay synchronous).
The command GET SECURITY STATUS KEY is used to ask for the security status of key
objects. The security status to be read is determined by a reference which is part of the
command data as a parameter.
14.7.3.1 Use Case Read of the security status, symmetric key
In this variant the APDU of the command GET SECURITY STATUS KEY contains one pa-
rameter:

(N877.00)
The parameter cmdData contains a key reference. Value and coding MUST be chosen
according to (N1089.00).
(N878.00)
Table 121: (N878.50) GET SECURITY STATUS KEY, symmetric key
Content Description
INS 82 Instruction Byte (identical to EXTERNAL AUTHENTICATE)
P1 80 Read security status
P2 00
Data XXYY 83 01 || cmdData
14.7.3.2 Use Case Read security status of a role
In this variant the APDU of the command GET SECURITY STATUS KEY contains one pa-
rameter:
(N879.00)
The parameter cmdData contains a role reference. Value and coding MUST be chosen
according to 7.1.1.4 and (N57.00).
(N880.00)
Table 122: (N880.20) GET SECURITY STATUS KEY, role reference
Content Description
INS 82 Instruction Byte (identical to EXTERNAL AUTHENTICATE)
P1 80 Read security status
P2 00
Data XXYY 5F4C 07 || cmdData
14.7.3.3 Use Case Read security status of a a bitlist, G2 (informative)
This clause will be completed in a later version

14.7.3.4 Response of the smartcard to read a security status of a key
Table 123: (N880.80) GET SECURITY STATUS KEY Response APDU in case of success

90 00 NoError Authentication status set
63 CF NoAuthentication Authentication status not set
Table 124: (N880.90) GET SECURITY STATUS KEY Response APDU in case of failure

6A 88 KeyNotFound Addressed key object not found
(N881.00)

(N882.00)
The COS MUST support the variant of the command GET SECURITY STATUS KEY
from 14.7.3.1 and 14.7.3.2.
The COS MAY support additional variants of GET SECURITY STATUS KEY.
The COS MAY refuse additional variants of GET SECURITY STATUS KEY.
(N883.00)
If cmdData is the reference of a symmetric key according to Clause 14.7.3.1 then
a. affectedObject = SearchKey(
currentFolder,
cmdData,
Wildcard
) is set. According to Clause 9.2.3 and (N1136.00) it MAY happen, that the search
for a key is not successful. If and only if the search for a key returns the error key-
NotFound, then the command MUST terminate with the trailer KeyNotFound. The
error notSupported is not possible because of the search with a wildcard.
b. If and only if AccessRuleEvaluation( affectedObject, CLA, INS, P1, P2 ) returns
False, then the command MUST be terminated with the trailer SecurityStatusNot-
Satisfied.
c. If affectedObject is contained in globalSecurityList (see (N321.00)e) or in dfSpecifi-
cSecurityList (see (N321.00)f), then the trailer NoError MUST be used.
(N884.00)
If cmdData is a role according to Clause 14.7.3.2. and if this role is part of globalSecuri-
tyList (see (N321.00)e) or dfSpecificSecurityList (see (N321.00)f), then the trailer NoEr-
ror MUST be used.
(N885.00)
If cmdData is a bitList (to be completed for generation 2)
(N886.00)
Otherwise the trailer NoAuthentication MUST be used.
(N887.00)
c. NoError MUST have a higher priority than NoAuthentication.
14.7.4 INTERNAL AUTHENTICATE
The command INTERNAL AUTHENTICATE calculates the authentication data of a token

with the help of a symmetric or a private key. The key is selected prior to the authentication
operation. This is done by sending a command MSE: SET before INTERNAL AUTHENTI-
CATE is sent, see Clause 14.9.6.3. The token is part of the command message as a pa-
rameter.
14.7.4.1 Use Case Internal authentication
In this variant the APDU of the command INTERNAL AUTHENTICATE contains two parame-
ters:
(N888.00)
The parameter token contains the data to be authorised. The parameter token is an oc-
tet string of any content. The length of token token depends on the algID selected us-
ing noch suchen. If algID equals
a. aesRoleAuthentication, then token MUST be 16 octets long.
b. desRoleAuthentication, then token MUST be 8 octets long.
c. elc (to be completed for generation 2)
d. rsaClientAuthentication, then token MUST NOT be longer than 64 octets.
e. rsaRoleAuthentication, then token MUST be 16 octets long.
f. rsaSessionkey4SM, then token MUST be chosen according to (N1187.00).
g. rsaSessionkey4Intro, then token MUST be chosen according to (N1187.00) (HPC
towards an eGK) resp. (N1190.00) (SMC to HPC).
h. (requirement for SMC-A and SMC-B) rsaSessionkey4TC, then token MUST be cho-
sen according to (N1183.00) (SMC towards an eGK) resp. (N1190.00) (SMC to
HPC).
i. desSessionKey4SM, then token MUST be 16 octets long.
j. (requirement for SMC-A and SMC-B) desSessionKey4TC, then token MUST be 16
octets long
k. signPKCS1_V1_5, then the number of octets in token MUST be less than 0,4 Oc-
tetLength( n ), with n as modulus of the selected authentication key.
(N889.00)
(N890.00)

Table 125: (N890.40) INTERNAL AUTHENTICATE
Content Description
P1 00 Information in respect to the algorithm already available in the smartcard
P2 00 Key reference already available in the smartcard
Data XXYY token
14.7.4.2 Response of the smartcard to internal authentication

Table 126: (N890.50) INTERNAL AUTHENTICATE Response APDU in case of success

XXYY response Authentication Data
90 00 NoError Authentication operation successful
Table 127: (N890.60) INTERNAL AUTHENTICATE Response APDU in case of failure

69 85 NoKeyReference No authentication key selected
6A 88 KeyNotFound authentication key not found
6A 81 UnsupportedFunction Key does not support selected algorithm
69 85 NoPukReference No encryption key selected
6A 88 PukNotFound encryption key not found
(N891.00)

(N892.00)
The COS MUST support the variants of the command INTERNAL AUTHENTICATE
from 14.7.4.1.
The COS MAY support additional variants of INTERNAL AUTHENTICATE.
The COS MAY refuse additional variants of INTERNAL AUTHENTICATE.
(N893.00)
If and only if channelContext.keyReferenceList.internalAuthenticate
currentFolder,
channelContext.keyReferenceList.internalAuthenticate.keyReference,
channelContext.keyReferenceList.internalAuthenticate.algID
) is set. According to Clause 9.2.3 and (N1136.00) it MAY happen that the search for
a key is not successful. If the search for a key returns the error
Found.
ii. notSupported meldet, then the command MUST terminate with the trailer
UnsupportedFunction.
(N894.00)
(N895.00)
The response response is calculated as follows:
If channelContext.keyReferenceList.internalAuthenticate.algID has the value
a. aesRoleAuthentication, then it applies
( response , T ) = AES_CTR_ENC( affectedObject.encKey, 0, token )
b. desRoleAuthentication, then it applies
response = 3TDES_CBC_ENC( affectedObject.encKey, 0, token )
c. elc*, then it applies (to be completed for generation 2)
d. rsaClientAuthentication, then it applies
response = RSASSA_PSS_SIGN( affectedObject.privateKey, token )
e. rsaRoleAuthentication, then it applies with
PrK = affectedObject.privateKey
i. PRND = RAND(OctetLength( PrK.n ) 34 )
ii. M = PRND || token
iii. ( response, M2 ) = RSA_ISO9796_2_DS1_SIGN( PrK, M )
Note: The length of PRND is chosen in a way that M2 = token. Therefore it is not nec-
essary to include M2 in the response message.
f. rsaSessionkey4SM, then it applies with PrK = affectedObject.privateKey
i. KD.i = RAND( 64 )
The octet string KD.i MUST be transferred to the Secure Messaging Layer
(see Clause 13.1).
ii. PRND = RAND(OctetLength( PrK.n ) 34 OctetLength(KD.i) )
iii. M = PRND || KD.i || token
iv. ( sig, M2 ) = RSA_ISO9796_2_DS1_SIGN( PrK, M )
Note: The length of PRND is chosen in a way that M2 = token. Therefore it is not nec-
essary to include M2 in the response message.
v. If channelContext.keyReferenceList.externalAuthenticate
1. is empty, then the command MUST terminate with the trailer NoPukRefer-
ence.
2. is not empty, then tmpObject = SearchKey(
currentFolder
channelContext.keyReferenceList.externalAuthenticate.keyReference,
channelContext.keyReferenceList.externalAuthenticate.algID
) is set. According to Clause 9.2.3.2 and according to (N1136.00) it MAY
happen, that the search for a key is not successful. Then the command
MUST terminate with the trailer PuKNotFound.
vi. response = sigPuK.e mod PuK.n, with PuK = tmpObject.publicKey.
g. desSessionKey4SM or (requirement for SMC-A and SMC-B) desSessionkey4TC,
then the following steps will be executed:

i. Set RND.int = RAND( 8 )
ii. Set ICCSN8.int = iccsn8 (see (N210.00)c)
iii. Set KD.i = RAND( 64 )
iv. Set S = RND.int || ICCSN8.int || token || KD.i
v. Set C1 = 3TDES_CBC_ENC ( affectedObject.encKey, 0, S )
vi. Set MAC1 = CALCULATE_Retail_MAC( affectedObject.macKey, C1 )
vii. Set response = C1 || MAC1
viii. RND.int MUST be stored as RND.ICC (see (N321.00)b).
ix. KD.i MUST be passed to the Secure Messaging Layer (see (N321.00)).
h. rsaSessionkey4Intro or rsaSessionkey4TC, then in the context of the command
processing it MUST be acted identical to rsaSessionkey4SM.
i. signPKCS1_V1_5, then it applies:
response = RSASSA_PKCS1_V1_5_SIGN( PrK, token )
(N896.00)
As data field of the response message response MUST be used.
(N897.00)
(N898.00)
14.8 Commands of the Cryptobox
14.8.1 PSO: COMPUTE DIGITAL SIGNATURE
The command PSO: COMPUTE DS signs data using a private key. The private key and the
algorithm to be used are selected prior to the signature operation. This is done by sending a
command MSE: SET before PSO: COMPUTE DS is sent, see Clause 14.9.6.7. The data to
be signed are part of the command message as a parameter.
14.8.1.1 Use Case Signing of the data field, without message recovery
This variant applies for the following algorithms (see (N189.00) and (N194.00)): rsaClientAu-
thentication, signPKCS1_V1_5, signPSS, signECDSA.
In this variant the APDU of the command PSO: COMPUTE DS contains two parameters:
(N899.00)
The parameter dataToBeSigned contains the data to be signed. The parameter data-
ToBeSigned is an octet string of any content. The length of dataToBeSigned depends
on the algID selected by (N1121.00). If algID equals
a. rsaClientAuthentication, then dataToBeSigned MUST NOT be longer than 64 octets.
b. signPKCS1_V1_5, then the number of octets in dataToBeSigned MUST be less
than 0,4 OctetLength( n ), with n being the Modulus of the selected signature key.
c. signPSS, then dataToBeSigned MUST NOT be longer than 64 octets.

d. signECDSA, then the number of octets in dataToBeSigned is subject only to the re-
strictions in Clause 11.5.5.
(N900.00)
The parameter length determines the length of the expected response data. The val-
ued of length MUST be chosen from the range defined in Clause 11.5.6.
(N901.00)
Table 128: (N901.50) PSO: COMPUTE DS, signing of a data field, without message recovery
Content Description
INS 2A Instruction Byte according to [ISO7816-4]
P1 9E Description of the response data, here digital signature
P2 9A Description of the command data, here data to be signed
Data XXYY dataToBeSigned
14.8.1.2 Use Case Signing of a data field, with message recovery
This variant applies for the following algorithm (see (N194.00)): sign9796_2_DS2.
In this variant the APDU of the command PSO: COMPUTE DS contains three parameters:
(N902.00)
The parameter M1 contains the recoverable part of the message to be signed. The
parameter M1 is an octet string of any content. The bit length of M1 MUST NOT ex-
ceed the capacity of the scheme according to [ISO9796-2] Clause 9.1.4.
(N903.00)
The parameter hashM2 contains the hash value of the non recoverable part of the
message to be signed. The parameter hashM2 is an octet string of any content, whose
length MUST be less than or equal to 64 octets.
(N904.00)
(N905.00)
The parameters M1 and hashM2 MUST be present in the data fieldof the command
message. The coding is specified in (N912.00). The number of octets in signIn-
put9796_2_DS2 is restricted by (N902.00) and (N903.00).
(N906.00)

Table 129: (N906.40) PSO: COMPUTE DS, signing of a data field, with message recovery
Content Description
P1 9E Description of the response data, here digital signature
P2 AC Description of the command data, here data to be signed as DE
Data XXYY signInput9796_2_DS2
14.8.1.3 Response of the smartcard to the signature of data

Table 130: (N906.50) PSO: COMPUTE DS Response APDU in case of success

XXYY signature Signature
90 00 NoError Signature operation successful
Table 131: (N906.60) PSO: COMPUTE DS Response APDU in case of failure

69 85 NoKeyReference No signature key selected
6A 88 KeyNotFound Key not found
64 00 KeyInvalid Key data missing
(N907.00)

(N908.00)
The COS MUST support the variants for PSO: COMPUTE DS from 14.8.1.1 and
14.8.1.2.
The COS MAY support additional variants for PSO: COMPUTE DS.
The COS MAY refuse additional variants for PSO: COMPUTE DS.
(N909.00)
If and only if channelContext.keyReferenceList.signatureCreation
currentFolder,
channelContext.keyReferenceList.signatureCreation.keyReference,
channelContext.keyReferenceList.signatureCreation.algID
) is set. According to Clause 9.2.3.1 and according to (N1136.00) it MAY happen,
that the search for a key is not successful. If the search for a key returns the error

i. keyNotFound, then the command MUST be terminated with the trailer Key-
NotFound.
ii. notSupported, then the command MUST be terminated with the trailer Un-
supportedFunction.
(N910.00)
(N911.00)
If and only if affectedObject.keyAvailable has the value False, then the command
MUST be terminated with the trailer KeyInvalid.
(N912.00)
The signature signature is calculated as follows:
If channelContext.keyReferenceList.signatureCreation.algID has the value
a. sign9796_2_DS2, then it MUST apply
i. signInput9796_2_DS2 = plainDO || hashDO.
ii. plainDO = 80 L80 M1.
iii. hashDO = 90 L90 hashM2.
iv. signature = RSA_ISO9796_2_DS2_SIGN(
affectedObject.privateRsaKey,
M1,
hashM2,
)
b. signPKCS1_V1_5, then it applies:
signature = RSASSA_PCKS1_V1_5_SIGN(
dataToBeSigned
)
c. rsaClientAuthentication or signPSS, then it applies
signature = RSASSA_PSS_SIGN(
dataToBeSigned
)
d. signECDSA, then it applies
signature = R || S, with
( R, S ) = ELC_SIG(affectedObject.privateElcKey, dataToBeSigned)
(N913.00)
As data field of the response message signature MUST be used.
(N914.00)
(N915.00)
Note: If the requirement of (N899.00)a is fulfilled for the operation in (N912.00)b, then it is not possible
that in (N32.00)a the error DigestInfoTooLong is returned. Therefore this error is not relevant for
this document.

14.8.2 PSO: COMPUTE CRYPTOGRAPHIC CHECKSUM
The command PSO: COMPUTE CC calculates a cryptographic checksum by applying a

symmetric key on given data. The algorithm to secure a command which has to be used is
described in Clause 13.2. In doing so the SMC executes the steps according to (N353.00)
and (N354.00)a.iii. The symmetric key is agreed during a mutual authentication (see Clause
15.4 and Clause 15.6). The data protected by the checksum are contained as parameters in
the command.
(N916.00)
All normative requirements of Clause 14.8.2 and sub-Clauses MUST apply for the
SMC-A and SMC-B.
14.8.2.1 Use Case Computing a Cryptographic Checksum
In this variant of PSO: COMPUTE CC the command APDU includes two parameters.
(N917.00)
The parameter data contains the data to be protected. The parameter data is an octet
string of any content. The parameter data corresponds to the MACin in (N354.00)a.iii.
The length of data is subject only to the restrictions described in Clause 11.5.5.
(N918.00)
of length MUST be in the range defined in Clause 11.5.6.
(N919.00)
A Case 4 command APDU according to Clause 11.7.4.1 MUST be sent via interpreter
interface. For the construction of this case 4 command APDU the instructions of Table
132 (N919.40) MUST be used.
Table 132: (N919.40) PSO: COMPUTE CC, Computing a cryptographic checksum
Content Description
P1 8E Description of response data, here: cryptographic checksum
P2 80 Description of command data, here: plaintext
Data XXYY data
Ne length Number of octets expected in the response data
14.8.2.2 Response of the Card to Computing a Cryptographic Checksum

Table 133: (N919.50) PSO: COMPUTE CC Response APDU in Case of Success

XXYY mac Cryptographic checksum
90 00 NoError Calculation of MAC successful

Table 134: (N919.60) PSO: COMPUTE CC Response APDU in Case of Error

69 85 NoKeyReference No key selected for MAC computation
6A 88 KeyNotFound No key available for MAC computation
6A 81 UnsupportedFunction Key does not the support the specified algorithm
69 82 SecurityStatusNotSatisfied Access rule not satisfied
(N920.00)
14.8.2.3 Command Processing inside the smartcard

(N921.00)
The COS MUST support the variant of PSO: COMPUTE CC described in Clause
14.8.2.1
The COS MAY support further PSO: COMPUTE CC variants.
The COS MAY refuse further PSO: COMPUTE CC variants.
(N922.00)
If and only if channelContext.keyReferenceList.macCalculation is
a. empty, then the command MUST terminate with the trailer NoKeyReference.
b. not empty, then affectedObject = SearchKey(
currentFolder,
channelContext.keyReferenceList.macCalculation.keyReference,
channelContext.keyReferenceList.macCalculation.algID
) is set. According to Clause 9.2.3 as well as (N1136.00) it MAY occur that the key
search is not successful. If the key search returns the error
i. keyNotFound, then and only then the command MUST terminate with the
trailer KeyNotFound.
ii. notSupported, then and only then the command MUST terminate with the
trailer UnsupportedFunction.
(N923.00)
If AccessRuleEvaluation( affectedObject, CLA, INS, P1, P2 ) returns the value False,
then and only then the command MUST terminate with the trailer SecurityStatus-
NotSatisfied.
(N924.00)
The following applies to the attributes SSCmac and Kmac of the attribute Sessionkey-
Context related to the current channelContext of the logical channel (data and mac cor-
respond to MACin and MAC in (N354.00)a.iii:
a. SSCmac = SSCmac + 1.
b. mac = CALCULATE_Retail_MAC( Kmac, I2OS( SSCmac, 8) || data ).
(N925.00)
mac MUST be used as data field of the response message.
(N926.00)
(N927.00)
For the priorities of the trailer the following applies:
a. The priorities of trailer in Table 134 (N919.60) are manufacturer-specific.
14.8.3 PSO: DECIPHER
The command PSO: DECIPHER deciphers data using a private asymmetric or symmetric
key. The data to be decrypted are part of the command message as a parameter.
14.8.3.1 Use Case Decryption, RSA, G1 (normative)
This variant applies for the following algorithms (see (N191.00)): rsaDecipherPKCS1_V1_5,
rsaDecipherOaep. The private key and the algorithm to be used are selected prior to the de-
cryption operation. This is done by sending a command MSE: SET before PSO: DECIPHER
is sent, see Clause 14.9.6.9.
In this variant the APDU of the command PSO: DECIPHER contains two parameters:
(N928.00)
The parameter C contains the data to be decrypted. The parameter C is an octet string
of any content. The number of octets in C MUST be equal to OctetLength( n ) with n as
modulus of the key which is used for the decyphering operation.
(N929.00)
ued of length MUST be chosen from the range defined in Clause 11.5.6
(N930.00)
Table 135: (N930.50) PSO: DECIPHER, Decryption with RSA
Content Description
P1 80 Description of the response data, here plaintext
P2 86 Description of the command data, here cipher text
Data XXYY 00 || C, Meaning: PaddingIndicator || Cryptogram
14.8.3.2 Use Case Decryption using 3TDES (normative)

(N931.00)
All normative requirements of the sub-clause 14.8.3.2 MUST apply for the SMC-A and
SMC-B.
This variant applies to the following algorithm: desSessionkey4TC. The algorithm to be used
for the de-securing of the message is described in Clause 13.3.
In this variant the APDU of the command PSO: DECIPHER contains two parameters
(N932.00)
The parameter C contains the data to be deciphered. The parameter C is an octet
string of any content. The relation between the response APDU on one side and C on
the other side is described in (N369.00)a and (N363.00)d. The parameter C corre-
sponds to C in (N363.00)b. The number of octets in C MUST be an integral multiple of
eight.
(N933.00)
(N934.00)
A Case 4 command APDU according to Clause 11.7.4 MUST be sent via interpreter in-
terface. The information given in Table 136 (N934.50) MUST be used for the construc-
tion of this Case 4 command APDU.
Table 136: (N934.50) PSO: DECIPHER, Decryption using DES
Content Description
P1 80 Description of response data, here: plaintext
P2 86 Description of command data, here: cryptogram
Data XXYY 01 || C = padding indicator || cryptogram
14.8.3.3 Use Case Decryption with ELC, G2 (informative)
This variant applies for the following algorithm (see (N191.00)): elcSharedSecretCalculation.
In this variant the APDU of the command PSO: DECIPHER contains four parameters:
(N935.00)
The parameter POA contains a point on an elliptical curve.This point was selected by
the sender of the message. The parameter POA is an octet string, whose content
SHOULD be chosen so that no error occurs during decoding, see (N48.00)a.
(N936.00)
The parameter C contains the data to be decrypted. The parameter C is an octet string
of any content.
(N937.00)
The parameter T contains a MAC, which protects the integrity of C. The parameter T is
an octet string whose content SHOULD be chosen so that no error occurs during the
verification of the MAC.
(N938.00)
ued of length MUST be chosen from the range defined in Clause 11.5.6.
(N939.00)
The parameters POA, C and T MUST be part of the data field of the command mes-
sage. The coding is specified in (N945.00)c.
(N940.00)

Table 137: (N940.40) PSO: DECIPHER, Decryption with elliptic curves
Content Description
P1 80 Description of the response data, here plaintext
P2 86 Description of the command data, here cipher text
Data XXYY cipher
Note: P2 will possibly be changed in a later version of this document.
14.8.3.4 Response of the smartcard to the decryption of data

Table 138: (N940.50) PSO: DECIPHER Response APDU in case of success

XXYY plain plaintext
90 00 NoError Decryption operation successful
Table 139: (N940.60) PSO: DECIPHER Response APDU in case of failure

69 85 NoKeyReference No key selected for the decryption
6A 80 WrongCiphertext Error during decryption of the cryptogram
(N941.00)

(N942.00)
The COS MUST support the variant PSO: DECIPHER from 14.8.3.1 and 14.8.3.2.
The COS MAY support additional variants for PSO: DECIPHER.
The COS MAY refuse additional variants for PSO: DECIPHER.
(N943.00)
If and only if channelContext.keyReferenceList.dataDecipher
a. is empty, then the command MUST terminate with the trailer NoKeyReference
currentFolder,
channelContext.keyReferenceList.dataDecipher.keyReference,
channelContext.keyReferenceList.dataDecipher.algID
) will be set. According to Clause 9.2.3 and according to (N1136.00) it MAY happen,
that the search for a key is not successful. If the search for a key returns the error
NotFound.

supportedFunction.
(N944.00)
(N945.00)
The plaintext message plain is calculated as follows:
If channelContext.keyReferenceList.dataDecipher.algID has the value
a. rsaDecipherPKCS1_V1_5, then it applies
plain = RSAES_PKCS1_V1_5_DECRYPT( affectedObject.privateRsaKey, C )
b. rsaDecipherOaep, then it applies
plain = RSAES_OAEP_DECRYPT( affectedObject.privateRsaKey, C )
c. elcSharedSecretCalculation, then it applies
i. cipher = A6 LA6 ( keyDO || cipherDO || macDO ).
ii. keyDO = 7F49 L7F49 ( 86 L86 POA ).
iii. cipherDO = 86 L86 02 || C.
iv. macDO = 8E L8E T.
Note: in this case cipher is defined identical to (N965.00)b and (N1002.00)c.

v. plain = ELC_DEC( POA, affectedObject.privateElcKey, C, T ).
d. desSessionkey4TC, then the following applies to the attributes SSCenc and Kenc of
the attribute SessionkeyContext related to the current channelContext of the logical
channel, whereas the parameter C and plain comply with C and Data in (N363.00)b.
i. Step 1: SSCenc = SSCenc + 1.
ii. Step 2: P = 3TDES_CBC_DEC( Kenc, SSCenc, C ).
iii. Step 3: plain = TruncateIso( P, 8 ).
(N946.00)
If and only if one of the operations in (N945.00) terminates with an error, then the
command MUST terminate with the trailer WrongCiphertext.
(N947.00)
As data field of the response message plain MUST be used.
(N948.00)
(N949.00)
14.8.4 PSO: ENCIPHER (normative)
The command PSO: ENCIPHER enciphers data using a public asymmetric key or a symmet-
ric key. The public key and the data to be enciphered are part of the command message as a
parameter.

(N950.00)
All normative requirements of Clause 14.8.4 and its sub-clauses MUST apply for the
SMC-A and SMC-B.
14.8.4.1 Use Case Encryption of data with 3TDES, G1 (normativ)
This variant applies to the following algorithm: desSessionkey4TC. The algorithm to secure a
command which has to be used is described in Clause 13.2. In doing so the SMC executes
the steps according to (N348.00)a and (N348.00)b.
In this variant the APDU of the command PSO: ENCIPHER contains two parameters
(N951.00)
The parameter M contains the data to be enciphered. The parameter M is an octet
string of any content. M complies with Data in (N348.00)b.The length of M is subject
only to the restrictions defined in Clause 11.5.5.
(N952.00)
(N953.00)
Table 140: (N953.50) PSO: ENCIPHER, Enciphering using DES
Content Description
P1 86 Description of response data, here: cryptogram
P2 80 Description of command data, here: plaintext
Data XXYY M
14.8.4.2 Use Case Encryption of data with ELC, G2 (informative)
In this variant the APDU of the command PSO: ENCIPHER contains five parameters:
(N954.00)
The parameter algID contains information about the algorithm to be used for the en-
cryption. The parameter algID MUST be chosen from the set (to be defined for gen-
eration 2).
(N955.00)
The parameter oid contains an object identifier referencing the used elliptical curve.
The parameter oid is an octet string, whose length and content SHOULD be chosen so
that a curve is referenced which is stored in the smartcard.
(N956.00)
The parameter POB contains a point on an elliptical curve. This point represents the
public key of the receiver. The parameter POB is an octet string whose length and con-
tent SHOULD be chosen so that no error occurs during the decoding, see (N48.00)a.
(N957.00)
The parameter M contains the data to be encrypted. The parameter M is an octet string
with any content.

(N958.00)
(N959.00)
The parameters POB, oid and M MUST be part of the data field of the command mes-
sage. The coding is specified in (N965.00)b.
(N960.00)
Table 141: (N960.40) PSO: ENCIPHER, encryption of data
Content Description
P1 86 Description of the response data, here cipher text
P2 80 Description of the command data, here plaintext
Data XXYY plain
Note: P1 will possibly be changed in a later version of this document.
14.8.4.3 Response of the smartcard to the encryption of data

Table 142: (N960.50) PSO: ENCIPHER Response APDU in case of success

XXYY cipher Cipher text
90 00 NoError Encryption operation successful
Table 143: (N960.60) PSO: ENCIPHER Response APDU in case of failure

64 00 CurveNotFound Referenced curve not found
64 00 EncipherError Error during encryption of the plaintext
69 85 NoKeyReference No key selected for the decryption operation
(N961.00)

(N962.00)
The COS MUST support the variants for PSO: ENCIPHER from Clause 14.8.4.1
The COS MAY support additional variants for PSO: ENCIPHER.
The COS MAY refuse additional variants for PSO: ENCIPHER.
(N963.00)
If channelContext.keyReferenceList.dataDecipher
a. Is empty, then and only then the command MUST terminate with the trailer
NoKeyReference.
b. Is not empty, then affectedObject = SearchKey(
currentFolder,
) is set. According to Clause 9.2.3 and according to (N1136.00) it MAY happen, that
the search for a key is not successful. If the search for a key returns the error
NotFound.
supportedFunction.
(N964.00)
then and only then the command MUST terminate with the trailer SecurityStatus-
NotSatisfied.
(N965.00)
The cipher text cipher will be calculated as follows:
a. desSessionkey4TC, then it applies with the attributes SSCenc and Kenc from the at-
tribute SessionkeyContext of the current channel context of the logical channel
(whereas M and C comply with Data resp. C in (N348.00)b:
i. Step 1: SSCenc = SSCenc + 1.
ii. Step 2: P = PaddingIso( M, 8 ).
iii. Step 3: C = 3TDES_CBC_ENC( Kenc, SSCenc, P ).
iv. Step 4: cipher = 01 || C.
b. (G2, informative) elcSharedSecretCalculation, then the data field of the command
message MUST be divided as follows:
i. plain = algDO || plainDO.
ii. algDO = 80 01 algID
iii. plainDO = A0 LA0 (oidDO || keyDO || mDO ).
iv. oidDO = 06 L06 oid .
v. keyDO = 7F49 L7F49 ( 86 L86 POB ).
vi. mDO = 80 L80 M.
vii. It will be searched in the attribute domainParameterList (see (N210.00)g) for a
list element, whose attribute OID is identical to oid from the command mes-
sage. If and only if such a list element
1. does not exist, then the command MUST terminate with the trailer
CurveNotFound.
2. exists, then the domain parameters being part of it will be named as dP in
the following part.
viii. ( POA, C, T ) = ELC_ENC( M, POB, dP )
If and only if this function terminates with the error ERROR, then the com-
mand MUST terminate with the trailer EncipherError. Otherwise a DER TLV
coded octet string cipher will be built:
Note: in this case cipher is defined in an identical way to (N945.00)c and (N1002.00)c.
ix. Set keyDO = 7F49 L7F49 ( 86 L86 POA ).
x. Set cipherDO = 86 L86 02 || C.
xi. Set macDO = 8E L8E T.
xii. Set cipher = A6 LA6 ( keyDO || cipherDO || macDO ).
(N966.00)
As data field of the response message cipher MUST be used.
(N967.00)
(N968.00)
14.8.5 PSO: VERIFY CRYPTOGRAPHIC CHECKSUM
The command PSO: VERIFY CC by using a symmetric key checks, whether a given crypto-
graphic checksum matches the given data. The algorithm to be used to verify a response
APDU is described in Clause 13.3. The symmetric key is agreed during a mutual authentica-
tion procedure (see Clause 15.4 and Clause 15.6). The checksum and the protected data are
contained as parameters in the command message.
(N969.00)
All normative requirements of Clause 14.8.5 and its sub-clauses MUST apply to SMC-
A and SMC-B.
14.8.5.1 Use Case Verifying a Cryptographic Checksum
In this variant the APDU of the command PSO: VERIFY CC contains two parameters:
(N970.00)
The parameter data contains the protected data. The parameter data is an octet string
of any content.
(N971.00)
The parameter mac contains a cryptographic checksum. The parameter mac is an oc-
tet string of any content whose length MUST NOT exceed the block length of the sym-
metric algorithm.
(N972.00)
The parameters data and mac MUST be contained in the data field of the command
message. The encoding is defined in (N978.00).
(N973.00)

Table 144: PSO: (N973.40) VERIFY CC, Verifying a Cryptographic Checksum
Content Description
P1 00 Description of response data, here: no response data
P2 A2 Description of command data, here: input template for MAC
Data XXYY inputTemplate
14.8.5.2 Card Response to Verifying a Cryptographic Checksum

Table 145: (N973.50) PSO: VERIFY CC Response in case of Success

90 00 NoError successful verification of a MAC
Table 146: (N973.60) PSO: VERIFY CC Response APDU in case of Error

69 85 NoKeyReference no key for MAC computation selected
6A 88 KeyNotFound no key for MAC computation available
6A 81 UnsupportedFunction key does not support the specified algorithm
69 82 SecurityStatusNotSatisfied access rule not satisfied
6A 80 VerificationError MAC verification failed
SecMes from Figure 1(N270.50).
(N974.00)
A COS MAY use additional trailer
14.8.5.3 Command Processing inside the Card

(N975.00)
The COS MUST support the PSO: VERIFY CC variant of 14.8.5.1.
The COS MAY support further PSO: VERIFY CC variants.
The COS MAY refuse further PSO: VERIFY CC variants.
(N976.00)
If channelContext.keyReferenceList.macCalculation is
a. empty, then and only then the command MUST terminate with the trailer
NoKeyReference.
currentFolder,
) is set. According to Clause 9.2.3 and according to (N1136.00) it MAY occur that
the key search is not successful. If the key search returns the error
i. keyNotFound, then and only then the command MUST terminate with the
trailer KeyNotFound.
ii. notSupported, then and only then the command MUST terminate with the
trailer UnsupportedFunction.

(N977.00)
then and only then the command MUST terminate with the trailer SecurityStatusNot-
Satisfied.
(N978.00)
It applies:
a. inputTemplate = '80 L80 data || 8E L8E mac'
(N979.00)
the following applies to the attributes SSCmac and Kmac of the attribute Sessionkey-
Context related to the current channelContext of the logical channel whereas the rela-
tion between the response APDU on one side and MACin and MAC on the other side
complies with (N369.00)a, (N367.00)a and (N368.00). data and mac comply with
MACin and MAC in (N367.00)a.iv:
a. SSCmac = SSCmac + 1.
b. result = VERIFY_Retail_MAC(Kmac, mac, I2OS( SSCmac, 8) || data ).
(N980.00)
If result has the value
a. INVALID, then and only then the trailer VerificationError MUST be used.
b. VALID, then and only then the trailer NoError MUST be used.
(N981.00)
a. The priorities of the trailer in Table 146 (N973.60) is manufacturer-specific
14.8.6 PSO: HASH
(N982.00)
14.8.7 PSO: TRANSCIPHER
The command PSO: TRANSCIPHER combines the commands PSO: DECIPHER and PSO:
ENCIPHER without the need for the plaintext to leave the smartcard. The data will be de-
crypted with a private key and will be encrypted immediately after. The private key and the
algorithm to be used are selected prior to the decryption operation. This is done by sending a
command MSE: SET before the command PSO: TRANSCIPHER is sent, see Clause
14.9.6.9. The data to be transciphered and the public key of the receiver are part of the
command message as a parameter.
14.8.7.1 Use Case Transcipher of data with RSA key, G1 (normative)
This variant applies for the following algorithms (see (N191.00)): rsaDecipherPKCS1_V1_5,
rsaDecipherOaep.
In this variant the APDU of the command PSO: TRANSCIPHER contains four parameters

(N983.00)
The parameter C contains the data to be transciphered. The parameter C is an octet
string of any content.
(N984.00)
The parameter PuK contains the public key of the receiver according to Clause 8.2.4.1.
The parameter PuK is an octet string whose content MUST be chosen so that no error
occurs during decoding, see (N1004.00)a.iii.
(N985.00)
The parameter algID_enc contains information about the algorithm to be used for the
encryption. The value for algID_enc MUST be chosen from the set {rsaEnci-
pherPKCS1_V1_5, rsaEncipherOaep} .
(N986.00)
(N987.00)
The parameters C, PuK and algID_enc MUST be part of the data field of the command
message. The coding is specified in (N1001.00), (N1002.00) and (N1004.00).
(N988.00)
Table 147: (N988.50) PSO: TRANSCIPHER, transcipher of data with RSA
Content Description
P2 B8 Description of the command data, here CRT for encryption
Data XXYY cipherIN
14.8.7.2 Use Case Transcipher of data with ELC, G2 (informative)
This variant applies for the following algorithm (see (N191.00)): elcSharedSecretCalculation.
In this variant the APDU of the command PSO: TRANSCIPHER contains six parameters:
(N989.00)
The parameter POA contains a point on an elliptical curve.This point was selected by
the sender of the message. The parameter POA is an octet string, whose content
SHOULD be chosen so that no error occurs during decoding, see (N48.00)a.
(N990.00) The parameter C contains the data to be transciphered. The parameter C is an
octet string of any content.
(N991.00)
The parameter T contains a MAC, which protects the integrity of C. The parameter T is
an octet string whose length and content SHOULD be chosen so that no error occurs
during the verification of the MAC.
(N992.00)
The parameter POB contains a point on an elliptical curve. This point represents the
public key of the receiver. The parameter POB is an octet string whose content
SHOULD be chosen so that no error occurs during the decoding, see (N48.00)a
(N993.00)
The parameter algID_enc contains information about the algorithm to be used for the
encryption. A value of the set { elcSharedSecretCalculation} MUST be used.
(N994.00)
(N995.00)
The parameters POA, POB, C, T and algID_enc MUST be part of the data field of the
command message. The coding is specified in (N1001.00), (N1002.00)c and
(N1004.00)c.
(N996.00)
Table 148: (N996.40) PSO: TRANSCIPHER, transcipher of data with ELC
Content Description
P2 86 Description of the command data, here also cipher text
Data XXYY cipherIN
Note 1: it will be interesting if RSA and ELC keys will be mixed for transcipher. That is something for
the future.
Note 2: Possibly P1 and P2 will be changed in a later version of this document.
14.8.7.3 Response of the smartcard to the transcipher of data

Table 149: (N996.50) PSO: TRANSCIPHER Response APDU in case of success

XXYY cipherOUT cipher text
90 00 NoError Transcipher successful
Table 150: (N996.60) PSO: TRANSCIPHER Response APDU in case of failure

69 85 NoKeyReference Key for decryption not selected
6A 88 KeyNotFound Key for decryption not found
6A 80 WrongCiphertext Error during decryption of the cryptogram

(N997.00)

(N998.00)
The COS MUST support the variant PSO: TRANSCIPHER from 14.8.7.1.
The COS MAY support additional variants for PSO: TRANSCIPHER.
The COS MAY refuse additional variants for PSO: TRANSCIPHER.
(N999.00)
If and only if channelContext.keyReferenceList.dataDecipher
a. is empty, then the command MUST terminate with the trailer NoKeyReference
b. is not empty, then affectedObject is set equal to the key being named SearchKey(
currentFolder,
). According to Clause 9.2.3.1 and according to (N1136.00) it MAY happen, that the
search for a key is not successful. If the search for a key returns the error
NotFound.
supportedFunction.
(N1000.00)
(N1001.00)
The command data will be divided as follows:
a. cipherIN = cipher || plainDO.
b. cipher MUST be a DO with tag = A6 sein.
c. plainDO MUST be a DO with tag = A0 sein.
(N1002.00)
The plaintext is calculated as follows:
a. rsaDecipherPKCS1_V1_5, then it applies:
i. cipher = A6 LA6 ( cipherDOin ).
ii. cipherDOin = 86 L86 00 || Cin.
iii. M = RSAES_PKCS1_V1_5_DECRYPT(
Cin
).
mand MUST terminate with the trailer WrongCiphertext.
b. rsaDecipherOaep, then it applies:
i. cipher = A6 LA6 ( cipherDOin ).
ii. cipherDOin = 86 L86 00 || Cin.

iii. M = RSAES_OAEP_DECRYPT(affectedObject.privateRsaKey, Cin).
c. elcSharedSecretCalculation, then it applies:
i. cipher = A6 LA6 ( keyDOA || cipherDOin || macDOin ).
ii. keyDOA = 7F49 L7F49 ( 86 L86 POA ).
iii. cipherDOin = 86 L86 02 || Cin.
iv. macDOin = 8E L8E Tin.
Note: In this case cipher is defined in an identical way to (N945.00)c and (N965.00)b.
v. M = ELC_DEC( POA, affectedObject.privateElcKey, Cin, Tin ).
(N1003.00)
Search in plainDO for a DO with the tag = 80. This DO MUST have the length one.
Then it applies algID_enc = value field of the DO with tag = 80.
(N1004.00)
The cipher text cipherOUT will be calculated from M as follows:
If algID_enc has the value
a. rsaEncipherPKCS1_V1_5, then it applies:
i. plainDO = A0 LA0 ( algDO || keyDO ).
ii. algDO = 80 01 || algID_enc.
iii. keyDO = 7F49 L7F49 [(81 L81 PuK.n) || (82 L82 PuK.e)].
iv. cipherOUT = 00 || RSAES_PKCS1_V1_5_ENCRYPT(PuK, M ).
b. rsaEncipherOaep, then it applies:
i. plainDO = A0 LA0 ( algDO || keyDO ).
iii. keyDO = 7F49 L7F49 [(81 L81 PuK.n) || (82 L82 PuK.e)].
iv. cipherOUT = 00 || RSAES_OAEP_ENCRYPT( PuK, M ).
c. elcSharedSecretCalculation, then it applies:
i. plainDO = A0 LA0 ( algDO || keyDOB ).
iii. keyDOB = 7F49 L7F49 ( 86 L86 POB ).
iv. ( POout, Cout, Tout ) = ELC_ENC(
M,
POB,
affectedObject.privateElcKey.domainParameter
)
mand MUST terminate with the trailer WrongCiphertext. Otherwise a DER TLV
coded octet string cipherOUT is built as follows:
Note: cipherOUT is defined in an identical way to (N965.00)b.

v. Set keyDOout = 7F49 L7F49 ( 86 L86 POout ).
vi. Set cipherDOout = 86 L86 02 || Cout.
vii. Set macDOout = 8E L8E Tout.
viii. cipherOUT = A6 LA6 ( keyDOout || cipherDOout || macDOout ).
(N1005.00)
As data field of the response message cipherOUT MUST be used.
(N1006.00)
(N1007.00)
14.8.8 PSO: VERIFY CERTIFICATE
The command PSO: VERIFY CERTIFICATE verifies the signature of a certificate using a
public key. The public key is selected prior to the verification operation. This is done by send-
ing a command MSE: SET before PSO: VERIFY CERTIFICATE is sent, see Clause 14.9.6.8.
The certificate is part of the command message as a parameter. If the signature of the certifi-
cate is regarded as valid, then certain attributes of the key object being part of the certificate
will be stored for a later usage.
14.8.8.1 Use Case Import of a RSA key with a certificate, G1 (normative)
In this variant the APDU of the command PSO: VERIFY CERTIFICATE contains two pa-
rameters:
(N1008.00)
The parameter certificateContent contains attribute information for the key object.
(N1009.00)
The parameter signature contains the signature over the attribute information, created
by a CA.
(N1010.00)
The parameters certificateContent and signature MUST be part of the data field of the
command message. The coding is specified in (N1019.00)a.
(N1011.00)

Table 151: (N1011.50) PSO: VERIFY CERTIFICATE for RSA keys
Content Description
P1 00 no response data
P2 AE Command data with template; the value fields are certified
Data XXYY certificate
14.8.8.2 Use Case Import ELC keys with certificate, G2 (informative)
In this variant the APDU of the command PSO: VERIFY CERTIFICATE contains two pa-
rameters:
(N1012.00)
The parameter certificateContent contains all attributes for the key object.
(N1013.00)
The parameter signature contains the signature over the attributes, created by a CA.
(N1014.00)
The parameters certificateContent and signature MUST be part of the data field of the
command message. The coding is specified in (N1019.00)b.
(N1015.00)
Table 152: (N1015.40) PSO: VERIFY CERTIFICATE for ELC keys
Content Description
P1 00 no response data
P2 BE Command data with certified template
Data XXYY certificate
14.8.8.3 Response of the smartcard to the comparison of a user secret

Table 153: (N1015.50) PSO: VERIFY CERTIFICATE Response APDU in case of success

90 00 NoError Certificate validation successful

Table 154: (N1015.60) PSO: VERIFY CERTIFICATE Response APDU in case of failure

69 85 NoKeyReference No key for signature validation selected
6A 88 KeyNotFound key for signature validation not found
6A 80 VerificationError Validation of certificate failed
6A 88 InconsistentKeyReference Reference for key for signature validation different from
the CAR of the certificate
(N1016.00)

(N1017.00)
The COS MUST support the variant for PSO: VERIFY CERTIFICATE from 14.8.8.1.
The COS MAY support additional variants for PSO: VERIFY CERTIFICATE.
The COS MAY refuse additional variants for PSO: VERIFY CERTIFICATE.
(N1018.00)
If and only if channelContext.keyReferenceList.verifyCertificate
currentFolder
channelContext.keyReferenceList.verifyCertificate.keyReference,
verifyCertificate
) is set. According to Clause 9.2.3.2 and according to (N1136.00) it MAY happen,
that the search for a key is not successful. Then the command MUST terminate with
the trailer KeyNotFound.
(N1019.00)
a. publicRsaKey, then it applies:
i. certificate = 5F37 L5F37 signature || 5F38 L5F38 certificateContent.
ii. ( out, M ) = RSA_ISO9796_2_DS1_VERIFY(
affectedObject.publicRsaKey,
signature,
certificateContent
)
command MUST terminate with the trailer VerificationError.
iii. The key attributes are extracted from the message M according to
Clause 7.1.2 and a public key object pukObj is built.
iv. IF CPI is equal to 21, then pukObj MUST be a public signature validation ob-
ject (see Clause 8.5.4.1), whose attributes have to be set as follows (accord-
ing to the definitions of Clause 7.1.2.1):
1. pukObj.oid = OID.

2. pukObj.publicKey.n = modulus.
3. pukObj.publicKey.e = public exponent.
4. pukObj.keyIdentifier = CHR.
v. IF CPI is equal to 22, then pukObj MUST be a public authentication object
(see Clause 8.5.4.2), whose attributes have to be set as follows (according to
the definitions of Clause 7.1.2.2): 7.1.2.2
1. pukObj.CHA = CHA.
2. pukObj.oid = OID.
3. pukObj.publicKey.n = modulus.
4. pukObj.publicKey.e = public exponent.
5. pukObj.keyIdentifier = CHR.
vi. If and only if affectedObject.keyIdentifier is not equal to CAR, then the com-
mand MUST terminate with the trailer InconsistentKeyReference.
vii. The object pukObj SHOULD be stored in the list persistentPublicKeyList of the
object system.
viii. The object pukObj MAY be stored in the list publicKeyList of the object sys-
tem.
ix. The object pukObj MUST be stored together with a reference to currentFolder
in the respective list.
b. publicElcKey, then (to be completed for generation 2)
(N1020.00)
(N1021.00)
used as trailer.
(N1022.00)
(N1023.00)
b. Each trailer in Table 154 (N1015.60) MUST have a higher priority than UpdateRe-
tryWarning.
14.9 Miscellaneous
14.9.1 ENVELOPE
The optional command ENVELOPE supports a Trusted Channel by generating Secure Mes-
saging data objects for secured commands and by processing Secure Messaging data ob-
jects for secured responses. Thus ENVELOPE is possibly a more efficient alternative to the
commands PSO: COMPUTE CC (see Clause 14.8.2) and PSO: ENCIPHER (see Clause
14.8.4) for the generation of data objects and PSO: DECIPHER (see Clause 14.8.3) and

PSO: VERIFY CC (see Clause 14.8.5) for the processing of data objects by using Secure
Messaging keys.
For the generation of Secure Messaging DOs for secured commands the command ENVE-
LOPE calculates a cryptographic checksum to given data with the help of a symmetric key
and additionally (if indicated in the command message) a cryptogram. The algorithm to be
used to secure a command is defined in Clause 13.2.
For the processing of Secure Messaging DOs in secured responses the command ENVE-
LOPE checks by using a symmetric key whether a given cryptographic checksum matches
with the given data and additionally deciphers (if indicated in the command message) the
secured data. The algorithm to be used to verify and decipher a response APDU is defined in
Clause 13.3.
In both cases the symmetric key is negotiated in the context of a mutual authentication (see
Clause 15.4 and Clause 15.6). The data to be protected resp. checksum and protected data
are part of the command message as parameters.
(N1024.00)
All normative requirements of Clause 14.9.1 and its sub-clauses MUST apply for the
SMC-A and SMC-B, if the command ENVELOPE is supported.
14.9.1.1 Use Case Generation of Secure Messaging DOs for secured commands
In this variant the APDU of the command ENVELOPE contains three parameters:
(N1025.00)
The parameter commandData contains the data to be protected and possibly to be en-
ciphered. The parameter commandData MUST be an octet string with the content of a
command APDU according to Clause 11.5. The length of commandData is only limited
by the restrictions of Clause 11.5.5.
(N1026.00)
The parameter responseDescriptor contains information which data objects are ex-
pected in the response message. The parameter responseDescriptor MUST be em-
bedded in a Response Descriptor Template according to [ISO7816-4] Clause 6.3.4.
(N1027.00)
If the command ENVELOPE shall calculate a checksum and return it in the response
message, then the parameter responseDescriptor MUST be coded as an empty
checksum with the value of 8E 00.
(N1028.00)
If the command ENVELOPE shall calculate a cryptogram and a checksum and return
both in the response message, then the parameter responseDescriptor MUST be
coded as empty data objects cryptogram and checksum with the values of 87 00 ||
8E 00.
(N1029.00)
The parameter commandData and responseDescriptor MUST be part of inputTemplate
in the data field of the command message. It MUST apply
a. inputTemplate =
52 L52 commandData || 7D L7D (BA LBA responseDescriptor)'
(N1030.00)
(N1031.00)

Table 155: (N1031.50) ENVELOPE, Generation of Secure Messaging Data Objects
Content Description
INS C3 Instruction Byte according to [ISO7816-4]
P1 00
P2 00
Data XXYY inputTemplate: DO Command APDU and Secure Messaging Template
with Response Descriptor Template according to [ISO7816-4]
14.9.1.2 Use Case Processing of Secure Messaging DOs with secured response data
In this variant the APDU of the command ENVELOPE contains one or three parameter:
(N1032.00)
The parameter responseData contains protected data which are possibly also enci-
phered. The parameter responseData MUST be an octet string with the content of a
secured response APDU according to Clause 11.6 and Clause 13.3.
(N1033.00)
The optional parameter responseDescriptor contains the information that the command
ENVELOPE shall decipher a cryptogram and return the plaintext in the response mes-
sage; it MUST be coded as an empty DO plaintext with the value of 80 00.
(N1034.00)
The parameter responseData MUST be present in inputTemplate in the data field of
the command message. The parameter responseDescriptor MAY be present. It MUST
apply:
a. inputTemplate = 7D L7D responseData, or
b. inputTemplate = 7D L7D (responseData || BA LBA responseDescriptor).
(N1035.00)
The optional parameter length
a. MUST be present if the parameter responseDescriptor is present.
b. MUST NOT be present if the parameter responseDescriptor is not present.
(N1036.00)
(N1037.00)
If the parameter length is
a. present, then a case 4 command APDU MUST be sent via the interface Interpreter
of Figure 1 (N270.50), according to Clause 11.7.4.1.
b. not present, then a case 3 command APDU MUST be sent via the interface Inter-
preter of Figure 1 (N270.50), according to Clause 11.7.3.1.
(N1038.00)
For the construction of this case 4 or case 3 command APDU the instructions of Table
156 (N1038.40) MUST be used.

Table 156: (N1038.40) ENVELOPE, Processing of Secure Messaging Data Objects
Content Description
INS C3 Instruction Byte according to [ISO7816-4]
P1 00
P2 00
Data XXYY inputTemplate: Secure Messaging Template with or without Response
Descriptor Template according to [ISO7816-4]
Ne length Expected number of octets in the response data (conditional, see
(N1037.00), depending on the presence of a Response Descriptor Tem-
plate in inputTemplate)
14.9.1.3 Response of the Smartcard to the Generation or Processing of Secure Messaging

DOs
Table 157: (N1038.50) ENVELOPE Response APDU in Case of Success

or Not present or smTem- Secure Messaging Template with checksum and per-
'XX..YY' plate haps cryptogram, or Secure Messaging Template with
plaintext; conditionally depending on the presence of a
Response Descriptor Template in the command mes-
sage
Trailer Content Descrption
90 00 NoError Calculation or Pocessing of DOs successful
Table 158: (N1038.60) ENVELOPE Response APDU in case of Failure

69 85 NoKeyReference No key selected
6A 88 KeyNotFound No key available
69 82 SecurityStatusNot Access rule not fulfilled
Satisfied
6A 80 WrongCiphertext Error during decryption oft the cryptogram
6A 80 VerificationError MAC verification has failed
(N1039.00)

(N1040.00)
The COS MAY support the variants of ENVELOPE from 14.9.1.1 and 14.9.1.2.
The COS MAY refuse the variants of ENVELOPE from 14.9.1.1 and 14.9.1.2.
The COS MAY support additional variants of ENVELOPE.
The COS MAY refuse additional variants of ENVELOPE.
(N1041.00)
If channelContext.keyReferenceList.macCalculation is

a. empty, then the command MUST terminate with the trailer NoKeyReference.
currentFolder,
) is set. According to Clause 9.2.3 and (N230.00) it MAY happen that the search for
the key is not successful. If the key search terminates with the error
Found.
ii. notSupported, then the command MUST terminate with the trailer Unsup-
portedFunction.
(N1042.00)
then the command MUST terminate with the trailer SecurityStatusNotSatisfied.
(N1043.00)
If inputTemplate has the content:
a. 52 L52 commandData || 7D L7D (BA LBA [8E 00],
then the command APDU MUST be executed as follows:
i. The mdo for the response message will be calculated according to Clause
13.2 (N346.00), (N347.00), (N350.00) up to (N355.00) with the attributes
SSCmac and Kmac from the attribute SessionkeyContext from the current
channelContext of the logical channel. The commandData contain the input
CLA, INS, P1, P2, Data (optional) and LeField (optional) of the command to be
protected. mdo corresponds to the MDO in (N355.00).
ii. As Data field of the response message MUST be used:
1. smTemplate = 7D L7D mdo
iii. NoError MUST be used as trailer.
b. 52 L52 commandData || 7D L7D (BA LBA [87 00 || 8E 00],
i. If channelContext.keyReferenceList.dataDecipher is
1. empty, then and only then the command MUST terminate with the trailer
NoKeyReference.
2. not empty, then the object affectedObject = SearchKey(
currentFolder,
) is set. According to Clause 9.2.3 and according to (N1136.00) it MAY
happen that the search for the key is not successful. If the key search ter-
minates with the error.
NotFound.
supportedFunction.
ii. If AccessRuleEvaluation( affectedObject, CLA, INS, P1, P2 ) returns False,
then the command MUST terminate with the trailer SecurityStatusNotSatisfied.
iii. protectedData for the response message according to Clause 13.2 will be cal-
culated according to (N346.00) up to (N348.00) with the attributes SSCenc
and Kenc from the attribute SessionkeyContext of the current channelContext
of the logical channel. commandData contains the input CLA, INS, P1, P2,
Data (optional) and LeField (optional) of the command to be protected and
protectedData corresponds to ProtectedData in (N346.00) or (N348.00)d.
iv. mac for the response message will be calculated according to Clause 13.2
(N350.00) up to (N355.00) with the attributes SSCmac and Kmac from the at-
tribute SessionkeyContext of the current channelContext of the logical chan-
nel. The value for protectedData calculated in (N1043.00)b.iii is used as an in-
put for (N354.00). mdo corresponds to MDO in (N355.00).
v. As data field for the response message MUST be used:
1. smTemplate = 7D L7D (protectedData || mdo)
vi. NoError MUST be used as trailer.
c. 7D L7D responseData,
then the command message MUST be processed as follows:
i. It applies: responseData = data || 8E L8E mac
ii. result will be calculated with the attributes SSCmac and Kmac from the attrib-
ute SessionkeyContext of the current channelContext of the logical channel as
follows (data and mac correspond to MACin and MAC in (N367.00)a.iv). The
correlation between the response message on the one hand and MACin and
MAC on the other hand is given in (N369.00)a, (N367.00)a and (N368.00).
1. SSCmac = SSCmac + 1.
2. result = VERIFY_Retail_MAC(Kmac, mac, I2OS( SSCmac, 8) || data ).
iii. If result has the value
1. INVALID, then VerificationError MUST be used as trailer
2. VALID NoError MUST be used as trailer.
d. 7D L7D (responseData || BA LBA [80 00]),
i. It applies: responseData = data || 8E L8E mac
ii. result will be calculated with the attributes SSCmac and Kmac from the attrib-
ute SessionkeyContext of the current channelContext of the logical channel
as follows (data and mac correspond to MACin and MAC in (N367.00)a.iv).
The correlation between the response APDU on the one hand and MACin and
MAC on the other hand is given in (N369.00)a, (N367.00)a and (N368.00):
1. SSCmac = SSCmac + 1.
2. result = VERIFY_Retail_MAC(Kmac, mac, I2OS( SSCmac, 8) || data ).
iii. If result has the value
1. INVALID, then the command MUST terminate with the trailer VerificationEr-
ror.
2. VALID, then plain for the response message MUST be calculated as fol-
lows:
iv. If channelContext.keyReferenceList.dataDecipher is
1. empty, then and only then the command MUST terminate with the trailer
NoKeyReference.

2. not empty, then affectedObject = SearchKey(
currentFolder,
) is set. According to Clause 9.2.3 and according to (N1136.00) it MAY
happen that the search for the key is not successful. If the key search ter-
minates with the error
NotFound.
supportedFunction.
v. If AccessRuleEvaluation( affectedObject, CLA, INS, P1, P2 ) returns the value
False, then the command MUST terminate with the trailer Security-
StatusNotSatisfied.
vi. It applies: data = 81 L81 cipher.
vii. plain will be calculated with the attributes SSCenc and Kenc from the attribute
SessionkeyContext of the current channelContext of the logical channel as fol-
lows (cipher and plain correspond to C and Data in (N363.00)b:
1. Step 1: SSCenc = SSCenc + 1.
2. Step 2: P = 3TDES_CBC_DEC( Kenc, SSCenc, cipher ).
3. Step 3: plain = TruncateIso( P, 8 ).
viii. If the function TruncateIso terminates with the error paddingError, then and
only then the command MUST terminate with the trailer WrongCiphertext.
ix. As data field in the response message MUST be used:
1. smTemplate = 7D L7D (80 L80 plain).
x. NoError MUST be used as trailer.
(N1044.00)
14.9.2 GENERATE ASYMMETRIC KEY PAIR
The command GENERATE ASYMMETRIC KEY PAIR (GAKP) is used to generate asymmet-
ric key pairs and to read a public key generated by the command. The respective key pair is
selected afore. This is done by a command MANAGE SECURITY ENVIRONMENT (see
Clause 14.9.6.7).
14.9.2.1 Use Case Key generation without returning a public key
In this variant the APDU of the command GAKP contains one parameter:
(N1045.00)
The parameter operationMode determines the operation to be performed. In this case
operationMode = 84 MUST be chosen.
(N1046.00)

Table 159: (N1046.50) GAKP, key generation without returning a public key
Content Description
P1 84 operationMode = key generation
P2 00
14.9.2.2 Use Case Returning a public key generated before
In this variant the APDU of the command GAKP contains two parameters:
(N1047.00)
(N1048.00)
(N1049.00)
Table 160: (N1049.50) GAKP, Return of a public key
Content Description
P1 81 operationMode = returning a key generated afore
P2 00
14.9.2.3 Use Case Key generation with returning a public key
In this variant the APDU of the command GAKP contains two parameters:
(N1050.00)
(N1051.00)
(N1052.00)

Table 161: (N1052.40) GAKP, key generation with returning the public key
Content Description
P1 80 operationMode = key generation and return of the public key
P2 00
14.9.2.4 Response of the smartcard to key generation

Table 162: (N1052.50) GAKP Response APDU in case of success

XXYY publicKeyDO Absent, or public key generated afore
90 00 NoError Operation successful
Table 163: (N1052.60) GAKP Response APDU in case of failure

6A 88 KeyNotFound Referenced key object not found
64 00 KeyAlreadyPresent Key already generated
64 00 KeyInvalid Key data missing
(N1053.00)

(N1054.00)
The COS MUST support the variants of the command GAKP from 14.9.2.1, 14.9.2.2
and 14.9.2.3.
The COS MAY support additional variants of GAKP.
The COS MAY refuse additional variants of GAKP.
(N1055.00)
If in currentFolder the attribute keyReferenceList in the element signatureCreation
a. is empty, then the COS MAY
i. either refuse the execution of this command with any trailer,
ii. or try to work in executing this command with keys which do not represent a
private signature object.

currentFolder,
channelContext.keyReferenceList.signatureCreation.keyReference,
Wildcard
) will be set. According to Clause 9.2.3.1 and according to (N1136.00) it MAY hap-
pen, that the search for a key is not successful. If and only if the search for a key re-
turns the error keyNotFound, then the command MUST terminate with the trailer
KeyNotFound terminieren. The error notSupported is not possible because of the
search with a wildcard.
(N1056.00)
(N1057.00)
If operationMode is element of the set {80, 84} and the attribute keyAvailable has the
value
a. True, then the command MUST terminate with the trailer keyAlreadyPresent.
b. False,
i. then a key pair ( PrK, PuK ) MUST be generated whose characteristics match
with the attributes of affectedObject.
ii. Subsequently, the attribute keyAvailable MUST be changed to the value of
True. The change of keyAvailable MUST be executed with transaction pro-
tection.
(N1058.00)
If and only if operationMode is element of the set {81} and the attribute keyAvailable
has the value False, then the command MUST terminate with the trailer KeyInvalid.
(N1059.00)
(N1060.00)
used as trailer.
(N1061.00)
(N1062.00)
The DER TLV coded data object publicKeyDO MUST be calculated as follows: If PuK
is a
a. RSA key, then it applies:
i. Set L82 greater than or equal to OctetLength( PuK.e ), but less than 128.
ii. Set n = I2OS( PuK.n, OctetLength( PuK.n ) ).
iii. Set e = I2OS( PuK.e, L82 ).
iv. publicKeyDO = 7F49 L7F49 ( 81 L81 n || 82 L82 e ).
b. ELC key, then it applies from generation 2 on
publicKeyDO = 7F49 L7F49 ( 06 L06 OID || 86 L86 P ).
(N1063.00)

a. If operationMode has a value of the set {80, 81}, then the data field of the re-
sponse message contains publicKeyDO.
b. Otherwise the data field is not present in the response message.
(N1064.00)
b. Each trailer in Table 163 (N1052.60) MUST have a higher priority than UpdateRe-
tryWarning.
14.9.3 GET CHALLENGE
The command GET CHALLENGE generates a random number. This random number is
available inside the smartcard at least fort the execution of the next command. Typically this
next command contains the authentication of an external component.
14.9.3.1 Use Case Generation of a random number for DES- or RSA-Authentication
In this variant the APDU of the command GET CHALLENGE contains one parameter:
(N1065.00)
of length MUST be equal to 8.
(N1066.00)
Table 164: (N1066.20) GET CHALLENGE
Content Description
P1 00
P2 00
Ne 08 Expected number of octets in the response data, in this case 8
14.9.3.2 Use Case Generation of a random number for AES or ELC authentication
This clause will be completed in a later version of this document.

Generation 2 with Ne = 16 for AES and ELC

14.9.3.3 Response of the smartcard to the generation of a random number
Table 165: (N1066.80) GET CHALLENGE Response APDU in case of success

XXYY RND.ICC Random number
90 00 NoError Generation of a random number successful
Table 166: (N1066.90) GET CHALLENGE Response APDU in case of failure

No error codes defined at the moment
(N1067.00)

(N1068.00)
The COS MUST support the variant for GET CHALLENGE from 14.9.3.1.
The COS MAY support additional variants for GET CHALLENGE.
The COS MAY refuse additional variants for GET CHALLENGE.
(N1069.00)
The access condition for all variants of GET CHALLENGE MUST be ALWAYS.
(N1070.00)
Set RND.ICC = RAND( Ne ).
(N1071.00)
(N1072.00)
The data field of the response message contains RND.ICC.
(N1073.00)
RND.ICC MUST be stored to be used in the following commands: (see (N321.00)b).
RND.ICC MUST be available in the subsequent command.
RND.ICC MAY be available in the next but one command.
14.9.4 GET RESPONSE
(N1074.00)
The COS MAY support this command according to [ISO7816-4]
14.9.5 MANAGE CHANNEL
The command MANAGE CHANNEL is used for opening and closing logical channels which

have a non-zero channel number. The parameters of the MANAGE CHANNEL command
determine whether a channel will be opened or which channel will be closed.
(N1075.00)
A logical channel being open in addition to the basic channel MAY influence the com-
mand execution, if these commands access objects which are active in other logical
channels. Therefore, the following requirement is to be observed by the component
that sends the command APDU.
The commands LOAD APPLICATION, DELETE, ACTIVATE and DEACTIVATE MUST
NOT be sent to the COS, if in addition to the basic channel a further logical channel
has been opened.
14.9.5.1 Use Case Opening a logical Channel
In this variant the APDU of MANAGE CHANNEL includes three parameters:

(N1076.00)
The parameter logicalChannelNumber contains the channel number which the com-
mand is to be performed in. The value of logicalChannelNumber MUST be set to zero
and MUST be set according to [ISO7816-4] Clause 5.1.1, i.e. in the CLA byte of the
APDU that is visible at the I/O interface.
(N1077.00)
The parameter intendedAction indicates that a logical channel is to be opened. The
COS determines the channel number. The value of intendedAction MUST be set to
0 = 0000.
(N1078.00)
of length MUST be set to 1 = 01.
(N1079.00)
A Case 2 command APDU according to Clause 11.7.2.1 MUST be sent via interpreter
interface. The information given in Table 167 (N1079.50) MUST be used for the con-
struction of this Case 2 command APDU.
Table 167 (N1079.50) MANAGE CHANNEL for opening a Logical Channel
Content Description
P1 00 intendedAction, here: Open a channel,
P2 00 Channel number is determined by the COS.
Ne 01 Number of expected octets in the response data
14.9.5.2 Use Case Closing a Logical Channel
In this variant the APDU of a MANAGE CHANNEL command includes two parameters:
(N1080.00)
The parameter logicalChannelNumber MUST contain the number of an open channel
that is to be closed. The value of logicalChannelNumber MUST be a non-zero value
and MUST be set according to [ISO7816-4] CLAUSE 5.1.1, i.e. in the CLA byte of the
APDU that is visible at the I/O interface.
(N1081.00)
The parameter intendedAction indicates that a logical channel is to be closed. The
channel number is specified in the CLA byte. The value of intendedAction MUST be set
to 32768 = 8000.
(N1082.00)
Table 168 (N1082.40) MANAGE CHANNEL for Closing a Channel
Content Description
CLA XX CLA Byte according to [ISO7816-4] with a non-zero channel number
P1 80 intendedAction, here: Close a channel
P2 00 affected channel is indicated in the CLA byte.
14.9.5.3 Card Response to Channel Management Operations

Table 169 (N1082.50) MANAGE CHANNEL Response in case of success

XX Channel No. Number of the channel just opened
90 00 NoError successful operation
Table 170: (N1082.60) MANAGE CHANNEL Response APDU in case of failure

68 81 NoMoreChannelsAvailable no further logical channel available
Note: This table does not contain the errors which might be detected in the I/O, ChannelSwitch, and
SecMes components in Figure 1 (N270.50).
(N1083.00)
14.9.5.4 Command Processing inside the Card

(N1084.00)
The COS MUST support the MANAGE CHANNEL variants of Clause 14.9.5.1 and
14.9.5.2.
The COS MAY support further MANAGE CHANNEL variants.
The COS MAY refuse further MANAGE CHANNEL variants.
(N1085.00)
The access condition of all MANAGE CHANNEL variants MUST be ALWAYS.
(N1086.00)
If intendedAction indicates the opening of a channel
a. and all available logical channels have already been opened, then the command
MUST terminate with the trailer NoMoreChannelsAvailable,
b. otherwise the COS MUST

i. allocate a channel number not being used newChannelNumber
ii. open a further logical channel,
iii. assign to it the allocated number newChannelNumber and
iv. initialize its channel context according to (N321.00).
c. I2OS( newChannelNumber, 1) MUST be used as data field of the response mes-
sage.
(N1087.00)
If intendedAction indicates the closing of a channel
a. then the corresponding logical channel MUST be closed and
b. the channel number being released MUST be available for future allocations.
c. The data field of the response message MUST be empty.
(N1087.10)
(N1088.00)
a. The priorities of the trailer in Table 170 (N1082.60) is manufacturer-specific
b. Each trailer in Table 170 (N1082.60) MUST have priority over NoError.
14.9.6 MANAGE SECURITY ENVIRONMENT
The command MANAGE SECURITY ENVIRONMENT (MSE) changes in currentFolder the

attributes seIdentifier and in channelContext elements of keyReferenceList. Which operation
has to be executed, which attribute or list element is affected and to which value it has to be
changed will be determined by parameters being part of the command message.
(N1089.00)
If a symmetric or a private key is referenced, then the parameter keyReference has two
parts: location and identifier. location indicates whether a global or a DF-specific key is
affected by the operation. An element of the set {00, 80} MUST be used as the
value for location. It applies:
a. The value location = 00 MUST be used if a global key is affected.
b. The value location = 80 MUST be used if a DF-specific key is affected.
c. The parameter identifier determines the affected key object. The value of identifier
MUST be chosen in accordance with (N167.00) resp. (N184.00).
d. The parameter keyReference MUST be coded in an octet with the following value:
keyReference = location + identifier.
14.9.6.1 Use Case Changing the SE-Identifier
In this variant the APDU of the command MSE contains two parameters
(N1090.00)
The parameter operationMode determines the operation to be executed. For this use
case operationMode = F3 MUST be chosen.
(N1091.00)
The parameter seNo MUST be chosen according to (N79.00).

(N1092.00)
APDU the instructions of Table 171 (N1092.50) MUST be used
Table 171: (N1092.50) MSE: RESTORE
Content Description
P1 F3 operationMode = selection of a SEIdentifier
P2 XX seNo = value of the SEIdentifier to be selected
14.9.6.2 Use Case Key selection for internal symmetric authentication
In this variant the APDU of the command MSE contains four parameters:
(N1093.00)
case operationMode = 41 MUST be chosen.
(N1094.00)
The parameter crtTag determines the list element in keyReferenceList, which has to be
changed. For this use case crtTag = A4 MUST be chosen.
(N1095.00)
Requirement for SMC-A and SMC-B
The parameter keyRef contains the new value of keyReference in the list element in-
ternalAuthenticate. Value and encoding MUST be chosen
a. either according to (N1089.00) or
b. according to (N176.00).
(N1096.00)
The parameter algID contains the new value for the element algorithmIdentifier in the
list element internalAuthenticate. The value and encoding MUST be chosen according
to Table 186 (N1216.00). A value of the set {
desRoleAuthentication,
desSessionkey4SM,
desSessionkey4TC (requirement for SMC-A and SMC-B)
} MUST be used.
The COS MAY support further values for algID.
The COS MAY refuse further values for algID.
(N1097.00)

Table 172: (N1097.50) MSE, selection of a symmetric key for INTERNAL AUTHENTICATE
Content Description
P1 41 operationMode = setting of an internal key
P2 A4 crtTag = the list element affected is internalAuthenticate
Data XXYY 83 L83 keyRef || 80 01 || algID
Note: L83 is an octet with the value of I2OS( OctetLength(keyRef), 1).
14.9.6.3 Use Case Key selection for internal asymmetric authentication
(N1098.00)
(N1099.00)
(N1100.00)
The parameter keyRef contains the new value for the element keyReference in the list
element internalAuthenticate. Value and coding MUST be chosen according to
(N1089.00).
(N1101.00)
The parameter algID contains the new value for the element algorithmIdentifier in list
element internalAuthenticate. The value and encoding MUST be chosen according to
Table 186 (N1216.00) and Table 188 (N1218.00). A value of the set {
rsaClientAuthentication,
rsaRoleAuthentication,
rsaSessionkey4Intro,
rsaSessionkey4SM,
rsaSessionkey4TC, (requirement for SMC-A and SMC-B)
signPKCS1_V1_5
} MUST be used.
(N1102.00)

Table 173: (N1102.50) MSE, Selection of a private INTERNAL AUTHENTICATE Key
Content Description
P1 41 operationMode = setting of an internal key
P2 A4 crtTag = the list element affected is internalAuthenticate
Data XXYY 84 01 || keyRef || 80 01 || algID
14.9.6.4 Use Case Key selection for external symmetric authentication
(N1103.00)
(N1104.00)
(N1105.00)
Requirement for SMC-A and SMC-B
element externalAuthenticate. The value and encoding MUST be chosen
(N1106.00)
element externalAuthenticate. The value and encoding MUST be used according to
Table 186 (N1216.00). A value of the set {
desRoleCheck,
desSessionkey4SM
} MUST be used.
(N1107.00)
Table 174: (N1107.50) MSE, Selection symmetric key for EXTERNAL AUTHENTICATE
Content Description
P1 81 operationMode = setting of an external key
P2 A4 crtTag = the list element affected is externalAuthenticate
Note: L83 is an octet with the value of I2OS( OctetLength(keyRef), 1).

14.9.6.5 Use Case Key selection for external asymmetric authentication
(N1108.00)
(N1109.00)
(N1110.00)
element externalAuthenticate. Value and coding MUST be chosen according to
(N206.00).
(N1111.00)
element externalAuthenticate. The value and encoding MUST be chosen according to
Table 186 (N1216.00). A value of the set {
rsaRoleCheck,
rsaSessionkey4Intro,
rsaSessionkey4SM,
rsaSessionkey4TC, (requirement for SMC-A and SMC-B)
} MUST be used.
(N1112.00)
Table 175: (N1112.50) MSE, selection of a public key for EXTERNAL AUTHENTICATE
Content Description
P1 81 operationMode = setting of a public key
Data XXYY 83 0C || keyRef || 80 01 || algID
14.9.6.6 Use Case Key selection for symmetric mutual authentication
(N1113.00)
(N1114.00)
(N1115.00)
element externalAuthenticate. The value and encoding MUST be chosen
(N1116.00)
list element externalAuthenticate. Value and coding MUST be chosen according to
Table 186 (N1216.00), whereas a value from the set {
desSessionkey4SM
} MUST be used.
The COS MAY accept additional values for algID.
The COS MAY refuse additional values for algID.
(N1117.00)
Table 176: (N1117.50) MSE, selection symmetric key for MUTUAL AUTHENTICATE
Content Description
P1 81 operationMode = setting of a symmetric key
Note 1: L83 is an octet with value I2OS( OctetLength(keyRef), 1)
Note 2: It is not required to change or extend the normative requirement (N1116.00) as the command
MUTUAL AUTHENTICATE is solely used to establish session keys for Trusted Channel.
14.9.6.7 Use Case Key selection for signature keys
This use case is used to select a signature key. Afterwards it is possible to generate this key
or to read its public part (see Clause 14.9.2) or to calculate signatures with this key (see
Clause 14.8.1). In this variant the APDU of the command MSE contains four parameters:
(N1118.00)
(N1119.00)
changed. For this use case crtTag = B6 MUST be chosen.
(N1120.00)
element signatureCreation. Value and coding MUST be chosen according to
(N1089.00).
(N1121.00)
list element signatureCreation. Value and coding MUST be chosen according to Table
186 (N1216.00) and Table 188 (N1218.00). A value from the set {
rsaClientAuthentication,
sign9796_2_DS2,
signPKCS1_V1_5,
signPSS
} MUST be used.
(N1122.00)
Table 177: (N1122.50) MSE, selection of a private signature key
Content Description
P1 41 operationMode = setting of a private key
P2 B6 crtTag = the list element affected is signatureCreation
14.9.6.8 Use Case Key selection for the validation of CV-certificates
In this variant the APDU of the command MSE contains three parameters:
(N1123.00)
(N1124.00)
(N1125.00)
element verifyCertificate. Value and coding MUST be chosen according to (N202.00).
(N1126.00)
Table 178: (N1126.50) MSE, selection of the public certificate validation key
Content Description
P1 81 operationMode = setting of a public key
P2 B6 crtTag = the list element affected is verifyCertificate
Data XXYY 83 08 || keyRef
14.9.6.9 Use Case Key selection for data decryption or transcription

(N1127.00)
(N1128.00)
(N1129.00)
element dataDecipher. Value and coding MUST be chosen according to (N1089.00).
(N1130.00)
list element dataDecipher. Value and coding MUST be chosen according to Table 187
(1217.00), whereas a value from the set {
rsaDecipherPKCS1_V1_5,
rsaDecipherOaep
} MUST be used.
(N1131.00)
Table 179: (N1131.40) MSE, Key Selection for Decryption
Content Description
P1 41 operationMode = setting of a private key
P2 B8 crtTag = the list element affected is dataDecipher
14.9.6.10 Response of the smartcard to the management of the Security Environments

Table 180: (N1131.50) MSE Response APDU in case of success

90 00 NoError Transfer of command data parameters successful
Table 181: (N1131.60) MSE Response APDU in case of failure

6A 88 KeyNotFound Key object to be selected is not found
6A 81 UnsupportedFunction Key does not support indicated algorithm
(N1132.00)

(N1133.00)
The COS MUST support the variants of MSE from 14.9.6.1, 14.9.6.2, 14.9.6.3,
14.9.6.4, 14.9.6.5, 14.9.6.6, 14.9.6.7, 14.9.6.8 and 14.9.6.9.
The COS MAY support additional variants for MSE.
The COS MAY refuse additional variants for MSE.
(N1134.00)
The access condition for all variants of the command MSE MUST be ALWAYS.
(N1135.00)
If the parameter operationMode in P1 has the value F3, then in currentFolder
a. the attribute seIdentifier (see (N322.00)a) MUST be set to the value of the parame-
ter seNo.
b. each list element in keyReferenceList (see (N321.00)c) MUST be set to the value
which codes an empty element.
c. each element in globalPasswordList (see (N321.00)i) and in dfSpecificPasswordList
(see (N321.00)j) the attribute securityStatusEvaluationCounter MUST be removed
from the mentioned lists using clearPasswordStatus() if it is assigned to current-
Folder.
d. the value of currentEF MUST remain unchanged.
e. each element in globalSecurityList (see (N321.00)e) and in dfSpecificSecurityList
(see (N321.00)f) MUST be removed from the mentioned lists using
clearSecurityStatus() if it is assigned to currentFolder.
f. attributes, which are assigned to folders of a higher layer MUST NOT be changed.
(N1136.00)
If the parameter operationMode in P1 has a value of the set {41, 81}, then the list
element in currentFolder which is characterized by the parameters operationMode and
crtTag MUST be filled with the parameters from the data field of the command mes-
sage.
ATTENTION: Depending on the COS implementation it is possible that the referenced
key objects with matching algorithmIdentifier are searched already during the execution
of the MSE command. In this case the command MSE MAY terminate with a trailer
KeyNotFound or UnsupportedFunction. It MAY be that this error does not occur again
when the command is executed which needs to use the key. Either here or there the
error KeyNotFound or UnsupportedFunction MUST be reported.
(N1137.00)
(N1138.00)
14.9.7 GET RANDOM
The command GET RANDOM generates a random number. Unlike GET CHALLENGE this
random number is not available for further operations inside the smartcard after completion
of the command. In return the random number generated via GET RANDOM fulfills certain
security requirements.
(N1139.00)
All normative requirements of Clause 14.9.7 and sub-clauses MUST apply for the HPC,
SMC-A and SMC-B.
14.9.7.1 Use Case Generation of a kryptographically secure random number

In this variant the APDU of the command GET RANDOM contains one parameter:
(N1140.00)
(N1141.00)
Table 182: (N1141.40) GET RANDOM
Content Description
INS 84 Instruction Byte acc. to [ISO7816-4] (identical to GET CHALLENGE)
P1 00
P2 00
14.9.7.2 Response of the smartcard to the generation of a cryptographically secure random

number
Table 183: (N1141.50) GET RANDOM Response APDU in case of success

XXYY random Random number
90 00 NoError Generation of a random number successful
Table 184: (N1141.60) GET RANDOM Response APDU in case of failure

(N1142.00)

(N1143.00)
The COS MUST support the variant for GET RANDOM from Clause 14.9.7.1.
The COS MAY support additional variants for GET RANDOM.
The COS MAY refuse additional variants for GET RANDOM.

(N1144.00)
currentFolder MUST be used as affectedObject.
(N1145.00)
If and only if AccessRuleEvaluation( affectedObject, CLA, INS, P1, P2 ) returns the
value False, then the command MUST terminate with the trailer SecurityStatusNot-
Satisfied.
(N1146.00)
The COS MUST
a. generate a random octet string random with length octets and
b. the quality of this random number MUST at least follow Clause 5.2 [Krypt-Alg].
(N1147.00)
(N1148.00)
The data field of the response message contains random.

15 Authentication Protocols (normative)
This clause describes how the key-based authentication is processed between an HPC and
an eGK (see Figure 3 (N1148.40)), between an SMC and an eGK (see Figure 4 (N1148.50)),
and between an HPC and an SMC (see Figure 5 (N1148.60)).
Channel_1 Channel_2
HP C S oftware eGK
Figure 3: (N1148.40) Communication model HPC, controlling software and eGK
C hannel_1 Channel_2
SMC Softw are eGK
Figure 4: (N1148.50) Communication model SMC, controlling software and eGK
Channel_1 Channel_2
HP C S oftware SMC
Figure 5: (N1148.60) Communication model HPC, controlling software and SMC
The communication model, used in this clause, is as follows:
A component HPC respectively SMC has the interface characteristics specified in this
document.
A component eGK has analog characteristics as HPC/SMC.
A component controlling software has a defined process logic. The controlling software
shall communicate with the HPC via the communication channel 1 and with the eGK via
the communication channel 2. Depending on the communication partner the SMC is ad-
dressed either via channel 1 (eGK is the communication partner) or via channel 2 (the
HPC is the communication partner). These two channels comply with the physical inter-
face in Figure 1(N270.50).
A separate sub-clause is dedicated to each of the described variants. In general the authen-
tication consists of a sequence of one ore more commands, being sent via the communica-
tion channels. For all authentication protocols it applies:
(N1149.00)
If the sequence of an authentication protocol has more than one command-response
pair (see Clause 15.3, Clause 15.4, Clause 15.5 and Clause 15.6), then this sequence
MUST NOT be interrupted at the interface channel 1 in Figure 3 (N1148.40) and Figure

4 (N1148.50) respectively channel 1 and channel 2 in Figure 5 (N1148.60) by com-
mands not belonging to this sequence.
(N1150.00)
If the external entity cannot meet the requirement (N1149.00), therefore the sequence
is interrupted by an interrupting command, then the COS of the HPC/SMC MAY
a. accept the interrupting command.
b. refuse the interrupting command.
c. accept to continue the interrupted sequence.
d. refuse to continue the interrupted sequence.
(N1151.00)
It MUST be possible that each of the sequences described here can be transferred
without protection (without Secure Messaging). If it is necessary to support also the
protected transfer this will be explicitely mentioned in the corresponding clauses.
(N1151.10)
If the first command of this sequence
a. is transferred in protected mode, then all other commands of this sequence MUST
also be transferred in the protected mode.
b. is transferred in unprotected mode, then all other commands of this sequence
MUST also be transferred in the unprotected mode.
(N1152.00)
If the external entity cannot meet the requirement (N1151.00), then the COS of the
HPC/SMC MAY
a. accept this.
b. refuse this.
15.1 Internal Authentication without Negotiation of Session Keys
This clause covers the authentication of an HPC or SMC versus an eGK.
15.1.1 Internal Authentication with symmetric Keys
In case that the HPC resp. SMC will prove its authenticity with a symmetric key and no ses-
sion keys shall be negotiated the following sequence has to be used (see Figure 6
(N1156.50)):
(N1153.00)
The first command of the sequence MUST be GET CHALLENGE sent to the eGK via
channel 2.
(N1154.00)
The second command of this sequence MUST be INTERNAL AUTHENTICATE ac-
cording to Clause 14.7.4.1 sent to the HPC or SMC via channel 1. In the HPC or SMC
desRoleAuthentication MUST be set as algorithm according to Clause 14.9.6.2.
(N1155.00)
The third command is the last command of this sequence and MUST be EXTERNAL
AUTHENTICATE sent to the eGK via channel 2.

(N1156.00)
It MUST be possible to transfer the commands of this sequence, which are sent via
channel 1, in protected mode according to Clause 13 (Secure Messaging).
H PC/S MC Softw are eGK
GetChallenge
Channel_1
Channel_2
InternalAuthenticate(RND .ICC). (RND. ICC, N oError ).
( authData, NoError ) ExternalAuthenticate (aut hData)

(N oError ).
Figure 6: (N1156.50) Sequence Diagram for the internal Authentication
15.1.2 RSA, asymmetric role authentication
In case that the HPC resp. SMC will prove its authenticity with a RSA key and no session
keys shall be negotiated the following sequence has to be used (see Figure 6 (N1156.50)):
(N1157.00)
channel 2.
(N1158.00)
rsaRoleAuthentication MUST be set as algorithm according to Clause 14.9.6.3.
(N1159.00)
(N1160.00)
channel 1, in protected mode according to Clause 13 (Secure Messaging).
15.1.3 ELC, asymmetric proof of authorization (G2, informative)
In case that the HPC resp. SMC will prove its authenticity with an ELC key and no session
keys shall be negotiated the following sequence has to be used (compare Figure 6
(N1156.50)):
(N1161.00)
The first command of the sequence MUST be GET CHALLENGE sent via channel 2 to
the eGK.
(N1162.00)
elcRoleAuthentication MUST be set as algorithm according to Clause 14.9.6.3.

(N1163.00)
(N1164.00)
channel 1, in protected mode according to Clause 13 (Secure Messaging)
15.2 External Authentication without Negotiation of Session Keys
In case that the HPC resp. SMC will check the authenticity of an eGK with a key and no ses-
sion keys shall be negotiated the following sequence has to be used (see Figure 7
(N1168.50)):
(N1165.00)
The first command of the sequence MUST be GET CHALLENGE according to Clause
14.9.3.1 sent to the HPC or SMC via channel 1.
(N1166.00)
The second command of this sequence MUST be INTERNAL AUTHENTICATE sent to
the eGK via channel 2. In the eGK rsaRoleAuthentication MUST be set as algorithm.
(N1167.00)
The third command of the sequence MUST be EXTERNAL AUTHENTICATE according
to Clause 14.7.1.1 sent to the HPC or SMC via channel 1. In the HPC or SMC
rsaRoleCheck MUST be set as algorithm according to Clause 14.9.6.5.
(N1168.00)
channel 1, in protected mode according to Clause 13 (Secure Messaging)
HPC/ SMC S oftware eGK
GetC hallenge
Channel_1
Channel_2
(RND. ICC, N oError ).

Int ernalA uthen ticate(RND. ICC).
(authD ata, N oError )

ExternalAuthenticate (authData )
(NoError ).
Figure 7: (N1168.50) Sequence Diagram for the external Authentication
15.3 Card-2-Card Authentication without Negotiation of Session Keys
The Card-2-Card authentication without negotiation of session keys is a special variant of the
processes discussed in Clause 15.1 and Clause 15.2.
If a one-sided authentication (only one of the components HPC resp. SMC or eGK authenti-
cates) is intended, then an algorithm from Clause 15.1 or Clause 15.2 will be performed de-
pending on the direction of the authentication.
If a mutual authentication (both components HPC resp. SMC and eGK authenticate) is inten-
ded, then both an algorithm from Clause 15.1 and an algorithm from Clause 15.2 will be per-
formed. Typically the access conditions for the involved keys define which component has to
authenticate first.
15.4 Negotiation of Session Keys
This sub-clause covers the mutual authentication of two entities whereas session keys are
negotiated at the same time.
15.4.1 Symmetric Negotiation of Session Keys between SMC and eGK
In case that a mutual authentication has to be executed between SMC and eGK and at the
same time session keys shall be negotiated the following sequence has to be used (see
Figure 8 (N1173.50)):
(N1169.00)
channel 2. The random number generated by the eGK is denoted R.1.
(N1170.00)
The second command MUST be INTERNAL AUTHENTICATE according to Clause
14.7.4.1 sent to the SMC via channel 1. In the SMC desSessionkey4TC MUST be set
as algorithm according to Clause 14.9.6.2. For the authentication command cmdData
MUST contain R.1. The response data are denoted rspData.2.
(N1171.00)
The third command of the sequence MUST be MUTUAL AUTHENTICATE sent to the
eGK via channel 2. In the eGK desSessionkey4SM MUST be set as algorithm. For the
authentication command rspData.2 MUST be used as command data. The response
data are denoted rspData.3.
(N1172.00)
The fourth command is the last command of this sequence and MUST be EXTERNAL
AUTHENTICATE according to Clause 14.7.1.1 sent to the SMC via channel 1. In the
SMC desSessionkey4TC MUST be set as algorithm according to Clause 14.9.6.4. For
the authentication command rspData.3 MUST be used as command data.
(N1173.00)
The SMC MAY accept the protected transfer of the sequence.
The SMC MAY refuse the protected transfer of the sequence.
SMC Software eGK
GetChallenge
Channel_1
Channel_2
(R.1, NoError).
InternalAuthenticate(cmdData=R.1 sn.1).
(rspData.2=enc(R.2 sn.2 R.1 sn.1 KD.2) || MAC, NoError )
MutualAuthenticate(rspData.2)
(rspData.3=enc(R.1 sn.1 R.2 sn.2 KD.1) || MAC, NoError ).
ExternalAuthenticate(rspData.3).
(NoError)

Figure 8: (N1173.50) Sequence Diagram for the symmetric Negotiation of Session Keys
between SMC and eGK
15.4.2 Symmetric Negotiation of Session Keys between HPC and SMC
In case that a mutual authentication has to be executed between HPC and SMC with sym-
metric keys and at the same time session keys shall be negotiated the following sequence
has to be used (see Figure 9 (N1178.50)):
(N1174.00)
14.9.3.1 sent to the SMC via channel 2. The random number generated by the SMC is
denoted R.1.
(N1175.00)
14.7.4.1 sent to the HPC via channel 1. In the HPC desSessionkey4SM MUST be set
as algorithm according to Clause 14.9.6.2. For the authentication command cmdData
MUST contain R.1. The response data are denoted rspData.2.
(N1176.00)
The third command of the sequence MUST be MUTUAL AUTHENTICATE according to
Clause 14.7.1.2 sent to the SMC via channel 2. In the SMC desSessionkey4TC MUST
be set as algorithm according to Clause 14.9.6.6. For the authentication command
rspData.2 MUST be used as command data. The response data are denoted
rspData.3.
(N1177.00)
AUTHENTICATE according to Clause 14.7.1.1 sent to the HPC via channel 1. In the
HPC desSessionkey4SM MUST be set as algorithm according to Clause 14.9.6.4. For
the authentication command rspData.3 MUST be used as command data.
(N1178.00)
HPC and SMC MAY accept the protected transfer of the sequence.
HPC and SMC MAY refuse the protected transfer of the sequence.
HPC Software SMC
GetChallenge
Channel_1
Channel_2
(R.1, NoError).
InternalAuthenticate (cmdData=R.1 sn.1).
(rspData.2=enc(R.2 sn.2 R.1 sn.1 KD. 2) || MAC, NoError )

MutualAuthenticate(rspData. 2)
(rspData.3=enc(R.1 sn.1 R.2 sn.2 KD. 1) || MAC, NoError ).

ExternalAuthenticate (rspData.3).
(NoError)
Figure 9: (N1178.50) Sequence Diagram for the symmetric Negotiation of Session Keys
between HPC and SMC

15.4.3 RSA Negotiation of Session Keys between SMC and eGK
In case that a mutual authentication has to be executed between SMC and eGK with asym-
metric RSA keys and at the same time session keys shall be negotiated the following se-
quence has to be used (see Figure 10 (N1185.50)):
(N1179.00)
The first command MUST be GET CHALLENGE according to Clause 14.9.3.1 sent to
the SMC via channel 1. The response data generated by the SMC are denoted R.1.
(N1180.00)
The second command MUST be INTERNAL AUTHENTICATE sent to the eGK via
channel 2. In the eGK rsaSessionkey4SM MUST be set as algorithm. For the authenti-
cation command it MUST apply: cmdData.2 = R.1 || ICCSN8.SMC with ICCSN8.SMC
equal to iccsn8 (see (N210.00)c) of the SMC. It is not a topic of this document to de-
scribe how the entity which sends the command APDU gets knowledge of
ICCSN8.SMC. The corresponding response data of the eGK are denoted rspData.2.
(N1181.00)
The third command MUST EXTERNAL AUTHENTICATE according to Clause 14.7.1.1
sent to the SMC via channel 1. In the SMC rsaSessionkey4TC MUST be set as algo-
rithm according to Clause 14.9.6.5. For the authentication command rspData.2 MUST
be used as command data.
(N1182.00)
The fourth command MUST be GET CHALLENGE according to Clause 14.9.3.1 sent
to the eGK via channel 2. The corresponding response data generated by the eGK are
denoted R.2.
(N1183.00)
The fifth command MUST be INTERNAL AUTHENTICATE according to Clause
14.7.4.1 sent to the SMC via channel 1. In the SMC rsaSessionkey4TC MUST be set
as algorithm according to Clause 14.9.6.3. For the authentication command it MUST
apply: cmdData.5 = R.2 || ICCSN8.eGK with ICCSN8.eGK equal to iccsn8 (see
(N210.00)c) of the eGK. It is not a topic of this document to describe how the entity
which sends the command APDU gets knowledge of ICCSN8.eGK. The corresponding
response data of the SMC are denoted rspData.5.
(N1184.00)
The sixth command is the last command of this sequence and MUST be EXTERNAL
AUTHENTICATE sent to the eGK via channel 2. In the eGK rsaSessionkey4SM MUST
be set as algorithm. For the authentication command rspData.5 MUST be used as
command data.
(N1185.00)
The SMC MAY accept the protected transfer of the sequence.
The SMC MAY refuse the protected transfer of the sequence.

SMC Software eGK
Ge tChalle nge.
(rsp Data.1 =R.1, N oError) In ternalAuthenticate(cmd Data.2 =R.1 sn.1)

( rspData.2=enc[sig (P.2 KD.2 R.1 sn.1)], NoError).
Extern alAuth enticate (rspData.2).
Channel_1
Channel_2
(No Error)
GetChalle nge
InternalAuthenticate(cmdData.5=R.2 sn.2). (rspD ata.4=R.2, NoError).
(rspData.5= enc[sig(P.1 KD.1 R.2 sn.2)], NoEr ror)

ExternalAuthenti cate(rsp Data.5)
(NoError).
Figure 10: (N1185.50) Sequence Diagram for the RSA Negotiation of Session Keys
between SMC and eGK
15.4.4 RSA Negotiation of Session Keys between SMC and HPC
In case that a mutual authentication has to be executed between SMC and HPC with asym-
metric RSA keys and at the same time session keys shall be negotiated the following se-
quence has to be used (see Figure 11 (N1192.10)):
(N1186.00)
The first command MUST be GET CHALLENGE according to Clause 14.9.3.1 sent to
the SMC via channel 2. The response data generated by the SMC are denoted R.1.
(N1187.00)
14.7.4.1 sent to the HPC via channel 1. In the HPC rsaSessionkey4SM MUST be set
as algorithm. For the authentication command it MUST apply: cmdData.2 = R.1 ||
ICCSN8.SMC with ICCSN8.SMC equal to iccsn8 (see (N210.00)c) of the SMC. It is not
a topic of this document to describe how the entity which sends the command APDU
gets knowledge of ICCSN8.SMC. The corresponding response data of the HPC are
denoted rspData.2
(N1188.00)
The third command MUST be EXTERNAL AUTHENTICATE according to Clause
as algorithm. For the authentication command rspData.2 MUST be used as command
data.
(N1189.00)
to the HPC via channel 1. The corresponding response data generated by the HPC are
denoted R.2
(N1190.00)
as algorithm. For the authentication command it MUST apply: cmdData.5 = R.2 ||

ICCSN8.HPC with ICCSN8.HPC equal to iccsn8 (see (N210.00)c) of the HPC. It is not
a topic of this document to describe how the entity which sends the command APDU
gets knowledge of ICCSN8.HPC. The corresponding response data of the SMC are
denoted rspData.5.
(N1191.00)
AUTHENTICATE according to Clause 14.7.1.1 sent to the HPC via channel 1. In the
HPC rsaSessionkey4SM MUST be set as algorithm. For the authentication command
rspData.5 MUST be used as command data.
(N1192.00)
HPC Software SMC
GetChallenge.
InternalAuthenticate(cmdData.2=R.1 sn.1) (rspData.1=R.1, NoError)
(rspData.2=enc[sig(P.2 KD.2 R.1 sn.1)], NoError). ExternalAuthenticate(rspData.2).

Channel_1
Channel_2
(NoError)
GetChallenge
(rspData.4=R.2, NoError). InternalAuthenticate(cmdData.5=R.2 sn.2).
ExternalAuthenticate(rspData.5) (rspData.5=enc[sig(P.1 KD.1 R.2 sn.2)], NoError)
(NoError).
Figure 11: (N1192.10) Sequence Diagram for the RSA Negotiation of Session Keys
between SMC and HPC
15.4.5 ELC Negotiation of Session Keys (informative)
This clause will be added in a later version of this document.
15.5 Mutual Introduction
In the context of the so called Round of introduction a mutual authentication with negotia-
tion of session keys is executed; these session keys will be stored in a persistent way as
Introduction Keys after successful authentication. The benefit of this Round of Introduction
is the fact that for later authentication procedures the keys of the participating components
are instantly available, thus improving the performance. The agreed introduction keys belong
individually to the corresponding authentication keys. If a component A is introduced to n
other components, then n different introduction keys have to be stored.

It makes sense to use this process in an organization which has a manageable number of
HPCs, SMC-As, SMC-Bs and SMC-Ks, which frequently interact with each other. It is as-
sumed that the mutual introduction involves either
an HPC and an SMC-A or
an SMC-B and an SMC-A or
an HPC and an SMC-K.

A mutual introduction between HPC and SMC-A provides a basis for an efficient symmetric
authentication (see Chapter 15.6) with the objective of remote PIN transfer to the HPC. The
following is assumed for this introduction:
The HPC holds the public key PuK.SMC.AUTD_RPS_CVC. Therefore, the corre-
sponding certificate C.SMC.AUTD_RPS_CVC had to be imported into the HPC.
The SMC-A holds the public key PuK.HPC.AUTD_SUK_CVC. Therefore, the corre-
sponding certificate C.HPC. AUTD_SUK_CVC had to be imported into the SMC-A.
A mutual introduction between SMC-B and SMC-A provides a basis for an efficient symmet-
ric authentication (see Chapter 15.6) with the objective of remote PIN transfer to the SMC-B.
The following is assumed for this introduction:
The SMC-B holds the public key PuK.SMC.AUTD_RPS_CVC. Therefore, the corre-
sponding certificate C.SMC.AUTD_RPS_CVC had to be imported into the SMC-B.
The SMC-A holds the public key PuK.SMC.AUTD_RPE_CVC. Therefore, the corre-
sponding certificate C.SMC. AUTD_RPE_CVC had to be imported into the SMC-A.
A mutual introduction between HPC and SMC-K provides a basis for an efficient symmetric
authentication (see Chapter 15.6) with the objective of transfer of data to be signed to the
HPC. The following is assumed for this introduction:
The HPC holds the public key PuK.SAK.AUTD_CVC. Therefore, the corresponding
certificate C.SAK.AUTD_CVC had to be imported into the HPC.
The SMC-K holds the public key PuK.HPC.AUTD_SUK_CVC. Therefore, the corre-
sponding certificate C.HPC. AUTD_SUK_CVC had to be imported into the SMC-K.
The following steps will be executed (see Figure 12 (N1199.20)):
(N1193.00)
14.9.3.1 sent to the SMC-A or SMC-K via channel 2. The random number generated by
the SMC-A or SMC-K is denoted R.1.
(N1194.00)
14.7.4.1 sent to the HPC or SMC-B via channel 1. Prior to this command, the private
key PrK.HPC.AUTD_SUK_CVC (HPC) or PrK.SMC.AUTD_RPE_CVC (SMC-B) and
the algorithm rsaSessionkey4Intro MUST be selected according to Clause 14.9.6.3.
For the authentication command it MUST apply: cmdData.2 = R.1 || sn.1 with serial
number sn.1 equal to iccsn8 (see (N210.00)c) of the SMC-A or SMC-K. The corre-
sponding response data are denoted rspData.2.
(N1195.00)
The third command MUST be EXTERNAL AUTHENTICATE according to Clause
14.7.1.1 sent to the SMC-A or SMC-K via channel 2. Prior to this command, the public
key PuK.HPC.AUTD_SUK_CVC (of HPC) or PuK.SMC.AUTD_RPE_CVC (of SMC-B)

and the algorithm rsaSessionkey4Intro MUST be selected according to Clause
14.9.6.5. For the authentication command rspData.2 MUST be used as command data.
(N1196.00)
to the HPC or SMC-B via channel 1. The random number generated by the HPC or
SMC-B is denoted R.2.
(N1197.00)
14.7.4.1 sent to the SMC-A / SMC-K via channel 2. Prior to this command, the private
key PrK.SMC.AUTD_RPS_CVC (SMC-A) or PrK.SAK.AUTD_CVC (SMC-K) and the
algorithm rsaSessionkey4Intro MUST be selected according to Clause 14.9.6.3. For
the authentication command it MUST apply: cmdData.5 = R.2 || sn.2 with serial num-
ber sn.2 equal to iccsn8 (see (N210.00)c) of the HPC or SMC-B. The corresponding
response data are denoted rspData.5.
(N1198.00)
AUTHENTICATE according to Clause 14.7.1.1 sent to the HPC or SMC-B via channel
1. Prior to this command, the public key PuK.SMC.AUTD_RPS_CVC (of SMC-A) or
PuK.SAK.AUTD_CVC (of SMC-K) and the algorithm rsaSessionkey4Intro MUST be se-
lected according to Clause 14.9.6.5. For the authentication command rspData.5 MUST
be used as command data.
(N1199.00)
Channel_1
Channel_2
Figure 12: (N1199.20) Sequence Diagram for the Mutual Introduction
15.6 Establishment of a Trusted Channel with Introduction Keys
It is assumed that
either (HPC and SMC-A) or (SMC-B and SMC-A) or (HPC and SMC-K) are involved,

introduction keys were established according to Clause 15.5 between the two in-
volved cards, and
the serial numbers of both cards are known from their files EF.GDO.
The following steps will be executed (see Figure 13 (N1207.20)):
(N1203.00)
14.9.3.1 sent to the SMC-A or SMC-K via channel 2. The random number generated by
the SMC-A or SMC-K is denoted R.1.
(N1204.00)
14.7.4.1 sent to the HPC or SMC-B via channel 1. Prior to this command, the introduc-
tion key with a reference according to (N175.00) and the algorithm desSessionkey4SM
MUST be selected according to Clause 14.9.6.2. For the authentication command it
MUST apply: cmdData.2 = R.1 || sn.1 with serial number sn.1 equal to iccsn8 (see
(N210.00)c) of the SMC-A or SMC-K. The corresponding response data are denoted
rspData.2.
(N1205.00)
The third command MUST be MUTUAL AUTHENTICATE according to Clause 14.7.1.2
sent to the SMC-A or SMC-K via channel 2. Prior to this command, the introduction key
with a reference according to (N175.00) and the algorithm desSessionkey4TC MUST
be selected according to Clause 14.9.6.6. For the authentication command rspData.2
MUST be used as command data. The response data are denoted rspData.3.
(N1206.00)
AUTHENTICATE according to Clause 14.7.1.1 sent to the HPC or SMC-B via channel
1. Prior to this command, the introduction key with a reference according to (N175.00)
and the algorithm desSessionkey4SM MUST be selected according to Clause 14.9.6.4.
For the authentication command rspData.3 MUST be used as command data.
(N1207.00)
H PC SM C-A
Softw are
SMC-B SM C-K
GetChalle nge
Channel_1
Channel_2
In ter nalAuth entica te(cm dData.2=R.1 sn.1). (r spDa ta.1 =R.1, N oErro r).
(r spDa ta.2= en c(R.2 sn .2 R.1 sn.1 KD.2) || MAC, N oErr or)

Mu tualAuthen tica te( rsp Data.2 )
(rspData .3=enc( R.1 sn .1 R.2 sn.2 KD .1) | | MAC, No Er ror )
Exter nalAuth enticate(r spDa ta.3).
(No Er r or)
Figure 13: (N1207.20) Sequence Diagram for the Negotiation of Session Keys with Introduction
Keys.

16 Miscellaneous (normative)
16.1 Algorithm Identifier
Note 1: It is not an easy task to define AlgIds for authentication purposes, if the whole health care area
and also prEN14890 has to be taken into account. In the light of the ongoing discussion about
stack and comfort signatures several options are discussed and must be regarded if applicable.
The following is a trial for a generic approach:.
At the moment I see four possibilities (2 bit) for a private authentication key with respect to ses-
sion keys (SK):
1) Authentication without SK negotiation
2) Authentication with SK negotiation, whereas SKs are NOT stored in a persistent way.
3) Authentication with SK negotiation and storage of the SK as IntroductionKeys.
4) Authentication with SK negotiation and storage of the SK as PairingKeys.
Difference IntroductionKeys to Pairingkeys:
IntroductionKeys are some kind of shortcut with high performance to the asymmetric CV based
authentication, being described in this specification. This shortcut is intended for any of the de-
fined cards (mainly for HPC and SMC). It is not critical to introduce any HPC to any SMC.
ParingKeys are similar to IntroductionKeys, but meant for the pairing between two well defined
smartcards: A concrete HPC with a concrete token for the comfort signature.
Usage of the SKs, two options (1 Bit): Either for Secure Messaging or for PSO commands.
Derivation of SKs, two options (1 Bit): according to the new or to the old version of the specifica-
tion.
SK Type, four options (2Bit): 2TDES, 3TDES, AES-128, AES-256
So for an AlgId of 1 byte 2 bits are remaining for the selection of the authentication mechanism.
With SHA-1 (not used here), SHA-256
Note 2: Proposal for the coding of algorithmIdentifier for the Session key negotiation based on Note 1.
a) AlgId is coded in an octet.
b) Bits b2 b1 are coding the authentication mechanism
00 => process according to this spec.
others out of scope
c) Bits b4 b3 are coding SK Type
00 => 2TDES (not used here, but elsewhere)
01 => 3TDES
10 => AES-128
11 => AES-256
d) Bit b5 is coding the derivation method
0 => [EN14890-1]
1 => Clause 6.2
e) Bit b6 is coding the usage of the SKs (in the future also the SMC shall be prepared for Re-
mote-PIN)
0 => for Secure Messaging
1 => for PSO commands (resp. ENVELOPE)
f) Bits b8 b7 are coding possibilities
00 => no SK negotiation, coding of the remaining bits results from Note 3.
01 => SK negotiation with persistent storage of the SKs
10 => SK negotiation, storage as IntroductionKeys
11 => SK negotiation, storage as PairingKeys
Note 3: Proposal for the coding of algorithmIdentifier for authentication without Session key negotia-
tion.
a) AlgId is coded in one octet.
b) Bits b8 b7 are coding session key negotiation
00 => no SK negotiation, other values are discussed in Note 1.
c) The remaining bits will be set to 0, because at the moment only one method is assigned to
each key type (AES, DES, RSA, ELC).
Table 185: (N1215.00) Generic AlgorithmIdentifier for authentication purposes
Name Generic term for

asymClientAuthentication rsaClientAuthentication
asymRoleAuthentication elcRoleAuthentication, rsaRoleAuthentication
asymRoleCheck elcRoleCheck rsaRoleCheck
asymSessionkey4SM rsaSessionkey4SM
symRoleAuthentication aesRoleAuthentication desRoleAuthentication
symRoleCheck aesRoleCheck desRoleCheck
symSessionkey4SM aesSessionkey4SM desSessionkey4SM
symSessionkey4TC aesSessionkey4TC desSessionkey4TC
Table 186: (N1216.00) Concrete AlgorithmIdentifier for authentication purposes
Name Coding Usage

aesRoleAuthentication 0000 00002 = 00 symmetric, InternalAuth
aesRoleCheck 0000 00002 = 00 symmetric, ExternalAuth
aesSessionkey4SM 0101 01002 = 54 symmetric, MutualAuth
Session keys for Secure Messaging
aesSessionkey4TC 0111 01002 = 74 symmetric, ExternalAuth, InternalAuth,
Session keys for PSO commands
desRoleAuthentication 0000 00002 = 00 symmetric, InternalAuth
desRoleCheck 0000 00002 = 00 symmetric, ExternalAuth
desSessionkey4SM 0101 01002 = 54 symmetric, MutualAuth
Session keys for Secure Messaging
desSessionkey4TC 0111 01002 = 74 symmetric, ExternalAuth, InternalAuth,
rsaClientAuthentication 0000 01012 = 05 InternalAuth, see [EN14890-2] Table 11-1
rsaRoleAuthentication 0000 00002 = 00 asymmetric InternalAuth
rsaRoleCheck 0000 00002 = 00 asymmetric ExternalAuth
rsaSessionkey4Intro 1001 01002 = 94 asymmetric, ExternalAuth and InternalAuth,
Session keys are stored in a persistent way
rsaSessionkey4SM 0101 01002 = 54 asymmetric, ExternalAuth and InternalAuth,
Session keys for SecureMessaging
rsaSessionkey4TC 0111 01002 = 74 asymmetric, ExternalAuth and InternalAuth,
elc
Note: Missing codings are only necessary from generation 2 on.

Table 187: (1217.00) AlgorithmIdentifier for Decipher and Encipher
Name Coding Usage

desSessionkey4TC 0000 00002 = 00 PSO: DECIPHER + ENCIPHER
rsaDecipherOaep 1000 01012 = 85 PSO: DECIPHER with RSA,
rsaDecipherPKCS1_V1_5 1000 00012 = 81 see PI in [EN14890-2] Table 11-3
rsaEncipherOaep 0000 01012 = 05 PSO: ENCIPHER + TRANSCIPHER with RSA, is
rsaEncipherPKCS1_V1_5 0000 00012 = 01 equivalent to the AlgorithmIdentifier for DECI-
PHER mod 128
elcSharedSecretCalculation 0000 10112 = 0B PSO: DECIPHER with ELC, see [EN14890-2]
Table 11-2
Table 188: (N1218.00) AlgorithmIdentifier for Signature Computation and Signature Validation
Name Coding Usage

sign9796_2_DS2 0000 01112 = 07 PSO: COMPUTE DIGITAL SIGNATURE
signPKCS1_V1_5 0000 00102 = 02 PSO: COMPUTE DIGITAL SIGNATURE,
see [EN14890-1] Table 13-1
signPSS 0000 01012 = 05 PSO: COMPUTE DIGITAL SIGNATURE,
see [EN14890-1] Table 13-1
signECDSA PSO: COMPUTE DIGITAL SIGNATURE
verifyCertificate XX certificate validation; because this identifier will
never appear at the physical interface, it is not
necessary to define it here
Note 1: The algorithmIdentifier for sign9796_2_DS2 is not defined in this document, because the sig-
nature scheme DS2 from [ISO9796-2] in [EN14890-1] will not be covered.
Note 2: Missing codings are only necessary from generation 2 on.

16.2 Coding for Trailer
Table 189: (1219.00) Trailer Names for errors
Value Name Meaning

62 81 CorruptDataWarning The integrity of response data cannot be guaranteed
62 82 EndOfFileWarning More data were requested than available in the file
62 82 EndOfRecordWarning More data were requested than available in the record
62 82 UnsuccessfulSearch Pattern not found in any of the adressed records
62 83 FileDeactivated File, defined for the operation is deactivated
62 87 RecordDeactivated Record, defined for the operation is deactivated
62 Cx TransportStatus Indication for a transport protection method
63 CF NoAuthentication No authentication with the referenced key
63 Cx RetryCounter Value of the retry counter
63 Cx UpdateRetryWarning Problems with writing
63 Cx WrongSecretWarning Wrong password in the command data
63 00 AuthenticationFailure Authentication failed
64 00 CurveNotFound Domainparameter of the elliptical curve not found
64 00 EncipherError Incorrect enciphering operation
64 00 KeyAlreadyPresent Key data already present, generation impossible
64 00 KeyInvalid Key data missing,generation necessary
65 81 MemoryFailure Write error
67 00 WrongRecordLength Wrong record length
68 81 ChannelClosed Logical channel not opened
68 81 NoMoreChannelsAvailable No further logical channel available
69 81 WrongFileType File does not support the current command
69 83 CommandBlocked Reset of the retry counter no longer possible
69 85 NoKeyReference Key reference missing, MSE: SET is necessary
69 85 NoPrkReference Key reference missing, MSE: SET is necessary
69 85 NoPukReference Key reference missing, MSE: SET is necessary
69 85 NoRandom No random number, GET CHALLENGE is necessary
69 85 NoRecordLifeCycleStatus File does not support the current command
69 85 PasswordNotUsable Transport protection active, CHANGE REF. DATA is necessary
69 85 ShortPassword New password too short
69 86 NoCurrentEF Execution of the command impossible: no data are selected
69 88 IncorrectSmDo incorrect Secure Messaging
6A 80 VerificationError incorrect CV-certificate
6A 80 WrongCiphertext incorrect cryptogram
6A 82 FileNotFound referenced file not found
6A 83 RecordNotFound Referenced record not usable
6A 84 DataTooBig Too many data
6A 84 FullRecordList Record list already filled completely
6A 84 OutOfMemory Not enough memory
6A 88 InconsistentKeyReference Key reference in CV-certificate incorrect
6A 88 KeyNotFound Referenced key not found
6A 88 PasswordNotFound Referenced password not found
6A 88 PrKNotFound Referenced key not found
6A 88 PukNotFound Referenced key not found
6A 89 DuplicatedObject The object to be created exists already
6A 8A DfNameExists The application to be created exists already
6B 00 OffsetTooBig Offset too large
90 00 NoError Normal command execution, no error, no warning

HPC-Spezifikation 2.3.2 - COS Teil 1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

HPC-Spezifikation 2.3.2 - COS Teil 1

Uploaded by

Copyright:

Available Formats

Specification

Part 1: Commands, Algorithms and Functions

HPC Part 1 COS, V2.3.2 Page 1 of 278

The HPC specification consists of the following parts:

Part 1: Commands, Algorithms and Functions of the COS Platform

HPC Part 1 COS, V2.3.2 Page 2 of 278

Date Version Modifications

HPC Part 1 COS, V2.3.2 Page 3 of 278

1 Purpose and Scope......................................................................................11

3 Abbreviations and Notation ........................................................................17

4 Life Cycle of a smartcard and the applications (informative) .................24

5 Data Types and Data Conversion ...............................................................25

6 Cryptographic Algorithms (normative) ......................................................33

8 Objects (normative) .....................................................................................60

HPC Part 1 COS, V2.3.2 Page 6 of 278

9 Object System (normative)..........................................................................85

10 Access Control (normative) .....................................................................94

11 Communication (normative) ....................................................................98

12 Channel Context (normative).................................................................112

13 Secured Communication (normative) ...................................................118

15 Authentication Protocols (normative)...................................................263

HPC Part 1 COS, V2.3.2 Page 10 of 278

1.2 Structure of this document

Clause 1: Introduction: contains information how to work with this document

Clause 6: Cryptographic algorithms (normative): defines some basic cryptographic func-

Clause 7: CV-Certificates (normative): describes certificates which will be used to import

Clause 14: Commands (normative): contains normative statements to commands which

Chapter 15: Authentication Protocols (normative): describes the sequences containing

1.3 Target Group

1.4 Area of validity

1.5 Working Basis

1.6 Scope of this document

HPC Part 1 COS, V2.3.2 Page 13 of 278

HPC Part 1 COS, V2.3.2 Page 14 of 278

HPC Part 1 COS, V2.3.2 Page 15 of 278

HPC Part 1 COS, V2.3.2 Page 16 of 278

HPC Part 1 COS, V2.3.2 Page 17 of 278

HPC Part 1 COS, V2.3.2 Page 18 of 278

HPC Part 1 COS, V2.3.2 Page 19 of 278

Table 1: (N0.10) prefixes, based on multiples to the power of 10

Name Symbol Value according to SI Next multiple to the power of 2

The following table is based on [BinPrefix].

Name Symbol Value

3.3 Notation of Attributes and Values

HPC Part 1 COS, V2.3.2 Page 20 of 278

3.4 Notation of Keys and Certificates

<object descriptor> ::= <key descriptor> | <certificate descriptor>

<key descriptor>::= <key>.<keyholder>.<key usage>

<key>::= <private key> | <public key> | <secret key>

<private key>::= PrK (asym.)

<keyholder>::= <health professional> | <card holder> | <certification authority> |

<health professional card>::= HPC

<key usage>::= <organizational signature> | <encipherment> | <authentication> |

<authentication>::= AUT | <cv based authentication>

<cv based authentication>::= <role authentication> | <device authentication>

<remote pin Sender>:: = AUTD_RPS_CVC (Remote PIN Sender)

3.5 Use of Key Words

HPC Part 1 COS, V2.3.2 Page 22 of 278

3.6 Normative and informative clauses

HPC Part 1 COS, V2.3.2 Page 23 of 278

3. Termination phase: If a smartcard is in the termination phase all intended applications of

HPC Part 1 COS, V2.3.2 Page 24 of 278

5.1 BitLength Number of bits in a Bit String

Input: in Bit string with any content and any length