Anssi Profil PP 2015 01à06

Point oof Interraction
n
Protection Profile
P
Datee: 6th March 2015

V
Version: 4.0
0
POI P
Protection Profile
Historyy table
Versionn Com
mments
4.0 Upddate from lasst published version 2.0. Includes new
w security reequirements
m [EPC B4]], in particu
from ular addition
n of the “Op pen Protocools pack-
agee” and the “SRED moddule”
th
Page 2 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
Table oof contents

1 PR
ROTECTION TION ........................................................................................... 7
N PROFILE INTRODUCT
I
1.1 PROTECTION PROFILE IDENTIFICATION ........................................................................................................ 7
1.1.1 Identificcation of PED D-ONLY base P PP ............................................................................................... 7
1.1.2 Identificcation of POI--COMPREHE ENSIVE base PP P .......................................................................... 8
1.1.3 Identificcation of POI--CHIP-ONLY Y base PP...................................................................................... 8
1.1.4 Identificcation of SRED D PP Modulee (SRED PP-M Module) ................................................................... 8
1.1.5 Identificcation of the Package
P SFR--supporting feeatures related d to Open Prootocols ........................ 9
1.2 PROTECTION PROFILE PRESENTATION ........................................................................................................ 10
1.3 REFERENCES ................................................................................................................................................ 13
2 PO EWORK ............................................................................................................................... 14
OI PP FRAME
2.1 ““OPEN PROTO
OCOL PACKAGE” .................................................................................................................... 14
2.2 SSRED PP-MODULE
O ..................................................................................................................................... 14
3 TO EW ......................................................................................................................................... 16
OE OVERVIE
3.1 TTOE TYPE ................................................................................................................................................... 16
3.2 TTOE SECURITTY FEATURES ......................
. ................................................................................................... 17
3.2.1 Genericc POI ................................... .................................................................................................. 18
33.2.1.1 Geneeric Payment Trransaction Proceess ........................................................................................................ 18
33.2.1.2 Geneeric Terminal Management
M Proocess ..................................................................................................... 19
33.2.1.3 Geneeric POI Architeecture .............. ............................................................................................................. 19
33.2.1.4 Geneeric POI Architeecture Compone nents ...................................................................................................... 20
33.2.1.5 POI Example
E .................................. ............................................................................................................. 22
3.2.2 Securityy features ............................. .................................................................................................. 24
33.2.2.1 Securrity features in each base PP... ............................................................................................................. 30
3.3 NON-TOE HARDWARE
A / SOFFTWARE/ FIRM MWARE AVAIL LABLE TO THE TOE............................................... 31
3.4 TTOE USAGE ................................................................................................................................................ 32
3.5 T CLE ......................................................................................................................................... 32
TOE LIFE CYC
3.5.1 Developper phase ............................. .................................................................................................. 32
33.5.1.1 Deveelopment and Manufacturing
M .. ............................................................................................................. 32
33.5.1.2 Initiaal Software and Cryptographic Key Loading ....................................................................................... 33
3.5.2 User phhase...................................... .................................................................................................. 33
33.5.2.1 Installlation ...................................... ............................................................................................................. 34
33.5.2.2 Acquuirer Initialisatio on .................... ............................................................................................................. 34
33.5.2.3 Use by
b merchant and d customer ...... ............................................................................................................. 34
33.5.2.4 o life ....................................... ............................................................................................................. 35
End of
4 CO
ONFORMAN S ....................................................................................................................... 36
NCE CLAIMS
4.1 CONFORMANC C .................................................................................................................... 36
CE CLAIM TO CC
4.2 CE CLAIM TO A PACKAGE ....................................................................................................... 36
CONFORMANC
4.3 CONFORMANC
CE CLAIM OF THE
T PP .............................................................................................................. 36
4.4 CONFORMANC
CE CLAIM TO THE
T PP .............................................................................................................. 36
5 SEC
CURITY PR EFINITION ..................................................................................................... 37
ROBLEM DE
5.1 ASSETS ........................................................................................................................................................ 37
5.1.1 Assets in each base PP P .................. .................................................................................................. 43
5.2 USERS.......................................................................................................................................................... 44
5.2.1 Authoriised Human Users U .............. .................................................................................................. 44
5.2.2 Externaal Entities ............................. .................................................................................................. 45
5.2.3 Users inn each base PP P ................... .................................................................................................. 46
5.3 SUBJECTS .................................................................................................................................................... 46
5.3.1 Subjectss in each basee PP............... .................................................................................................. 48
5.4 THREATS ..................................................................................................................................................... 48
5.4.1 Threatss in each base PP ................ .................................................................................................. 52
5.5 ORGANISATIO ONAL SECURIT TY POLICIES ...................................................................................................... 53
5.5.1 OSP in each base PP P..................... .................................................................................................. 54
th
6 March, 2015 Version 4.0
4 Page 3
POI P
Protection Profile
5.6 ASSUMPTIONSS ............................................................................................................................................. 54
5.66.1 Assumpptions in each base PP ........ .................................................................................................. 54
6 SEC
CURITY OB ................................................................................................... 55
BJECTIVES ......................
.
6.1 SECURITY OBJECTIVES
B FORR THE TOE ......................................................................................................... 55
6.1.1 Securityy objectives fo
or the TOE in each base PP P ............................................................................ 62
6.2 SECURITY OBJECTIVES
B FORR THE OPERATIIONAL ENVIRO ONMENT ................................................................ 63
6.2.1 Securityy objectives fo
or the TOE envvironment by base PPs.............................................................. 65
7 RA
ATIONALE BETWEEN
B SPD
S AND SE CURITY OB ................................. 66
BJECTIVES ......................
.
7.1 THREATS ..................................................................................................................................................... 66
7.2 OSP ............................................................................................................................................................. 69
O
7.3 ASSUMPTIONSS ............................................................................................................................................. 69
7.4 RATIONALE APPLICABLE
A TOO PED-ONLY Y CONFIGURATION ....................................................................... 69
A TOO POI-COMPR REHENSIVE CONFIGURATIION ................................................. 73
A TOO POI-CHIP-O ONLY CONFIG GURATION.............................................................. 75
8 EX
XTENDED RE ENTS ................................................................................................................ 77
EQUIREME
8.1 DEFINITION OF THE FAMILY
Y FCS_RND ..................................................................................................... 77
Y FPT_EMSEC C ............................................................................................... 77
Y AVA_POI...................................................................................................... 78
9 SEC
CURITY RE NTS .................................................................................................................. 82
EQUIREMEN
9.1 SECURITY FUN NCTIONAL REQUIREMENTS .................................................................................................... 82
9.1.1 Definitiion of SFR pacckages ........... .................................................................................................. 85
99.1.1.1 PIN Entry
E Package.......................... ............................................................................................................. 85
99.1.1.2 ENC__PIN Package ........................
. ............................................................................................................. 88
99.1.1.3 PLAIIN_PIN Packag ge ..................... ............................................................................................................. 93
99.1.1.4 IC Caard Reader Pack kage ................ ............................................................................................................. 96
99.1.1.5 POI__DATA Package ..................... ........................................................................................................... 100
99.1.1.6 CoreTTSF Package ........................... ........................................................................................................... 105
99.1.1.7 PEDM MiddleTSF Pacckage ............... ........................................................................................................... 108
99.1.1.8 MidddleTSF Packagee ...................... ........................................................................................................... 110
99.1.1.9 PED Prompt Contro ol Package........ ........................................................................................................... 113
99.1.1.10 Crryptography Paackage ............. ........................................................................................................... 115
99.1.1.11 Phhysical Protectiion Package ..... ........................................................................................................... 118
9.1.2 Securityy Functional Requirements
R in each base PP ...................................................................... 120
9.1.3 Securityy Functional Requirements
R dependenciess rationale .......................................................... 121
9.2 SECURITY ASSURANCE REQ QUIREMENTS ................................................................................................... 122
9.2.1 Securityy Assurance Requirements
R Rationale ................................................................................. 123
R
9.2.2 Refinedd security assu
urance requireements ...................................................................................... 124
99.2.2.1 ADV
V_FSP Functionnal Specificationn ......................................................................................................... 124
99.2.2.2 V_TDS Basic deesign ................ ........................................................................................................... 125
ADV
99.2.2.3 ADV
V_ARC Securityy Architecture . ........................................................................................................... 126
99.2.2.4 AGD
D_OPE Operatioonal user guidannce ..................................................................................................... 128
99.2.2.5 D_PRE Preparattive procedure . ........................................................................................................... 131
AGD
99.2.2.6 ALC__CMC CM cap pabilities .......... ........................................................................................................... 131
99.2.2.7 ALC__CMS CM Sco ope ................... ........................................................................................................... 132
99.2.2.8 y ...................... ........................................................................................................... 132
ALC__DEL Delivery
99.2.2.9 ALC__DVS Developpment Security . ........................................................................................................... 133
99.2.2.10 A
ALC_FLR Flaw Remediation .. ........................................................................................................... 135
99.2.2.11 A
ATE_IND Indeppendent testing - sample ............................................................................................. 136
9.2.3 Extendeed security asssurance requiirements ................................................................................... 137
99.2.3.1 A_POI applied to MSR ............ ........................................................................................................... 137
AVA
99.2.3.2 A_POI applied to MiddleTSF .. ........................................................................................................... 138
AVA
99.2.3.3 AVA
A_POI applied to PEDMiddleT TSF ...................................................................................................... 140
99.2.3.4 A_POI applied to IC Card Readder TSF ............................................................................................... 141
AVA
99.2.3.5 A_POI applied to CoreTSF ...... ........................................................................................................... 142
AVA
99.2.3.6 AVA
A_POI applied to the CoreTSFK Keys ................................................................................................... 143
9.2.4 Securityy Assurance Requirements
R Dependenciess .......................................................................... 144
D
th
Page 4 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
10 RA ES/SFR ........................................................................................................... 146
ATIONALE OBJECTIVE
O
11 LOSSARY ................................................................................................................................................. 156
GL
12 DE
EFINITION OF
O THE SRE ULE ........................................................................................ 162
ED PP-MODU
12.1 SECURITY PROBLEM DEFFINITION ......................................................................................................... 162
12.1.1 Assets ......................................... ................................................................................................ 162
12.1.2 Userrs / Subjects ......................... ................................................................................................ 165
12.1.3 Threeats ....................................... ................................................................................................ 165
12.1.4 Orgaanisational Seecurity Policiees .............................................................................................. 165
12.1.5 Assuumptions ............................... ................................................................................................ 165
12.2 SECURITY OBJECTIVES ......................................................................................................................... 165
12.2.1 Secuurity Objectivees for the TOE E ............................................................................................... 165
12.2.2 Secuurity objectivess for the Operrational Envirronment............................................................... 166
12.2.3 Secuurity Objectivees Rationale... ................................................................................................ 166
12.3 EXTENDEDD REQUIREMEN NTS ................................................................................................................. 166
12.4 SECURITY REQUIREMENTS................................................................................................................... 167
12.4.1 Secuurity Functiona al Requiremennts............................................................................................ 167
12.4.1.1 RED Basis Package ................ ........................................................................................................... 169
SR
12.4.1.2 RED Cryptograaphy Package .. ........................................................................................................... 176
SR
12.4.1.3 RED Distributeed Architecture Package ............................................................................................. 179
SR
12.4.1.4 SR
RED End-to-ennd protection Paackage................................................................................................. 182
12.4.1.5 RED Surrogate PAN Package ........................................................................................................... 187
SR
12.4.2 Secuurity Assurancce Requiremennts ............................................................................................ 189
12.4.2.1 Refinements for SARs defined ffor the SRED PP-Module
P .................................................................. 190
12.4.3 ments Rationalle.............................................................................................. 192
Secuurity Requirem
12.4.3.1 Objectives .................................. ........................................................................................................... 192
12.4.3.2 Rationale table of o Security Objeectives and SFR Rs ............................................................................... 193
12.4.3.3 Dependencies ............................ ........................................................................................................... 194
12.4.3.4 Rationale for the Security Assurrance Requirem ments........................................................................... 197
12.5 RATIONALE OF CONSISTE
ENCY OF THE S
SRED PP-MODULE
O HE BASE PPS ................................. 197
WITH TH
13 AN
NNEX – EPC BOOK 4 TO N CRITERIA ........................................................................... 199
O COMMON
13.1 EPC BOOK
K 4 SECURITY REQUIREMENTTS ............................................................................................ 199
13.2 MAPPING FROM
F EPC BOOK
O 4 TO SFRS AND SARS ............................................................................. 211
14 AN
NNEX – RELA
ATIONSHIP
P BETWEEN
N AVA_POI AND
A AVA_V LIES ..................... 215
VAN.2 FAMIL
th
4 Page 5
POI P
Protection Profile
Table oof figures

Figure 11: POI Fram mework – Prrocess Flow w .................................................................................. 15
Figure 22: Relationss between various definnitions and chapters c in this PP.................................. 17
Figure 33: Generic POI
P Paymen nt Transactiion Process ................................................................ 18
P Architeecture ............................................................................................. 20
Figure 44: Generic POI
Figure 55: TOE in PED-ONLY
P Y configurati tion .............................................................................. 22
Figure 66: TOE in POI-COMPR
P REHENSIV VE configurration........................................................ 23
Figure 77: TOE in POI-CHIP-O
P ONLY confi figuration..................................................................... 24
Figure 88: TSF struccture in PED D-ONLY coonfiguration n ............................................................... 25
Figure 99: TSF struccture in POII-COMPRE EHENSIVE configuratiion ........................................ 26
Figure 110: TSF struucture in PO OI-COMPR REHENSIVE E configuraation with aadopted SRE ED PP-
Module ................................................................................................................................... 26
Figure 111: TSF struucture in PO OI-CHIP-ON NLY config guration ................................................... 27
Table oof tables
Table 1: TSF decom mposition by b base PP ...................................................................................... 30

Table 2: Physical boundaries
b of
o TSF partss by base PP P .............................................................. 31
Table 3: Assets sennsitivity ............................................................................................................ 38
Table 4: Assets by base PP ........................................................................................................... 44
Table 5: Users by base
b PP ............................................................................................................ 46
Table 6: Subjects byb base PP........................................................................................................ 48
Table 7: Threats byy base PP ......................................................................................................... 53
Table 8: Objectivess for the TO OE by base P PP ............................................................................... 63
Table 9: SPD coverage by objectives in P PED-ONLY Y configuration ........................................ 72
Table 10: SPD covverage by ob bjectives in POI-COMP PREHENSIIVE configuuration ................ 74
Table 11: SPD covverage by ob bjectives in POI-CHIP--ONLY con nfiguration ............................. 76
Table 122: Entities definition
d in
n Security F Function Policies........................................................ 85
Table 13: SFR packkages included in eachh base PP ................................................................... 121
Table 144: Definitioon of EAL POI P by basee PP ........................................................................... 123
Table 15: SAR deppendencies ..................................................................................................... 145
Table 16: Objectives coveragee by SFRs .................................................................................... 149
Table 17: SFR packkages in thee SRED PP--Module ................................................................... 168
Table 18: Security Objectives and SFRs iin SRED- Coverage C ................................................. 193
Table 19: SFRs Deependenciess in the SRE ED PP-Mod dule ......................................................... 195
th
Page 6 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
1 Prootection Pro
ofile Introd
duction
1 Thiss documentt defines six x base Proteection Profifiles dedicatted to paym

ment terminaals, each
for a different terminal
t variant. The ffirst three of these are PED-ONLY
P Y applicable to PIN
Entrry Devices (PED), and d POI-COM MPREHENS SIVE and POI-CHIP-O ONLY appliicable to
Poinnt of Interacction (POI). The secondd set of threee base PPs consists off the same th
hree var-
iantss, but in each case enhhanced by a package called “Open n protocol ppackage”. How
H this
enhaancement iss done, is exxplained in section 2.1 later on.
2 In thhe followingg, “this Protection Proffile” stands for the Pro
otection Proofile collectiion com-
poseed of these six base Prrotection Prrofiles. In the
t later tex xt of this PPP, many deefinitions
are only descriibed for thee first threee of these base
b PPs, since
s these definitionss are not
channged by thee addition off the “Openn protocol paackage”.
3 In addition to thhese six basse PPs a moodule in the sense of [PPP Mod] thee SRED PP-Module
is deefined, whicch may be added
a to fouur of the six
x base PPs listed
l abovee. How this is done,
is exxplained in section 2.1 later on.
1.1 Prottection Pro

ofile Identiffication
1.1.1 Iden
ntification of
o PED-ON
NLY base PP
P
Title Point of Inteeraction Prootection Pro

P ofile – PED--ONLY basse PP
Identifi
fication A
ANSSI-CC- -PP-POI-PE ED-ONLY
Authorrs S
Sandro Ameendola, SRC C Security Research
R & Consultingg GmbH
C
Carolina Laavatelli, Truusted Labs
T
Tony Boswell, SiVentuure
o behalf off OSeC (Oppen Standard
on ds for Securrity and Cerrtification)
Versionn 44.0
Publicaation 6th March, 2015
2
Date
Sponsoor ANSSI
A
CC Verrsion 3 Revision
3.1 n4
th
4 Page 7
POI P
Protection Profile
1.1.2 Iden
ntification of
o POI-CO
OMPREHE
ENSIVE basse PP
Title Point of Interaction Prootection Pro

P ofile – COM
MPREHENSSIVE base PP
P
Identifi
fication A
ANSSI-CC -PP-POI-CO OMPREHE ENSIVE
Authorrs S
Sandro Ammendola, SRC C Security Research
C
T
Tony Bosw
well, SiVentuure
o behalf off OSeC (Oppen Standarrds for Security and Cerrtification)
on
Versionn 44.0
2
Date
Sponsoor ANSSI
A
CC Verrsion 3 Revision 4
3.1
1.1.3 Iden
ntification of
o POI-CH
HIP-ONLY base PP
Title Point of Interaction Prootection Pro

P ofile – POI-CHIP-ONL LY base PP
Identifi
fication A
ANSSI-CC -PP-POI-CH HIP-ONLY Y
Authorrs S
Sandro Ammendola, SRC C Security Research
C
T
Tony Bosw
well, SiVentuure
o behalf off OSeC (Oppen Standarrds for Security and Cerrtification)
on
Versionn 44.0
2
Date
Sponsoor ANSSI
A
CC Verrsion 3 Revision 4
3.1
1.1.4 Iden
ntification of
o SRED P
PP Module (SRED PP--Module)

P ofile – SREDD PP Moduule
Identifi
fication A
ANSSI-CC- -PP-POI-SR RED-PP-Mo odule
Authorrs C
Carolina Laavatelli, Guiillaume Tétuu, Trusted Labs
L
Versionn 44.0
2
Date
Sponsoor ANSSI
A
3.1 n4
th
Page 8 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
1.1.5 Iden
ntification of
o the Pack
kage SFR-ssupporting features reelated to Op
pen
Prottocols

P ofile – Package of SFR
R-supporting
g fea-
t
tures related
d to Open PProtocols
Identifi
fication A
ANSSI-CC- -PP-POI-Oppen-Protoco ols
Authorrs S
Sandro Ameendola, SRC C Security Research
C
T
Tony Boswell, SiVentuure
Versionn 44.0
2
Date
Sponsoor ANSSI
A
3.1 n4
Note thaat the three base PPs deerived from

m the three base
b PPs already defineed in section
ns 1.1.1,
1.1.2 annd 1.1.3 by adding
a this “Open prottocol packag ge” can now
w be identiffied uniquely as fol-
lows:
 A
ANSSI-CC-PP-POI-PE
ED-ONLY + ANSSI-C
CC-PP-POI--Open-Protoocols,
 A
ANSSI-CC-PP-POI-CO
OMPREHE
ENSIVE + ANSSI-CC-
A -PP-POI-Oppen-Protoco
ols,
 A
ANSSI-CC-PP-POI-CH
HIP-ONLY
Y + ANSSI-CC-PP-POII-Open-Prottocols.
Note alsso that the four
f configu
urations derrived from th
he base PPss by adding the “SRED
D PP
module”” can be ideentified uniq
quely as folllows:
 A
ANSSI-CC-PP-POI-PE
ED-ONLY + ANSSI-C
CC-PP-POI--SRED-PP--Module,
 A
ANSSI-CC-PP-POI-CO
OMPREHE
ENSIVE + ANSSI-CC-
A -PP-POI-SR
RED-PP-Mo
odule,
 A
ANSSI-CC-PP-POI-PEED-ONLY + ANSSI-C
CC-PP-POI--Open-Protoocols + ANSSI-
C
CC-PP-POII-SRED-PP-Module,
 A
ANSSI-CC-PP-POI-CO
OMPREHE ENSIVE + ANSSI-CC-
A -PP-POI-Oppen-Protoco
ols +
A
ANSSI-CC-PP-POI-SR
RED-PP-M
Module.,
Note thhat the “SRE
ED PP mod
dule” can nneither be used
u with th
he “ANSSI--CC-PP-PO
OI-CHIP-
ONLY”” base PP nor with the
t “ANSS SI-CC-PP-P POI-CHIP-O ONLY + AANSSI-CC-PP-POI-
Open-Protocols” baase PP.
Since thhere are six base PPs an
nd four conffigurations using the “S
SRED PP m
module”, an
n ST au-
thor cann claim one of ten possible variantts.
th
4 Page 9
POI P
Protection Profile
1.2 Prottection Pro
ofile Presen
ntation
4 Thiss Protectionn Profile (PP

P) was deveeloped by thhe Open Staandards for Security an nd Certi-
ficattion (OSeC
C) body in co o-operationn with the Jo
oint Interpreetation Librrary Termin
nal Eval-
uatioon Subgrouup (JTEMS)) to be used for the Com mmon Criteeria (CC) evvaluation off Point of
Interaction. Eurropean Payment Counncil (EPC) security requ uirements [E EPC B4], chap.
c 2.6
- whhich includde Paymentt Card Induustry Paymeent Transacction Securrity (PCI POS PTS
v4.00) requirements as welll as securitty requiremments on payyment transsaction dataa and ex-
ternnal communnication - haave been traanslated into
o CC functioonal and as surance seccurity re-
quirrements.
5 The products inn the scope of this Prottection Proffile are paym ment terminnals with Inntegrated
Circcuit (IC) Caard based online
o and ooffline tran
nsaction cappabilities. Prroducts ran
nge from
simpple PED wiith PIN key ypad, displayay and IC an nd Magnetic Stripe Caard Readers to com-
pletee terminals (POI) that manage traansaction data d and pro ovide externnal commun nications
capaabilities. Otther functio onalities thaan paymentt, which might be proccessed by the t same
deviice, e.g. fleeet card proccessing, are out of scoppe of this PP
P.
6 The usage of this
t PP is in
ntended to achieve CC C evaluationns/certificattions, which
h can be
usedd multiple times
t for approvals off payment schemes
s paarticipating in the Singgle Euro
Paymment Area (SEPA)
( cerrtification frramework.
7 Privvacy shieldiing does no ot belong too the Targeet of Evaluaation (TOE)). Moreover, as the
paym ment appliccations currrently still ddiffer from scheme to scheme thhe payment applica-
tionns are also excluded
e froom the TOE E in this PPP. Ideally, on
nly the secuurity featurees of the
deviice to be ussed by paym ment appliccations (succh as libraries for the uuse of criticcal func-
tionns like contrrol of the diisplay and tthe keypad)) are in the scope of thhe TOE wheereas the
paym ment appliccations them mselves aree assigned to the env vironment. The TOE includes
paym ment appliccation separration mechhanisms, seecure software downlooad and upd date and
secuurity featurees that proteect the interrfaces of thee device. With this apprroach, the state
s ma-
chinne controllinng the paym ment transaaction flow is not part of the TOE E. Nevertheeless, the
scoppe of the TO OE can be extended
e w
within a speccific producct evaluationn to cover payment
p
appllication; in this
t case, th he security ttarget shall address pay yment appliccation issuees.
8 It haas to be nooted that the security ccertification
n is only onne input forr the appro oval of a
prodduct in a specific paymment schemee. Another input
i is e.g. the functioonal certificcation of
the device, in which
w for instance
i thee transaction flow of the
t paymennt applicatio on is ad-
dresssed.
9 For the optionaal protection
n of specificc assets a modular
m approach has bbeen chosen
n. Thus a
selected base PP given in i this doccument can be extend ded by the ‘Secure-Reead-and-
Exchange-Dataa (SRED) PP-module
P ddefined in section
s 12. This
T PP-moodule coverrs the set
of P
PCI PTS reqquirements K which aare related to t account data
d protecttion. Depennding on
the aaddressed security prob
blem the veendor may choose
c this option
o or noot.
10 pen Protocools1 are pro
In aaddition opttional SFR--supporting features reelated to Op ovided in
the assurance part
p of this document. The SFR-ssupporting features
f aree refinements of the
assuurance compponents. A base PP caan claim thee fulfilmentt of these SSFR-supportting fea-
1A set off requirementss that ensures POI using oppen security prrotocols and open communiication protoccols to ac-
cess publlic networks annd services do
o not have pubblic domain vulnerabilities.
th
Page 10 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
tures. Thereforee the SFR-ssupporting ffeatures are seen as a package. Theese SFR-supporting
assuurance refinnements cov ver the set oof PCI PTS
S requiremeents F-J. If Open Proto
ocols are
usedd in the TOE E then the vendor
v may chose this option or noot.
11 Thiss Protectionn Profile deffines six basse PPs, each
h of them with
w a particuular TOE:
 PED-ON NLY base PP: The T TOE provid des protectio on for bothh IC and Magnetic
M
Stripe card
c based trransactions.. It does nott manage transaction ddata nor prov vide any
on-line communicaation facilityy to an acqu uirer. The TOET is fullyy conformaant to the
set of PCI
P POS PT TS v4.0 reququirements A-D,
A L and d M. Note thhat the TOE E of this
base PP P is the PED
P part oof a POI. This base PP has bbeen introd duced to
acknowwledge the current
c suppply chain of
o POIs, wh here PEDs are often manufac-
m
tured seeparately ass componennts of a bro oader POI. The aim off this base PP is to
support a POI composite evaluuation for sp pecific use case scenarrios of mercchants or
other POOI vendors. Evaluationn against th his base PP will not inn itself secu ure com-
mon appproval across all OSeC C member markets
m 2 . Th
he PED-ON NLY base PP P is suit-
able to be
b extended d by the SR
RED PP-Mo odule accord ding to [PP Mod] in seection 12
coveringg the set of PCI PTS reequirementss K.
 PED-ON NLY and Open
O protoccol base PP: This fully
y incorporattes the PED
D-ONLY
base PP
P and corressponds to a compliancce with the sets of PCII PTS requiirements
A-D, F--J, L and M.
M The PED D-ONLY and d Open prootocol base PPP extendeed by the
SRED PP-Module
P in section 12 correspo
onds to a coompliance wwith the sets of PCI
PTS reqquirements A-D,
A F-J, K
K, L and M.
 POI-CO OMPREHEN NSIVE basse PP: This base PP fully incoorporates th he PED-
ONLY base PP. Th herefore thee TOE prov vides protecction for botth IC and Magnetic
M
Stripe card
c based transactions
t s and is fullly conform
mant to the set of PCI PTS re-
quiremeents A-D, L and M. Inn addition to o the PED-ONLY cappabilities it provides
p
paymennt transactio on data mannagement and a external communiication facillities for
interactiion with the Acquirer defined by y OSeC. PO OI-COMPRE REHENSIVE E is pre-
pared too be extend ded by the SSRED PP-M Module according to [PPP Mod] in n section
12 coveering the seet of PCI P PTS requireements K. The POI-C COMPREHE ENSIVE
base PPP extended by the SRE ED PP-Mod dule in secttion 12 andd the Open Protocol
SFR-suppporting feaatures (if OOpen Protoccols are supported) corrresponds to o a com-
pliance with PCI PTSP requireements A-D D, K, L and M and com mpliance wiith addi-
tional seecurity requ
uirements off other OSeC memberss.
 The POOI-COMPRE EHENSIVE E and Open protocol baase PP: Thiis fully inco orporates
the POII-COMPRE EHENSIVE base PP. If I this base PP is extenended by th he SRED
PP-Moddule in secttion 12, it ccorrespondss to a comp pliance withh PCI PTS require-
ments A-D,
A F-J, K,, L and M aand compliaance with ad dditional seecurity requiirements
of otherr OSeC meembers. Thee POI-COM MPREHENS SIVE and O Open Protocol base
PP extended by thee SRED PP P-Module in n section 12
2 covers a hharmonized superset
of all security requirements w which are considered
c appropriatee to defend d against
current and perceivved future thhreats. The aim of this configuratiion is to sup
pport the
2 In otherr words: The PED-ONLY

P configuration
c iis meant to su
upport a model, where a PED
D is used in several
different POIs without the need to ree-evaluate thee PED each tim me. Approval for a paymentt system is giv
ven only
for compllete POIs in most
m cases; theerefore the PE ED may not geet an approval of its own, buut its CC-certiificate
may be ree-used in the approval
a process for severaal POIs.
th
4 Page 11
POI P
Protection Profile
conceptt of the POOI as a univversal accep ptor for SE
EPA compliiant cards. It is the
baselinee configurattion that is intended to
o secure com
mmon approoval across all CAS
memberr markets.
 POI-CH HIP-ONLY base PP: T This TOE provides
p prootection forr IC based transac-
tions, payment
p trannsaction daata managem ment and external
e commmunicatio on facili-
ties. The only diffeerences to thhe POI-COM MPREHEN NSIVE basee PP are the absence
of hardwware security requirem ments for thee protectionn of the PIN N as well ass the ab-
sence of support fo or the proteection of offfline plainttext PIN annd for the Magnetic
M
Stripe Reader. The T POI-CH HIP-ONLY Y base PP P is a subbset of th he POI-
COMPR REHENSIV VE base PP P. Therefoore it is not
n compliaant with th he POI-
COMPR REHENSIV VE base PP. The aim off this varian pport of the business
nt is the supp
needs of
o payment schemes, w which suppo ort a chip onnly environnment and area using
encrypteed PIN onlly. Note thaat as a conssequence, the POI-CH HIP-ONLY base PP
does noot rely on thhe robustneess of the IC Card Reaader. This cconfiguratio on is in-
tended to
t lead to a common seecurity certiification of payment scchemes bein ng in this
migratioon phase. SRED
S is nott expected to be used in combinaation with the t chip-
only appproach and d its definitiion thereforre does not assume thee POI-CHIP P-ONLY
base PPP as a possib
bility.
 POI-CH HIP-ONLY and Open protocol baase PP: This fully inccorporates the t POI-
CHIP-O ONLY base PP and addditionally co overs the sett of PCI PT
TS requirements F-J.
SRED is i not expeccted to be uused in com
mbination wiith the chipp-only appro
oach and
its definnition thereffore does nnot assume the POI-CHHIP-ONLY and Open protocol
base PPP as a possibbility.
12 JTEEMS will revview and asssess threatss to determiine the valid
dity or needd for any fu
uture col-
lectiion of securrity requirem
ments.
13 Thiss Protectionn Profile deffines a speccific evaluattion packagee, called EA AL POI, thaat is built
uponn EAL2 annd includes some of thhe most releevant elemeents from thhe EAL4 assurance
leveel, with the aim of ensuuring that thhe POI can be evaluateed at the apppropriate leevel. The
EAL L POI balannces evaluation effort aaccording to o the archittecture of thhe POI, and
d empha-
sizes the use off suitably in
nformed pennetration tessting that refflects the vaariety of asssets. The
consstruction off this packaage allows tthe efficien nt evaluation of PED aand POI co onfigura-
tionns taking intto account the
t specificc attacks ob bserved on PEDP and PO OI devices,, and the
risk managemeent processeed for the syystems thatt use them. In critical areas the assurance
requuirements arre augmented to a leveel significan ntly greater than EAL22, e.g. with PIN en-
crypption keys evaluated
e ag
gainst POI-H High attack potential.
14 POII evaluationns conformaant with thiss Protection
n Profile sh
hall rely on the terminaals Eval-
uatioon Methodoology defineed in [POI C
CEM].
15 Thiss Protectionn Profile an
nd the packkages defineed in this document
d reequire “striict” con-
formmance. Secuurity Targets or Protecttion Profiless conformannt to this Prrotection Pro ofile can
exteend the periimeter of th
he chosen PE ED/POI con nfiguration with additiional functionalities
if neecessary.
16 The evaluation of this Pro
otection Pro file has beeen performeed by the Frrench ITSEF Serma
Techhnologies IT
TSEF. The PP has beenn certified byb French Scheme
S AN SSI.
th
Page 12 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
1.3 Refeerences
[CC1] C
Common Crriteria Part 11, Version 3.1,
3 Revision 4, CCMB
B-2012-09-0
001
[CC2] C
3 Revision 4, CCMB
B-2012-09-0
002
[CC3] C
3 Revision 4, CCMB
B-2012-09-0
003
[CEM] Common Crriteria Evaluuation Meth
C hodology, Version
V 3.1, Revision 4,,
C
CCMB-20122-09-004
[EPC B4] SEPA CARD
S DS STAND DARDISAT
TION (SCS) “VOLUME
E” 1, Book 4, “Se-
cuurity”, Verssion 6.4.0.440
[PP Mood] CC and CEM
C M addenda / Modular PP,
P Date: March 2014, V
Version 1.0
0,
C
CCDB-20144-03-001
[EMV] E
EMV Book 1 to 4, Verssion 4.3
[EPC Shhield] European Paayment Couuncil, Towarrds our Sing
E gle Paymentnt Area: Privvacy
shhielding of the PIN Enntry Device, Implementtation Guideelines, Verssion 1.3,
F
February 200
09
[POI AtttackPot] Jooint Interpretation Librrary / Appliication of Attack
A Potenntial to POIss, Ver-
Date: 9th Jun
siion 1.0 (for trial use), D ne 2011. Noote: POI evaaluations shhall rely
o the curren
on nt version oof this documment at the moment off the evaluattion.
[POI PP
P 2.0] Common Ap
C pproval Schheme (CAS)) / Point of Interaction
I PProtection Profile
P
D
Date: 26 th November,
N 22010, Versiion: 2.0. No
ote: This is tthe precedinng ver-
siion of this PP.
P
[POI CE
EM] Jooint Interpreetation Librrary – CEM
M Refinemen nts for POI E Evaluation,, Ver-
th
h
siion 1.0, 27 May 2011 . Note: POII evaluation ns shall relyy on the currrent
veersion of this documennt at the momment of the evaluation.
[RNGPC
CI] Payment Carrd Industry (PCI) POS PIN Entry Device (PE
P ED), Versionn 2.0,
A
Appendix A, Appendix C
R
Rukhin, Anddrew, et al., "A Statisticcal Test Suiite for Randdom and Pseeu-
d
dorandom Number
N Gennerators for Cryptographic Applicaations", NIS ST
S
SP800-22, reevisions datted May 15,, 2001.
K
Kim, Song-JJu, et al., "C
Corrections of
o the NISTT Statistical Test Suite for
R
Randomness s".
B
Bassham, Laarry (NIST)). "Validatio on Testing and
a NIST Sttatistical Teest
S
Suite" presenntation, dateed July 22, 2004.
H Joshua (InfoGard L
Hill, Labs). "ApEEn Test Parameter Seleection".
th
4 Page 13
Protection Profile
POI P
2 POII PP Frameework
17 Chaapter 1.2 alrready gives an overvieew of the POOI PP Frammework. Hoowever, thiss chapter
givees additionaal informatio
on to undersstand how a POI evaluation workss.
18 The ST author first has too choose onne of the th mental base PPs, i.e. th
hree fundam he PED-
ONL LY, the PO
OI-COPMRE EHENSIVE E or the PO OI-CHIP-ONNLY one. T There is no descrip-
tionn of each PO
OI base PPss in separatted chapterss of the PP,, but each cchapter inclludes in-
formmation for each
e POI baase PPs. Thiis is the sam
me approachh as in Verssion 2.0 of this
t doc-
umeent.
2.1 pen Protoco
“Op ol Package””
19 For the SFR-ennforcing feaatures relatedd to “Open Protocols” (see foot noote 1) the fo
ollowing
apprroach has been chosen: These feattures are alll realised ass refinementts of the SA
ARs. The
refinnements aree given in chapter
c 9.2..2 "Refined
d security asssurance reequirements" of this
docuument and are clearly y marked ass “Open Prrotocol” reffinements. These SAR R refine-
mennts can be seeen as a pacckage.
20 In oorder to incllude the “OOpen protoc ol package””, the ST auuthor has too choose on
ne of the
basee PPs “PED D-ONLY an nd Open prootocols”, “P POI-COPMR REHENSIV VE and Opeen proto-
colss” or “POI-C CHIP-ONL LY and Opeen protocolss”. There iss no formall method ap pplied in
the definition ofo the “Open Protocol” package. This is siimply donee by refinin ng corre-
sponnding SARss. However, the ST hass to claim conformance
c e to the “Oppen Protoco
ol” pack-
age if the packaage is going g to be usedd. If the ST
T claims con
nformance tto a base PP
P includ-
ing the “Open Protocol” package, thhe conform mance must be strict. TThe versionn of the
packkage is giveen in this do
ocument.
21 There is no new w assurance componennt for the evaluation
e of
o a Securitty Target co ompliant
withh a POI connfiguration extended bby the SFR R-enforcing features. E Each of the compo-
nentts in ASE_C CCL.1 that apply to a sstandard PP P also appliees to the POOI configuraation ex-
tendded by the SFR-enforci
S ing featuress. Indeed, in
n order to asssess the con
onformity off a Secu-
rity Target to a POI base PP
P extendedd by the SFR R-enforcingg features, tthe POI base PP ex-
tendded by the SFR-enforci
S ing featuress have to bee interpreted
d as a base PPP. Beside the con-
formmance claimm the evaluaator has to ccheck that alll refinemen
nts of the SAARs are also part of
the SST.
2.2 SRE
ED PP-Mod
dule
22 The SRED reqquirements set is definned accordiing to the module m appproach desccribed in
[PP Mod] and the t securityy problem, thhe SFRs an nd the SARss are describbed separately from
the chapters deescribing thee POI base PPs. Howeever, the asssignment off the protection lev-
els iis not descrribed separaately but paart of the ch
hapters describing the PPOI base PPPs. Thus
the cchapters describing thee POI base P PPs have linnks to the SRED PP-M Module.
23 If thhe SRED requirement set
s is going to be used the SRED PP-Module
P must be claaimed in
the ST. If thee SRED PP-Module
P is to be used, a PO OI base PPP i.e. eithher POI-
COM MPREHEN NSIVE or PED-ONLY Y, possibly enhanced
e by the Openn protocol package,
p
has to be selectted before (POI-CHIP-
( -ONLY is not n feasible with SRED D). If the ST
T claims
confformance too the chosenn POI base P
PP and the SRED PP-M Module the conforman nce claim
shalll be strict. See
S also [PP
P Mod] for ddetailed rulles on how to
t use a PP Module.
th
Page 14 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
24 There is no neww assurance componennt for the evaluation
e of
o a Securitty Target coompliant
withh a POI baase PP exteended by thhe SRED PP-Module
P . Each of the components in
ASE E_CCL.1 thhat apply too a base PPP also appliees to the baase PP exteended by th he SRED
PP-MModule. Inddeed, in ord
der to assesss the conforrmity of a Security Targ
rget to a basse PP ex-
tendded by the SRED PP-Module, tthe POI co onfiguration extended by the SR RED PP-
Moddule has to be interpreeted as a staandard PP, following guidance
g giiven in chap p. 2.6 of
[PP Mod].3
Chose a
POI
configu-
ration
Include th
he Include the Inc
clude the
POI- PED-ONLY POI-C
CHIP-ONLY
COMPREHEN NSIVE configuration connfiguration
configuration in the ST in the ST in
n the ST
Include SRED yes Is SRED

PP-module
required?
in the ST
T
no
Include Open Protocol

P yes Is ‚Open
packagee Protocols‘
in the ST
T required?
no
Perform evaluation
according to the
requirements of the
ST
Fig
gure 1: POI Framework – Process Fllow
3 Please nnote: Accordinng to [PP Mod d] a configuraation is alwayss the result of the inclusion of a module. However,
for readabbility in the foollowing chap
pters of this doocument someetimes all posssible TOE-varriants includinng the
base PPs are called “coonfiguration” in a general seense.
th
4 Page 15
POI P
Protection Profile
3 TOE
E Overview
w
3.1 TOE
E Type
25 The TOE is a product

p of type
t PIN EEntry Devicee (PED) or Point of Innteraction (P
POI), ei-
therr without shhielding cap
pabilities orr with privaacy shieldin
ng compliannt with EPC
C guide-
liness [EPC Shieeld].
26 The TOE has particular
p ch
haracteristic s depending
g on the basse PP:
 PED-ON NLY base PP: The T TOE provid des protectioon for bothh IC and Magnetic
M
Stripe card
c based trransactions.. It does nott manage transaction ddata nor prov
vide any
externall communiccation facillity. PED-O ONLY is su uitable to bbe extended d by the
SRED PP-Module
P in sectionn 12 and/or the Open Protocol SSFR-supportting fea-
tures.
 POI-CO OMPREHEN NSIVE bas e PP: The TOET provid
des protectiion for bothh IC and
Magnetic Stripe caard based trransactions,, provides payment
p traansaction daata man-
agemennt and exterrnal commuunication faacilities for interaction with the Acquirer.
A
POI-CO OMPREHEN NSIVE is ssuitable to be
b extended d by the SR RED PP-Module in
section 12 and/or th
he Open Prootocol SFR--supportingg features.
 POI-CH HIP-ONLY base PP: T TOE provid des protectio
on for IC CCard based transac-
tions, payment
p tran
nsaction daata managem ment and external
e commmunicatio on facili-
ties. Thhere are no hardware ssecurity req quirements for the prootection of the
t PIN.
Protectiion of the offline
o plainntext PIN authenticatio
a on and of th
the Magnetiic Stripe
Reader is out of thee scope of thhe TOE. PO
OI-CHIP-ON NLY is suittable to be extended
e
by the Open
O Protoccol SFR-suppporting feaatures.
th
Page 16 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
Since thhe existencee of these vaariants makees this PP harder
h to reaad than a PPP for a simp
ple TOE
type, thee reader maay want to use
u the folloowing picturre to undersstand the rellation betweeen var-
ious deffinitions andd chapters in this PP:
Figure 2: Relations between vaarious defin

nitions and
d chapters iin this PP.
3.2 TOE
E Security Features
27 The aim of this section iss to providee a high lev vel descriptiion of the PPOI configu urations,
theirr logical annd physical perimeter, assets, objeectives and security feaatures. Thiss section
startts with a prresentation of
o a genericc POI, and then it defines the TO OE security features.
These features vary from one configuuration to another,
a witth a shared kernel arou und PIN
Entrry, encrypteed PIN authentication aand IC Cardd Reader pro otection.
th
4 Page 17
POI P
Protection Profile
3.2.1 Gen
neric POI
3.2.1.1 Generic Payment

P Trransaction Process
28 The following figure show

ws the POII payment transaction
t process baased on offlline PIN
verification.
10. Isssuer payment
Acquirer Issuer
8. Ask for paym

ment with payment transaction data
11. Paym
ment 7. Payment transactioon data
to merch
hant inclu
uding Transaction 9. Payment notification
certificate and Merchaant
paraameters
1. Payment T
Transaction data
Merchant Cardholder
1. Payment
P Transactiion data
2. to 5. Paymeent transaction datta, managment

data and PIN ((if offline PIN verification)
POI 3. PIN requestt 5. Transactio

on Certificate Card
3. PIN requestt 6. Ca
ardholder receipt
4. PIN (if ooffline PIN verificattion)
Figure 3: Generic
G PO
OI Paymentt Transactiion Processs
1. T
The merchhant submitts payment transaction g. amount) to the Cardholder
n data (e.g
tthrough thee display and
d to the POII.
2. T
The POI suubmits paym ment transaaction data to the card in order too perform card c risk
mmanagemennt (and also o possibly too the Issuer''s authorisattion server in case of an
a online
rrequest). Thhis step cov
vers all card/
d/ POI data exchanges
e until
u transacction completion.
3. T
The card reequests Card
dholder authhentication by PIN com
mparison.
4. T
The Cardhoolder provid des his PIN N to be verified againstt a referencce PIN man naged by
tthe IC cardd (offline) or
o the remotte Issuer viia the Acqu uirer System
m (online). The
T POI
dispatches the PIN dep pending onn the transacction type: online or ooffline. Enteering the
vvalid PIN implies
i thatt the Cardhholder accep pts the term
ms of the traansaction (i.e. vali-
dates transaaction data), and enablees further trransaction processing
p bby granting the card
wwith the rigghts connectted to the C
Cardholder.
5. U
Upon succeessful comp pletion of ttransaction processing, including card risk manage-m
m
ment on behhalf of the Issuer
I (onlinne), the card
d issues a trransaction ccertificate.
th
Page 18 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
6. T
The POI eddits transacttion receiptss - includin
ng transactio
on data andd certificate, as well
as Cardholdder and merrchant identtifiers and data
d - to the Cardholderr and merch hant.
29 Afteer the POI payment transaction

t the followiing processs applies. T
This processs is not
stronngly relatedd to the POII payment trransaction.
7. T
The merchaant claims payment
p byy forwarding g the transaaction data aand certificate, plus
hhis own parrameters (e.g. merchannt identifier)) to the Acquirer bank.
8. T
The Acquirrer bank sen
nds this payyment requeest to the Isssuer bank ddetaining th
he Card-
hholder's acccount.
9. T
The Issuer maps
m the paayment requuest to one of
o its Cardh
holders, debbits him and
d issues a
ppayment nootification (tto be checkked by the Cardholder
C for
f consistenncy).
10. T
The Issuer pays
p the Accquirer refunnd, possibly
y through gllobal bank-tto-bank balance.
11. T
The Acquirrer pays the merchant rrefund for th
he goods delivered to thhe Cardhold
der.
3.2.1.2 Generic Terminal

T Managemen
M nt Process
30 The generic Teerminal Man

nagement pprocess of th
he POI adm
ministration consists off the fol-
lowiing steps:
1. A Terminall Managem ment sessionn is establish
hed with th
he Terminall Managem ment Sys-
ttem (TMS). The POI executes
e opeerations in communica
c ation with thhe TMS and
d/or asks
tthe TMS foor operation
ns to be perrformed (e.g. the POI asks whethher new sofftware is
aavailable).
2. TThe TMS sends

s POI managemen
m nt data or software
s to the POI viia a data do ownload
((e.g. new sooftware is downloaded
d d and authen
nticity of so
oftware is vverified by the
t POI)
aand/or the POI
P sends POIP manageement data tot the TMS via a data uupload.
3. TThe internaal state of th

he POI is chhanged appropriately (ee.g. new parrameters aree applied
oor new soft ftware is activated). Thhis operatio
on may be performed
p iimmediatelly or de-
fferred in tim
me.
4. TThe POI reeports on itss hardware, software anda internal managemeent parametter status
((e.g. the sofftware statu
us of the PO
OI is reported
d).
3.2.1.3 Generic POI

P Archittecture
31 The generic PO
OI architectu
ure includess the follow
wing compon
nents:
th
4 Page 19
POI P
Protection Profile
Point of Inte
eraction (POI)
Application
n/
POI
P Application Logic Acquirer Systtem
Terminal
App
plication1
Managemennt
Adm
ministration by
y System
Application2
Terminal Manageme ent
Applicatio
on n
al
Other Loca
Devices
CHV Devices:
PIN En ntry Device Userr I/O
Card Readerrs:
(includees keypad, Other Security Devicces:
IC Card Read der
displayy, Security Modules: (excluding
and/or
Module and may E.g HSM andd/ CHV) Ke eypad,
Magnetic Strip
pe
includ
de a Card or SAM Display, printer,
Reader
Reader) and/or Acousticc Signal
Biometric Device
Leegend
Mags
stripe
IC Card data flow
w
Caard
Fiigure 4: Geeneric POI Architectu

ure
3.2.1.4 Generic POI

P Archittecture Com
mponents
32 POII componennts may be integrated in the sam me device asa the POI Application n Logic.
They may alsoo be distribu uted as inddependent devices
d conn nected to thhe POI App plication
Loggic by varioous means such as cablles, wireless link, locaal area netw
work, etc. It is up to
the ST author to specify which POII componen nts are insidde the TOE E and thus shall be
evalluated. For instance, th
he printer oor audible signals, am
mongst Userr I/Os, are optional
com
mponents.
a) POI Ap pplication Logic

L (PAL L). The POII Applicatio on Logic m manages the applica-
tions running on th
he POI. At lleast one off the applicaations execuutes paymeent trans-
actions. The PAL offers
o securrity featuress to the applications annd includes the Ter-
minal Management
M t as well as all the relaated internall interfaces needed to access
a to
the POI peripheralss and to the external Teerminal Man nagement SSystem.
b) Applicaations. The objective oof a POI is to

t execute applications
a s issued by different
applicattion provideers (e.g. baank, health,, loyalty, government,, etc.). A POI
P may
support a multi-appplication envvironment.
th
Page 20 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
c) POI Coomponents.. POI Compponents are driven by th
he POI Appplication Lo
ogic. The
POI com
mponents arre:
 Carrd Readers: devices thhat provide interfaces

i to
o cards. Thee Card Read ders may
suppport differen
nt types of cards, e.g. IC
I contact cards,
c IC coontactless cards and
Maggnetic Stripe cards. PO OI as per thiis Protectionn Profile inncludes one or more
IC Card
C Readeers thus alloowing IC based
b paymment transact ctions. The IC Card
Reader may beelong to thee tamper-ressponsive en nclosure of the PED (C CHV de-
vicees block in Figure
F 4) orr it may be separated
s (C
Card Readerrs block in the
t same
figuure).
 Carrdholder Verification Devices (C CHV): devicces for Carrdholder autthentica-

tion, e.g. a PIN
N Entry Devvice (PED)). A PED contains a kkeypad, a diisplay, a
Secuurity Modu ule (PED SM M) for PIN N encryption n and may also includ de an IC
Cardd Reader. POI
P as per th this Protectiion Profile includes
i at least one PED
P thus
allow
wing Cardh holder PIN eentry and au uthenticatio
on. As for thhe PED key ypad and
PEDD display, distributed
d aarchitecturess are also acccepted proovided that the PED
keyppad securityy module ccontrols the PED display. The intterfaces of the t PED
keyppad security
y module annd the PED display hav ve to be prottected.
 Secuurity Modu ules (SM): devices forr management of crypptographic keysk and
crypptographic functions
f (ee.g. a Hardw
ware Security Module (H
(HSM) or a Security
Appplication Mo odule (SAM M) as part of a CHV orr an externaal Security Applica-
A
tion Module (SAM) for a ppurse appliccation (PSA AM)). A POII with integ
grated IC
Cardd Reader may
m include only one SM S (SM for CHV), buut in non-in ntegrated
casees additionaal SMs are required (e.g.
( to provide encrypption/decry
yption of
PINNs between PED
P and ICC Card Reader if they are not encclosed into one
o tam-
per-responsive boundary; iin this case an IC Card d Reader SMM is neededd in addi-
tion to the PED
D SM).
 User I/Os: thaat may incluude display y, keyboard d, printer, aand audible signals.
Diffferent User I/O interfacces may exiist for the Attendant
A annd for the Cardhold-
er.
d) Externaal IT Entitties. POI m

may provid
de communiication cappabilities to interact
with extternal IT en
ntities:
 IC Card:
C The Cardholderr's IC Card that
t interactts with the POI throug
gh the IC
Cardd Reader.
 Maggnetic Strip pe Card: T The Cardholder's Magn netic Stripe Card that interacts
(passsively) with
h the POI thhrough the Magnetic
M Sttripe Reader
er.
 Appplication / Acquirer
A S
System: Enttity operated by the Appplication Provider,
P
the Acquirer
A orr the Acquirrer Processo
or with who
om the POI exchanges transac-
tion data.
th
4 Page 21
POI P
Protection Profile
 Termminal Man nagement System: Entity E used to adminiistrate (insttallation,
mainntenance) a set of POIss. It is used by the Term
minal Admiinistrator.
 Local Devices:: Any devicce that is nott a peripherral device annd that eitheer inputs
or outputs
o paym
ment transaaction data. Examples of o Local Deevices are thet Elec-
tronnic Cash Reg
gister (ECR
R), a Vendin ng Machine Controller or a Pump Control-
f Petrol Outdoor conffigurations. The connecctions to theese externall devices
ler for
mayy be implemmented by vaarious mean ns such as private or puublic networrk.
3.2.1.5 POI Exam

mple
33 Figuure 5, Figurre 6 and Figure 7 show the minimu um set of co

omponents aand functionns of the
TOE E in PED-O ONLY, POII-COMPRE EHENSIVE and POI-C CHIP-ONLY Y configuraations re-
specctively, withh all components in onee device, ex
xcluding any
y payment aapplication..
34 Notiice that TOE componeents may be connected via an open n network (iin that case the data
exchhanged on thet interfaces betweenn the compo onents are signed
s or enncrypted if required
by thhe Securityy Functionall Requiremeents or proteected by oth
her means).
Figuree 5: TOE in
n PED-ONL
LY configu
uration
th
Page 22 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
Figgure 6: TO
OE in POI-C
COMPREH
HENSIVE configurati
tion
th
4 Page 23
POI P
Protection Profile
Point o
of Interaction (POI)
Application Application Application

n Application
1 2 3 n
...
Acqu
uirer System POI Application Logic (P
PAL) Terminal Man
nagement
Syste
em
Communiccation Seccurity App
plication Te
erminal
Other L
Local Devices Service
es Servvices Sep
paration Man
nagement
V
VPN Network
k
IC Card MagStripe
CHV Devicce
Reader Reader
R
TOE
ICC User Input/Ouutput Mag

gStripe Data
Figure 7: TOE in PO
OI-CHIP-O
ONLY conffiguration
3.2.2 Secu
urity featurres
4
35 The security of the TOE payment trransactions relies on a number oof security features
provvided by thee TOE, on the
t capabiliity of the IC
C Card as well
w as on thhe selected payment
p
appllication by the
t IC Cardd.
36 The goal of thee TOE is to enforce, thrrough its security featu
ures, part or all of the fo
ollowing
propperties on thhe assets, deepending onn the TOE configuratioon. These pproperties on n the as-
sets provide ann overview of the objeectives for the
t TOE wh hich are preecisely desccribed in
secttion 6:
- Connfidentiality of PIN (thee asset PIN is defined ini section 5..1, its definiition
takees into accou
unt the natuure of the PIIN, e.g. encrrypted or pllaintext).
- Connfidentiality, authenticitty and integ
grity of PIN
N processingg keys.
- Authhenticity an
nd integrity of PIN proccessing softtware.
- Authhenticity an
nd integrity of POI man
nagement an
nd transactioon data.
- Connfidentiality, authenticitty and integ
grity of POII data protecction keys.
- Prottection of IC
C Card Readder against tampering
4This Prootection Profile addresses security

s featurres independen
ntly of the stan
ndard they com
omply with, [E
EMV] or
any otherr legacy, domeestic or private IC Card stanndard.
th
Page 24 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
- Prottection of Magnetic
M Strripe Reader against tam
mpering
37 Eachh TOE conffiguration provides
p a sspecific set of security features thaat meets thee intend-
ed uusage and thhe assumptions on the eenvironmen nt. Moreoveer, each of tthe security features
are protected at a a specific level, nam
mely, POI-B Basic, POI-L Low, POI-E EnhancedLo ow, POI-
Modderate, or POI-High, The precise ddefinition of these prottection levells in terms of o attack
poteential is givven in [POI AttackPot]]. Note that the protecttion for keyys and otherr crypto-
grapphic data (e.g. salt valu
ues) used to protect carrdholder acccount data m may be set ata differ-
ent llevels accorrding to whhether the S RED PP-M Module is inccluded or nnot (cf. Figuure 9 and
Figuure 10).
38 PEDD and POI configuratio
c ons share a ccommon TS SF structuree made of T
TSF concenttric rings
(alsoo called TSFF parts), as shown in thhe following
g figures.
Enha
ancedLow prootection
Basic protection
Conttrol of PED Promptts
PEDMiddle TSF
P
Magnetic Stripe
S
Proce
essing of Plaintext PIN
Readeer
by ICCR
Middle TSF
ICCR TSF
PIN entry and processing of PIN

until PIN is enciphered
(excluding Plaintext PIN
N when sent to
and processed byb ICCR)
Core TSF
F
Processing o
of Secret
PIN Encipherm
ment Keys
Low proteection
Modeerate protectio
on High protectiion
Figure 8: TSF
T structu
ure in PED
D-ONLY configurationn
th
4 Page 25
POI P
Protection Profile
Enha
Basic p
protection
PEDMiddle TSF
P
Magnetic Stripe
S
Proce
Readeer
by ICCR
ICCR TSF
PIN Entry
y
Keeys for Processing and
a processing of PIN until
of POI management PIN is enciphered
and payment (exclu
uding Plaintext PIN
N when sent to
t
transaction data and processed by ICCR)
Core TSFF
Processing o
of Secret
Processing of POI
P
PIN Encipherm
ment Keys
managementt
and paymentt
transaction data
Middle TSF
Low proteection
Mode
erate protectio
on High protectiion
Figure 9: TSF structure in P

POI-COMP
PREHENSIIVE configguration
Enha
Basic protection
Conttrol of PED Prompts
PEDMiddle TSF
P
Magnetic Stripe
Proce
Readeer
by ICCR
ICCR TSF
PIN Entry
Keys (other and processing of PIN un
ntil
than th
hose in CoreTSF) fo
or PIN is enciphered (excluding Plaintexxt PIN when sent
fo
or processing of to and processed by ICCR) and cryp ptographic data
POI m
management amd
used to protect cardholder accou
unt information
p
payment trans‐
Core TSF
action data
Processing of
P Secre
et
Processing of POI
P
PIN
N Encipherment Ke eys
managemen nt
and payment
transaction daata
Middle TSFF
Low proteection
Modeerate protectio
on High protecti on
Figure 10:
1 TSF strructure in P
POI-COMPREHENS SIVE configguration
with adoptted SRED PP-Module
P e
th
Page 26 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
Basic p
protection
PEDMiddle TSF
P
Keyys (other than
Secrett Keys protecting
the autheenticiy and integrity PIN Entry and
P proccessing of
of a payyment transaction) PIN until
P PIN is encciphered.
for Processing of POI Processing of Secret
management and pay‐ PIN Encipherment Keys
meent transaction and Secreet Keys protecting the authenticy andd
data inte
egrity of a paymennt transaction
Processing of POI
P
Core TSF
F
managementt
and paymentt
transaction data
Middle TSF
Low proteection
Moderate prootection
Figu
ure 11: TSF
F structuree in POI-CH
HIP-ONLY
Y configuraation
39 The TSF parts define the logical

l and physical TO OE boundary of each cconfiguratio
on. Each
TSF
F part is assoociated to one
o attack pootential leveel:
 CoreTSFKeeys (CoreT
C TSF PIN en
nciphermentt keys) aree protected at POI-
H
High level for the PE
ED-ONLY and POI-COMPREHE ENSIVE co onfigura-
t
tions.
 CoreTSF co
C ontains secuurity featurees protected
d at POI-MModerate lev
vel. Only
f POI-CH
for HIP-ONLY cconfiguratio on the following holds : PIN encip
pherment
k
keys are asssigned to CooreTSF and d thus are prrotected at PPOI-Moderrate level
(
(instead of POI-High level in PE ED-ONLY and POI-C COMPREHE ENSIVE
c
configuratioons).
 Plaintext PIIN processiing by the IC Card Reader
P R (ICCCR) is prottected at
P
POI-Enhanc cedLow levvel for the PED-ONLY
P Y and POI-C COMPREHE ENSIVE
c
configuratio
ons. Plainteext PIN processing iss not appliccable for the POI-
C
CHIP-ONL LY configuraation.
 P
PEDMiddle
eTSF contaiins security features protected at PPOI-Low lev
vel.
 MiddleTSF (including keys for processing
M p POI
P manageement and paymentp
t
transaction data) contaains security
y features protected
p at POI-Basic level. If
t optionall SRED PP
the P-Module in n section 12 is adoptedd in an ST or
o a con-
f
forming PP, then this w
will result in
n cryptograaphic data uused to proteect card-
h
holder acco
ount informaation (e.g. keys
k and anny salt valuees used for a surro-
g PAN) being
gate b proteccted at POII-Moderate level insteaad of POI-Basic lev-
e see Figure 10. For P
el, POI-CHIP-O ONLY conffiguration onnly secret keys
k pro-
t
tecting Pay
yment Trannsaction Daata are prottected at PPOI-Moderaate level
th
4 Page 27
POI P
Protection Profile
aagainst discclosure andd thus assig
gned to CorreTSF, supeerseding PO
OI-Basic
l
level.
 T Magnettic Stripe R
The Reader (MSR
R) is protectted at POI-B
Basic level.
40 The definition of the TSF F parts takees into acco
ount that keys may be protected at a higher
leveels than the individual instances oof data thatt they proteect, and thaat keys for different
purpposes are prrotected to different
d levvels.
41 The highest levvel of protection is givven to keys that protectt PIN data ((with the ab
bove de-
scribbed exceptiion for prottecting thesse keys at POI-Modera
P ate in POI-CCHIP-ONL LY). Alt-
houggh PEDMidddleTSF an nd MiddleT TSF may alsso contain cryptograph
c hic keys and opera-
tionns, these keyys are not used
u for direect protectio
on of PIN data
d and thuus are protected at a
variety of loweer levels (ass shown in the figuress above) acccording to the type/usse of the
key,, the configuuration, and
d whether thhe SRED PP P-Module iss adopted orr not.
42 The ICCR TSF F, present in
i PED-ON
NLY and in n POI-COM MPREHENSSIVE, includes pro-
cesssing of thee PIN in plaintext bby the IC Card Reaader, and tthis requires POI-
EnhhancedLow protection (whereas thhe PIN proccessed in th
he PED requuires POI-M
Moderate
prottection levell).
43 The PEDMiddlleTSF contrrols the prottection of PED prompts at POI-Loow level forr all con-
figuurations.
44 The MiddleTSF F provides processing of POI maanagement and paymeent transactiion data.
Thiss is protecteed at POI-B
Basic level. K Keys used to process POI
P manageement and paymentp
trannsaction dataa are separaately identiified (mainlly so that th
hey can be distinguish hed from
keyss used to prrotect PINs)) but are prootected at PO
OI-Basic ass for the restt of the Mid
ddleTSF.
As ppointed outt above, cerrtain specifiic keys relaated to cardhholder accoount data prrotection
are pprotected att POI-Modeerate level iff the SRED D PP-Modulee is chosen..
45 The Magnetic Stripe
S Readder (MSR), ppresent in PED-ONLY
P Y and POI-C
COMPREHE
ENSIVE
conffigurations, is protected
d at POI-Baasic level.
46 The physical boundary
b off each TSF part is deffined by thee PED or PPOI compon nents in-
volvved in the realisation
r of
o the TSF part’s securrity features. Note thatt a compon nent may
conttribute to more
m than on ne TSF partt (e.g. a ran
ndom numbeer generatorr that is useed for all
purpposes). In thhis case, thee resistance required fro
om the com
mponent is thhat of the more
m pro-
tecteed TSF partt the compo onent belonngs to. Also note that data
d may be protected at a differ-
ent llevels accorrding to the different coomponents in which it is situated.
47 There are two different arrchitectures for PEDs and a IC Card Readers aas componeents of a
POII: in one arcchitecture th
he PED andd the IC Caard Reader area integrateed into one tamper-
respponsive bouundary. In thhe other, thee PED and the
t IC Card d Reader aree not integraated into
one tamper-ressponsive bo oundary annd thereforee the Plainttext PIN, aaddressed byb PED-
ONL LY and POOI-COMPRE EHENSIVE E configuraations, has to
t be encryp
ypted on thee way to
the IIC Card Reader.
th
Page 28 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
48 The security feeatures provvide a high level view of the secu urity of the terminals. The
T pre-
cise view is givven by the SFRs
S in secction 9. The complete list of securiity features, regard-
less of the TOEE configurattion, consistts of:
1. PIN
N Entry with
hout exposurre of PIN diigits.
2. Encipherment of o PIN for ooffline or online Cardh holder encryypted PIN authenti-
a
catioon and transfer for furtther processing (to thee IC Card R
Reader or to
o the Ac-
quirrer).
3. Encipherment ofo PIN for offline Carrdholder plaaintext PIN
N authenticaation and
transmission to
o the IC Caard Reader.. Applicablee only to ddistributed architec-
a
tures where PE ED and ICC Card Reaader are no ot enclosedd into one tamper-
respponsive boun
ndary.
4. Prottected transmission oof PIN forr offline Cardholder
C authenticaation of
Plainntext PIN to
t the IC C
Card Readerr. Applicable only to iintegrated architec-
a
tures where PEED and IC C
Card Readerr are enclossed into onee tamper-ressponsive
bounndary.
5. Deccipherment ofo PIN by thhe IC Card Reader and d transmissioon to the IC
C Card in
plainntext. Applicable onlyy to distributted architecctures wheree PED and IC Card
Reader are not enclosed innto one tamp per-responsive boundarry.
6. Periiodic authen
ntication of PIN processsing softwaare.
7. Authhenticity an
nd integrity protection of adminisstration (e.gg. download
ding, up-
datee) of PIN processing sooftware and keys, includ
ding approppriate crypto
ographic
meaans.
8. Integrity protecction of PO OI management and payment
p trransaction data
d and
crypptographic means
m to prrotect paym
ment transacttion data at external co
ommuni-
catioon lines agaainst disclossure and moodification.
9. Authhenticity an
nd integrity protection of adminisstration (e.gg. downloadding, up-
datee) of POI management
m t and transaction proccessing softtware and keys,
k in-
cludding approprriate cryptoographic meeans.
10. Conntrol of PED
D prompts.
11. Tam
mper-detectiion/tamper-rresponsiven
ness (PED, PED SM, IIC Card Reeader, IC
Cardd Reader SM
M, Magnetiic Stripe Reader).
12. Secuure downloaading of payyment appliication.
13. Tam
mper-detectiion/tamper-rresponsiven
ness (PED SM
S in case oof CHIP_O
ONLY).
14. Connfidentiality, authenticitty and integ
grity protecttion of keyss (including
g authen-
ticityy and integ
grity of pubblic keys) used
u to pro
otect accounnt data in payment
p
transactions.
th
4 Page 29
POI P
Protection Profile
3.2.2.1 Security features
f in each base PP
49 Table 1 definess the logicaal boundariees of each base

b PP in terms
t of TSSF parts imp plement-
ing a particularr set of secu ms in the cellls refer to tthe security features
urity featurees. The item
listeed in sectionn 3.2.2.
PPP Core- CoreTSFK

Keys IC
C Card PEED MiddleTSF MSR
M
cconfigu- TSF Reeader Mid-
M
rration dlleTSF
P
PED- 1, 2, 3, 4, Secret PIN
N enci- 5 10
0, 11 11
O
ONLY 6, 7, 11 pherment kkeys If SRED
If SRED for 2, 3, 5,
11 is adopt-
is adopted
d, also
ed also 8.
14.
P
POI- 1, 2, 3, 4, Secret PIN
N enci- 5 10
0, 11 8,, 9, 12 11
C
COM- 6, 7, 11 pherment kkeys
P
PRE- If SRED for 2, 3, 5, 11
H
HEN- is adopt-
S
SIVE ed 14.
P
POI- 1, 2, 6, 7, 10
0 8,, 9, 12
C
CHIP- 13 (in-
O
ONLY cluding
secret
PIN en-
cipher-
ment
keys and
secret
Payment
Transac-
tion Data
keys)
Tab
ble 1: TSF d
decomposittion by base PP
50 The componennts of a POI describedd in section 3.2.1.4 maay be part oof the TOE E or not.
Somme of the loocal devicess may be exxternal in sttrict terms, but sometim
mes, e.g. fo
or a cash
register, they may
m be orig ginators of ddata to be protected
p in
n the TOE. T Table 2 deffines the
defaault physicaal boundariees of each base PP inn terms of components
c s associated
d to TSF
partts.
th
Page 30 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
PPP CoreT
TSF C
CoreTSF- IC PEED Miid- MSR
M
cconfigura- K
Keys Card Mid-
M dleeTSF
ttion Read dlleTSF
er
P
PED-ONLY
Y PED Keypad
K IC
C Card IC PE
ED If SSRED is Magnet-
M
If SRE
ED is R
Read- Card Diisplay adoopted: ic
i Stripe
err SM, Read- Othher POI Reader
R
adopted Ac- PE
ED
PEED SM er com mpo-
count Data
D Keeypad
nennts han-
SM
dlinng POI
maanage-
meent and
payyment
trannsaction
datta.
P
POI- PED Keypad
K C Card
IC IC PE
ED Othher POI Magnet-
M
C
COMPRE-- R
Reader Card Diisplay commpo- ic
i Stripe
If SRE
ED is
H
HENSIVE SM
M, Read- nennts Reader
R
adopted Ac- PE
ED
PE
ED SM er
count Data
D KeeyPad
SM
P
POI-CHIP
P- PED Keypad,
K PE
ED Othher POI
O
ONLY PED SM Diisplay commpo-
nennts
PE
ED
Keeypad
T
Table 2: Ph
hysical bou
undaries of TSF parts by base PP
P
51 Appplication noote: The IC Card Readder SM is not requireed in integrrated architectures,

wheere the PIN does not tra
avel outsidee a logicallyy and physiccally securee boundary.
52 Appplication note: The PO OI SM may nnot exist ass a separatee componennt in some POI
P – it
mighht, for exam
mple, be a ro
ole fulfilledd by the PED
D SM.
53 Appplication notte: The Secu urity Targett author sha
all update th
he default lo
logical and//or phys-
ical boundariess of the TOE E regardingg TSF partss, according g to the prooduct speciffic prop-
ertiees. The Seccurity Targeet author iss allowed tot augmentt inner ringgs with com mponents
from
m the outer rings. This means, CorreTSF boun ndary can only be enlarrged, with elements
e
from
m the defauult PED Middle or MiiddleTSF, and a PED MiddleTSF
M ccan include compo-
nentts in the deffault MiddleeTSF. In any
ny such enlaargement, thhe attack pootential leveels for an
elem
ment can only be increa ased.
3.3 Non
n-TOE Harrdware/ Sofftware/ Firrmware ava
ailable to thhe TOE
54 There is no nonn-TOE hard

dware/ softw
ware/ firmware availablle to the TO
OE.
th
4 Page 31
POI P
Protection Profile
3.4 TOE
E Usage
55 The TOE is intended to bee used in paayment enviironments. The

T charactteristics requ
uired for
the eenvironmennt depend on
n the base P
PP:
 PED-ON NLY configguration: Thhe TOE is in
ntended to be
b used as a POI comp
ponent in
any payyment enviro
onment satiisfying glob
bal PCI requ
uirements.
 POI-CO
OMPREHEN NSIVE connfiguration: The TOE is intendedd to be used
d in any
SEPA payment
p env
vironment ssatisfying gllobal PCI reequirementss.
 POI-CH nded to be used by chip-only
HIP-ONLY configuratiion: The TOE is inten
paymennt schemes like
l girocardd.
3.5 TOE
E Life Cyclle
56 The main phasees of the TO

OE life cyclee are the following:
57 Devveloper Phasse:
1. Devvelopment and
a Manufaccturing
2. Initiial Softwaree and Cryptoographic Keey Loading
58 Opeerational Phase (User Phase):
P
3. Instaallation
4. Acqquirer Initiallisation
5. Use by Merchaant and Custtomer
6. Endd of life
59 The delivery of the TOE takes placee at the end d of develop
per phase. T
Thus TOE develop-
d
mennt and manuufacturing as
a well as IInitial Softw
ware and Crryptographiic Key Loaading are
coveered by the evaluation process.
60 The TOE behavviour during g the usage phase by thhe Merchantt and Custoomer is desccribed by
the gguidance doocumentatio
on, evaluateed with the AGD
A assuraance class.
61 Appplication Noote: The ST T author shhall update this life cyycle accordding to the product
speccificities, e.gg. integrateed or distribbuted device, applicatiion loading during Inittial Soft-
warre Loading and/or durring use, coonfiguration n of applicaations with device specific pa-
ram
meters, etc.
3.5.1 Devveloper pha

ase
3.5.1.1 Developm
ment and Manufactur
M ring
62 POII developmeent and man

nufacturing consists of producing
- POI harrdware containing emb edded softw
ware
th
Page 32 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
- Additionnal software for that PO
OI (when ap
pplicable)
- Initial Key
K Loading
g and if neccessary uplo
oad of personalisation ccryptograph
hic keys
63 Durring manufaacturing, thee POI is asssembled, po owered on and

a tested (uusing the emmbedded
softwware if preesent). Pre-p
personalisattion is the manufactur
m ring step whhen a POI receives
the ccryptographhic keys to be used in tthe subsequuent personalisation phhase. In som
me cases,
addiitional softw
ware is added to the em mbedded so oftware at later phases of the POII life cy-
cle.
3.5.1.2 Initial Software and
d Cryptograaphic Key Loading
64 Softtware load agents

a are installed
i duuring initial software lo
oading to alllow furtherr remote
softw
ware installlation, if app
plicable. Thhe installation of a load
d agent usess the minim
mum load
softw
ware presennt in the emmbedded soft ftware.
65 Initiial Cryptogrraphic Keyss are loadedd into the POI. Additioonal cryptoggraphic keys can al-
so bbe loaded during
d this phase.
p It is the task off the ST autthor to desccribe which
h crypto-
grapphic keys arre loaded duuring the deeveloper ph hase and whhich keys arre loaded duuring the
operration phasee.
66 The TOE is dellivered afterr the Initial Software an
nd Cryptogrraphic Key Loading.
67 Appplication notte:
68 The ST author shall speciffy exactly, w which softw
ware parts and
a which kkeys are covvered by
the IInitial Softw
ware and Crryptographiic Key Load ding. While Initial Softtware loadin
ng is op-
tional (if all neecessary sofftware and//or firmwarre is already
dy introduceed during hardware
prodduction), there will alw
ways be an IInitial Key Loading
L ocedure5.
pro
3.5.2 Userr phase
69 Durring the Useer phase at the Merchaant premisees, the POI performs ccard based payment
p
trannsactions. POOI administtration is peerformed byy an Acquirrer either thhrough a con
nnection
to a Terminal Managemen
M nt System orr directly att the POI. Further crypt
ptographic keys
k may
be looaded to peersonalise th
he POI.
70 POII installationn and POI Acquirer Innitialisation
n are pre-req
quisites to tthe use of the
t POI.
These steps aree performedd at the Merrchant site using
u the usser-accessibble interfacees of the
POII.
5 The inittial key is the trust anchor, on which all ffollowing cryp ptographically y secure key looading is baseed and
cannot bee loaded in thee field. Note also
a that the O OSeC steering committee haas defined the initial key by "The ini-
tial key inn no cases is the
t acquirer keey, but is the kkey, which assures the auth hentication of tthe hardware device
independdent of the purp d for later on. " While this statement
rpose it is used s is ab
bout authenticcity of the POII, the
common property betw ween this and thet preceding sentence is th he need for an ct, which is needed for
n initial secrect
the securee implementattion of furtherr steps. This innitial secret caan only be impported in clearar text (otherw
wise its en-
cryption w would requiree another secreet, which wouuld then be thee initial key). Therefore
T it caannot be impoorted in a
potentiallly insecure ennvironment.
th
4 Page 33
POI P
Protection Profile
3.5.2.1 Installatioon
71 Instaallation deppends on thee configuraation of the POI, either integrated in one encllosure or
he actual installation stteps for the evaluat-
distrributed. It iss up to the ST author tto specify th
ed P
POI. These steps
s may innclude:
- physical installation
n of the diff
fferent POI components
c s,
- cabling and connecctions to exxternal perippherals whiich may be local, e.g. an Elec-
tronic Cash
C Registeer, or remotte via an extternal accesss line,
- softwaree download
ding,
- configurration with specific parrameters,
- mutual recognitionn of POI coomponents (allowing

( components to exchang
ge infor-
mation, for instance in the conntext of a Laarge Retail configuratio
c on),
- test of thhe whole PO

OI configurration,
- installattion of the address o f each Acq

quirer and Terminal A
Administrator with
whom thhe Merchan nt has a cont
ntract.
3.5.2.2 Acquirer Initialisatiion
72 Local operationn on the PO OI is neededd to start in

nitialisation by the Acqquirer. Acquuirer ini-
tialisation takess place with
h each Acquuirer with whom
w the Merchant
M opperating the POI has
a coontract.
73 Furtther cryptoggraphic keys may be looaded during
g the Acquiirer Initialissation to perrsonalise
the P
POI.
74 The Acquirer downloads
d parameters configurin
ng how tran nsactions wiill be proceessed for
eachh of the acqquired brand
ds. A Merchhant who dooes not wannt to get invovolved in thee admin-
istraation of his POI wouldd put a Term
minal Manag gement Sysstem in charrge of initiaalisation.
Anoother Merchhant may pu ut his own P
POI Attendaant in chargee of initialissation.
75 Som metimes, in preparation
p n for Acquirrer address installation
i (POI installlation steps)) and for
Acqquirer appliccation confiiguration (AAcquirer initialisation steps),
s the PPOI receives the pa-
ram
meters that arre common to the Acquuiring envirronments du uring the peersonalisatioon phase
(e.g. list of actiive Acquireers on the m
market with their initial host addreess, list of Applica-
A
tionn Identifiers and public keys of commmonly acccepted brand ds).
76 It iss up to the ST
S author to
o specify thhe actual in
nitialisation steps for thhe evaluated
d POI. It
mayy also includde software downloadinng.
3.5.2.3 Use by merchant an
nd customerr
77 Durring the Useer phase at the Merchaant premisees, the POI performs ccard based payment
p
trannsactions. PO
OI administtration is peerformed by
y an Acquirrer either thhrough a con
nnection
to a Terminal Managemen
M nt System orr directly at the POI.
th
Page 34 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
78 All security rellevant guid
dance for seecure use of
o the TOE in this phaase needs to
o be ad-
dresssed in the guidance
g do
ocumentatioon.
3.5.2.4 End of liffe
79 The handling of o the TOE after its usaage may deepend on thee individuall product an nd is not
desccribed in thiis PP. All seecurity requuirements deefined in th
his PP have tto be upheld during
this phase. If, for
f example, a TOE cann be re-load ded with new w software and date too be used
in a new conteext, the ST-author will have to deescribe, how w this is donne in a wayy, which
uphoolds the seccurity of crryptographiic keys and d other data from the fformer usag ge phase
(e.g. by securelly deleting them).
t
th
4 Page 35
POI P
Protection Profile
4 Con
nformance Claims
4.1 nformance claim to CC

Con C
80 Thiss Protectionn Profile is conformant

c mmon Criteria version 33.1 revision 4:
to the Com
- CC
C Part 2 [CC2] extendeed
- CC
C Part 3 [CC3] extendeed
81 The CC Part 2 is extendedd with the ssecurity fun
nctional com
mponents FC
CS_RND.1 Genera-
tionn of random numbers, and
a FPT_EM MSEC.1 TO OE emanatioon.
82 The CC Part 3 is extended d with the ssecurity assu urance commponents AV VA_POI.1 POI P vul-
neraability analyysis (cf. secction 8.3). BBy instantiaation of AVVA_POI.1 tthis assuran nce com-
poneent is applieed to TSF parts
p of diffeerent attack
k potential reesistance (c f. 9.2.3). Th
he annex
in chhapter 14 exxplains the relationshipp between AVA_POI
A and
a AVA_V VAN.2.
83 Notee: The definition of AVA_POI
A hhas changedd compared Version 2..0 of this document
althoough the saame name for f the famiily is kept. This could be confusinng between n devices
certiified under different veersions of thhe PP. Therrefore, if reaaders of evaaluation doccumenta-
tionn for a prodduct (for example the aaccording certificate)
c encounter ddifficulties in inter-
pretting the AVA A-level, theey are askedd to check what
w version n of the PP applies (so e.g. cer-
tificcations undeer this PP will
w only usse AVA_PO OI.1, whereeas those unnder Versio on 2.0 of
this document used
u up to AVA_POI.4
A 4).
4.2 Con
nformance claim to a p
package
84 Thiss Protectionn Profile is conformant

c to EAL PO
OI which is defined
d in ssection 9.2.
4.3 Con
nformance claim of th
he PP
85 Thiss PP does noot claim con

nformance tto any otherr PP.
4.4 Con
nformance claim to th
he PP
86 The conformannce to this PP

P and to thhe packagess chosen fro
om it, requirred for the Security
Targgets and Prrotection Prrofiles claim
ming conformance to it, is strictt, as defined in CC
Partt 1 [CC1].
th
Page 36 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
5 Secu
urity probllem definitiion
5.1 Asseets
87 The following table

t summmarises the aassets of thee TOE and their
t sensitiivity: Confiidentiali-
ty (C
C), Authentticity (A) an
nd Integrity (I).
88 Somme assets onnly need to be
b separatelly identified
d if a particu
ular configuuration is ussed, or if
the SRED PP-M Module is adopted
a – inn other casees these asseets would eeither not bee present
or eelse would be
b included d as part off another assset. For exxample, PAN N and otheer SRED
Acccount Data are
a only disttinguished aas separate assets if SR RED is adoppted, otherw wise they
are cconsidered as part of PAY_DAT.
P Similarly, POI_PayDa
P atSK is onlyy separated from the
rest of POI_SKK in the POI-CHIP-ONL LY configu uration.
A
Asset Sensitivity
S
P
PIN C
E
ENC_PIN C
P
PLAIN_PIN C
C
Cleartext PLA
AIN_PIN C
C
Ciphertext PLAIN_PIN C
M
MAN_DAT A,
A I
P
PAY_DAT A,
A I
SRED Accoun
S nt Data partly subset of C,
C A, I
P
PAY_DAT (iff SRED PP-M Module is chosen)
M
Magnetic Strip
pe Track Dataa C,
C A, I
E
ENC_PIN_PK
K A,
A I
E
ENC_PIN_SK
K C,
C A, I
P
PLAIN_PIN_S
SK C,
C A, I
P
PED_MIDDLE_PK A,
A I
P
PED_MIDDLE_SK C,
C A, I
P
POI_PK A,
A I
P
POI_SK C,
C A, I
E2E_PAN_PK
E K (if SRED PP
P-Module is cho- A,
A I
s
sen)
TOE_PAN_SK
T K, E2E_PAN__SK (if SRED
D PP- C,
C A, I
M
Module is cho
osen)
P
POI_PayDatSK
K subset of PO
OI_SK C
C
CORE_SW A,
A I
C
CORE_HW A,
A I
P
PED_MIDDLE_SW A,
A I
th
4 Page 37
POI P
Protection Profile
A
Asset Sensitivity
S
P
PED_MIDDLE_HW A,
A I
I
ICCR_SW A,
A I
I
ICCR_HW A,
A I
P
POI_SW A,
A I
P
PAYMENT_A
APP A,
A I
Table 33: Assets sensitivity
89 PIN
N
90 Carddholder perrsonal identifier, used tto authenticcate himselff against thee IC Card or
o the Is-
suerr. The PIN stands
s for th
he digits enntered by the Cardholdeer, before aany treatmennt by the
TOE E.
91 There are two categories of PIN: EN NC_PIN an nd PLAIN_P PIN. ENC__PIN standss for the
N to be usedd for onlinee or offline encrypted authenticatiion, while PPLAIN_PIN
PIN N stands
b used for offline cleaartext autheentication. Like
for tthe PIN to be L PIN, thhe assets ENNC_PIN
and PLAIN_PIIN stand fo or the set oof digits enttered by th he Cardholdder before any
a pro-
cesssing.
92 Senssitivity: Connfidentiality
y.
93 ENC C_PIN6 (PIIN digits th

hat have too be receiveed encrypted by the IIC Card orr the Is-
suerr) { XE "EN
NC_PIN (E Enciphered d PIN)" }
94 PINN used by thhe Cardhold der to authennticate himsself in one of the two ffollowing ways
w (cf.
item
m 2 from thee list of secu
urity featurees in section
n 3.2.2)
- OI payment application
Online authenticatiion: the PO n and the IIC Card app plication
require sending thee PIN encryypted via the online intterface of thhe POI to th
he Issuer
via the Acquirer.
A
- Offline ciphertext authenticattion: the PO
OI paymentt applicatioon and the IC Card
applicattion requiree sending thhe PIN enccrypted to the IC Carrd via the IC Card
Reader interface.
y.
96 PLA
AIN_PIN (PIN digits that have to be received in cleartext by tthe IC Carrd) { XE
"PL
LAIN_PIN (Plaintext PIN)" }
97 PIN
N used by thee Cardholdeer to authennticate himself in the fo
ollowing waay:
- Offline plaintext au uthenticatioon: the POI payment ap pplication aand the IC Card
C ap-
plicationn require seending the P PIN in cleartext to the IC
I Card.
6 A moree descriptive name

n fort this asset would bbe something like
l "PIN_TO_ _BE_ENCRY YPTED", becaause it
stands forr the plain texxt PIN, which needs to be enncrypted laterr on. To keep the
t name shorrt we stay with
h
ENC_PIN N.
th
Page 38 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
98 There are two categories of PLAIN N_PIN, depending on the POI arrchitecture, defined
hereeafter: Ciphertext PLAIIN PIN andd Cleartext PLAIN_PIN
P N.
y.
100 Ciphertext PL LAIN_PIN7 (in distribbuted POI architectur

a res, PIN diggits that ha
ave to be
receeived in cleeartext by the IC Card
d){ XE "En
nciphered PLAIN_PIN
P N" }
101 The PLAIN_PIIN that has to be encryypted prior to t sending itt to the IC C
Card Readeer, which
thenn deciphers it before seending it inn cleartext to
o the IC Caard. This assset is relev
vant only
for tthose POI architecture
a s where thee PED and the IC Card d Reader arre separated d devices
(i.e. not integraated into onee single tam
mper-responnsive boundaary).
y.
103 Appplication notte: This corrresponds too items 3 th
hen 5 from the
t list of seecurity feattures (cf.
secttion 3.2.2).
104 Cleaartext PLA AIN_PIN (iin integratted POI arrchitecturess, PIN digiits that hav
ve to be
receeived in cleeartext by the IC Card
d){ XE "Plaaintext PLAAIN_PIN" }
105 The PLAIN_PIIN that has to be sent tto the IC Card Reader in cleartextt is called Cleartext
C
PLAAIN_PIN. This
T asset iss relevant oonly for tho
ose POI architectures w
where the PED
P and
the IIC Card Reader are inccluded in thee same tam
mper-responssive boundaary.
y.
107 Appplication notte: This corrresponds too item 4 fro
om the list of
o security ffeatures (cff. section
3.2.22).
108 POII_SW (POII software) { XE "POI__SW (POI software)"

s }
109 Softtware (codee and data) of
o the MidddleTSF.
110 Senssitivity: Authenticity and Integrityy.
111 ICC
CR_SW
o the ICCR
R TSF.
114 ICC
CR_HW
115 Harddware of thhe ICCR TSF.
7In a sim
milar way to thhe name ENC_ _PIN (as discuussed in footnnote 6) the nam
me "Ciphertexxt PLAIN_PIN N" is an
abbreviattion of its rolee. This name does
d not stand for an already y encrypted vaalue but for a plain text value that
needs to bbe encrypted forf internal traansfer in the ddistributed TO
OE.
th
4 Page 39
POI P
Protection Profile
117 PED
D_MIDDLE
E_SW
o the PEDM
MiddleTSF..
120 PED
D_MIDDLE
E_HW
121 Harddware of thhe PEDMidd
dleTSF.
123 COR
RE_SW { XE
X "CORE_
_SW (Coree software an
nd hardware)" }
o the CoreT
TSF.
126 COR
RE_HW
127 Harddware of thhe CoreTSF..
129 MA
AN_DAT (P
POI management dataa) { XE "MA
AN_DAT (POI managgement data))" }
130 At lleast POI Management
M t data are thhe POI Uniq
que Identifieer, the Mercchant Identifier and
the A ment data8. T
Acquirer rissk managem The POI_PK
K is a speciial kind of M
MAN_DAT T.
131 Senssitivity: Authenticity, Integrity.
I
132 Appplication noote: MAN_D
DAT shall bbe protecteed inside th
he TOE andd through external
com
mmunicationns.
133 PAY
Y_DAT (Paayment tra
ansaction daata) { XE "PAY_DAT
T (Payment ttransaction data)" }
134 Dataa related too the paymeent transactiion. It inclu
udes at leastt the amounnt, the Prim
mary Ac-
counnt Number (PAN), thee personal aaccount num mber, the cuurrency, thee date and tiime, and
the transaction identifier of the paym ment transaaction. Otheer data are consideredd part of
PAY Y_DAT if theyt are traansferred beetween the Issuer
I and the
t IC Cardd during a payment
p
trannsaction, forr example th he encrypteed PIN, the cryptogramm data, the AAuthorizatio
on Reply
as wwell as card script proceessing and ccard management data.
135 The Account DataD subset of PAY_D DAT includees the full PAN and (i (if present) any ele-
mennts of sensittive authenttication dataa associated
d with the account. Thee following are also
conssidered to be
b account data
d if sent iin conjunctiion with thee PAN: carddholder nam me, expi-
ratioon date, or service
s codee. Where a surrogate PAN
P is usedd and is calcculated by a hash of
the ooriginal PA
AN combineed with a sallt, then the value
v of thee salt is alsoo treated as Account
Dataa.
8 Issuer aand Acquirer risk

r management data are uused to decide,, together with
h the card, whhich kind of au
uthentica-
tion and aauthorisation is
i necessary.
th
Page 40 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
137 Appplication notte: The TOE E ensures pprotection of
o PAY_DAT T inside thee device. Prrotection
of P
PAY_DAT thhat are sentt outside thee device shall be impleemented if rrequired byy the Ac-
quirrer, using TOE
T security
ty services: The paymeent applicattion may usse the TOE security
servvices to avoid disclosurre and moddification off PAY_DAT when this ddata is sent through
the oonline interf
rface.
138 SRE
ED Accoun
nt Data
139 If thhe SRED PP
P-Module is
i chosen sppecific dataa is addressed to be pro
rotected. SR
RED Ac-
counnt Data consist
c of PAN, TO OE_CLEAR R_PAN, TO OE_CIPHER ER_PAN, SURRO-
S
GAT TE_PAN annd SURROGGATE_PAN N_SALT seee 12, sectio on 12.1.1 A
Assets.
140 Sennsitivity: Coonfidentialitty, Authenti
ticity and In
ntegrity.
141 ENC
C_PIN_PK K (Public ENC_PIN
E cryptograp
phic keys) { XE "ENC
C_PIN_PK
K (Public
ENC
C_PIN crypptographic keys)"
k }
142 All public crypptographic keys
k used too protect thee confidentiiality of EN
NC_PIN andd the au-
thennticity and integrity of CORE_SW W includin ng correspoonding Certtificate Verrification
Keyys.
144 ENC C_PIN_SK K (Secret/private ENCC_PIN cry yptographicc keys) { X

XE "ENC_
_PIN_SK
(Seccret/private ENC_PIN cryptographhic keys)" }
145 All secret/privaate cryptogrraphic keyss used to prrotect the co
onfidentialitty of the EN
NC_PIN
and the authentticity and inntegrity of CORE_SW W. Note thatt private keeys are only y needed
for ddecryption, not for encryption of E
ENC_PIN.
y, Authenticcity and Integrity.
147 PED
D_MIDDLE E_PK (Pub blic PEDM
Middle cryptographic keys)
k { XE "POI_PK
K (Public
POII cryptograaphic keys)" }
148 PED
DMiddleTSF
F public cry
yptographicc keys used to protect th
he integrityy and authen
nticity of
PED
D_MIDDLEE_SW.
150 PEDD_MIDDLE E_SK (Seccret/privatee PEDMidd dle cryptog

graphic keyys) { XE "P
POI_SK
(Seccret/privatee POI cryptographic k keys)" }
151 PEDDMiddleTSF F secret/priivate cryptoographic keys used to protect the confidentiaality, in-
tegrrity and authhenticity of PED_MIDD DLE_SW and
a Prompt Controls.
153 POII_PK (Pub hic keys) { XE "POI_P

blic POI crryptograph PK (Public POI crypto
ographic
keyss)" }
th
4 Page 41
Protection Profile
POI P
154 MidddleTSF puublic cryptographic keyys used to protect thee integrity and authen
nticity of
POII_SW, PAYY_DAT and MAN_DA AT (POI trannsaction andd managem ment data resspective-
ly).
156 E2E
E_PAN_PK
K (part of SRED
S Accoount Data keys)
k
157 If SRRED PP-M Module is cho
osen specifi
fic public crryptographicc keys are aaddressed to
o be pro-
tecteed. If SRED
D PP-Modulle is chosenn for E2E_P PAN_PK, seee section 122.1.1.
158 Sennsitivity: Auuthenticity and
a Integritty.
159 POII_SK (Secrret/private POI crypttographic keys)

k { XE "POI_SK ((Secret/priv
vate POI
crypptographic keys)"
k }
160 MidddleTSF seccret/private cryptographhic keys ussed to protect the confiidentiality, integrity
and authenticity of POI_S SW, PAY DDAT and MAN_DAT
M (POI transaaction and manage-
m
mennt data respeectively).
162 TOE
E_PAN_SK
K, E2E_PA
AN_SK (parrt of SRED
D Account Data
D keys)
163 If SRRED PP-M Module is chosen speciffic secret cry
yptographicc keys are aaddressed to
o be pro-
tecteed. If SRED
D PP-Modu ule is chosenn for TOE_ _PAN_SK and
a E2E_PA AN_SK, seee section
12.11.1.
164 Sennsitivity: Coonfidentialitty, Authenti
ticity and In
ntegrity.
165 POII_PayDatSK
K (Secret/ private PO
OI PAY_DA
AT Protectiion Keys)
166 POII_PayDatSK K is defined d as a subseet of POI_SSK in orderr to allow hhigher proteection in
casee POI-CHIP P-ONLY co onfigurationn is claimed
d. POI_PayDatSK are used to pro otect the
integgrity and auuthenticity of
o PAY_DA AT.
y.
168 PLAAIN_PIN_S SK (Secrett/private P

PLAIN_PIN N cryptogrraphic keyss) { XE "P
POI_SK
(Seccret/privatee POI cryptographic k
keys)" }
169 All secret cryyptographicc keys us ed to pro
otect the confidential
c lity of Ciiphertext
PLAAIN_PIN.
171 Appplication notte: Note thaat private keeys only needed for deecryption, noot for encryyption of
PLAAIN_PIN. This
T asset iss relevant too distributeed PED architectures, where the IC I Card
Reader is not inn the same tamper-resp
t ponsive enclosure as thhe PED keyppad.
172 Maggnetic Strip

pe Track Data
D
173 The Primary Account Num
mber (PAN)) and other data.
d
th
Page 42 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
y, Authenticcity and Integrity
175 PAY
YMENT_A
APP
176 The payment application
a installed onn the POI. It includes the paymen
ent applicatiion code
and any additioonal data wh
hich comes with appliccation code (configuratiion data, etcc.)
177 Senssitivity: Inteegrity and Authenticity
A y
5.1.1 Asseets in each base PP
178 Table 4 defines the assetss of each baase PP and d the TSF parts
p they arre assigned
d to. The
coluumns for TS SF parts, wh
hich do not exist in a given
g config
guration, arre marked by
b a grey
backkground collour. In add dition there is no PLAIIN_PIN in thet POI-CH HIP-ONLY configu-
ratioon, so the coorrespondin
ng cells alsoo marked wiith grey bacckground coolour.
179 There is no column for thhe TSF partt "MSR TS SF", since th
his is excluusively dediicated to
prottect the assset "Magnetic stripe trrack data". This is in
ndicated byy including the text
"MSSR TSF" in the correspponding celll.
180 Notee that an assset may be associated tto more than
n one TSF part
p in a givven configuration.
PED
D-ONLY POI- POI-CH
HIP-ONLY
Y
COM
MPREHENS
SIVE
PEDMiddleTSF
PEDMiddleTSF
PEDMiddleTSF
IC Card Reader
IC Card Reader
IC Card Reader
CoreTSFKeys
CoreTSFKeys
MiddleTSF
MiddleTSF
MiddleTSF
dd e S
CoreTSF
CoreTSF
CoreTSF
CoreTSF
Asset
TSF9
Keys
TSF
TSF
PIN x x x
ENC_PIN x x x x x
PLAIN_PIN x x x x
Cleartext x x
PLAIN_PIN
Ciphertext x x x x x x
PLAIN_PIN
POI_SW x x
ICCR_SW x x
ICCR_HW x x
PED_MIDDL LE_SW x x x
PED_MIDDL LE_HW x x x
CORE_SW x x x
CORE_HW x x x
MAN_DAT x x
PAY_DAT x x
SRED Accouunt Data x
9Note thaat although ann implementattion of the PO OI-CHIP-ONL LY configuration will clearlyy include an IC
I Card
Reader, thhe configuratiion does not rely on the seccurity of this component
c of the TOE, as eexplained in seection 1.2.
th
4 Page 43
POI P
Protection Profile
PED
D-ONLY POI- POI-CH
HIP-ONLY
Y
COM
MPREHENS
SIVE
PEDMiddleTSF
PEDMiddleTSF
PEDMiddleTSF
IC Card Reader
IC Card Reader
IC Card Reader
CoreTSFKeys
CoreTSFKeys
MiddleTSF
MiddleTSF
MiddleTSF
dd e S
CoreTSF
CoreTSF
CoreTSF
CoreTSF
Asset
TSF9
Keys
TSF
TSF
ENC_PIN_PK K x x x
ENC_PIN_SK K x x x
PED_MIDDL LE_PK x x x
PED_MIDDL LE_SK x x x
POI_PK x x
E2E_PAN_PK x x
POI_SK x x
TOE_PAN_S SK, x x
E2E_PAN_SK x x
PLAIN_PIN__SK x x x x x x
PAYMENT__APP x x
POI_PayDatS SK x
Magnetic Striipe R TSF
MSR MSR TSF
T
Track Data
Table 4:: Assets by
y base PP
5.2 Userrs
181 Users are humaans or IT en

ntities externnal to the TO
OE that inteeract with thhe TOE.
182 Users are definned in sectio
ons 5.2.1 annd 5.2.2. Users applicab
ble to each bbase PP aree defined
in seection 5.2.33.
5.2.1 Authorised Hu
uman Userss
183 Carrdholder { XE
X "Cardh
holder" }
184 The Cardholdeer interacts with the P POI via maan-machine interfaces: he reads payment p
trannsaction dataa displayed on the POI , inserts herr/his IC card
d, authenticcates herselff/himself
withh her/his PINN, confirmss the paymeent transaction and takees the receippt.
185 Atteendant { XE
E "Attenda
ant" }
a in the POII or in a connected
c device
d may initiate a payment
p
trannsaction at the
t request of the Atteendant. Thee Attendantt interacts w with the TO OE via a
mann-machine innterface. Th
he paymentt transactionn is either in
nitiated by tthe Attendaant or by
a Loocal Devicee. The Merch
hant himsellf can be thee attendant.
th
Page 44 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
187 Merrchant { XE
E "Mercha
ant" }
188 A reetailer, or anny other perrson, compaany, or corp
poration thaat agrees to accept (ban
nk) cards
in thhe framework of a conttract with ann Acquirer.
189 Terminal Adm ministrator" }

ministrator { XE "Terrminal Adm
190 The Terminal Administrat
A tor maintainns the TOE
E directly by
y local opeerations or remotely
r
throough a Term
minal Manag
gement Systtem.
5.2.2 Exteernal Entitties
191 Acq
quirer Systeem { XE "A
Acquirer syystem" }
192 The Acquirer System
S is th
he entity thaat exchangees payment transactionn data with the POI.
Used by the Appplication Provider, thee Acquirer or
o the Acquirer Processsor.
193 Terminal Man

nagement System
S { XE
E "Terminal Management System"" }
194 The Terminal Managemen
M nt System iss the entity used to adm
ministrate (iinstallation,, mainte-
nancce) a set off POIs: softw
ware and paarameter do ownload andd applicatioon activation n / deac-
tivattion. Used by
b a Termin nal Adminisstrator.
195 IC C
Card { XE "Cardholdeer's IC Cardd" }
196 The Cardholder's IC Card is an entityy interacting g with the POI
P during a payment transac-
tionn. The Cardhholder's IC Card
C acts onn behalf of the Card Issuer.
197 Maggnetic Strip

pe Card { XE
X "Cardh
holder's IC Card" }
198 The Cardholderr's Magnetic Stripe Caard is an enttity interactiing with thee POI durin
ng a pay-
mennt transactioon. The Carrdholder's M
Magnetic Sttripe Card is the Card IIssuer’s reppresenta-
tive.
199 Loccal Device { XE "Loca

al Device" }
200 A paayment trannsaction maay be initiatted at the reequest of thee Attendantt or a Locall Device.
Exaamples of Local Devicees are the E Electronic Cash
C Register (ECR), a Vending Machine
M
Conntroller or a Pump Controller forr Petrol Outtdoor confiigurations. T The connecctions to
thesse external devices
d mayy be implem mented by various
v meaans such ass a private or
o public
netwwork.
201 Payyment Appllication { XE

X "Paymeent Applica
ation " }
202 The Payment Application
A correspondds to the pay
yment appliication codee and data using
u the
Paymment Appliication Logic and the pperipheral components
c s of the PO
OI to processs a pay-
mennt transactioon. There may
m be moree than one Payment
P Ap
pplication inn the POI. The
T Pay-
mennt Applicatioon acts on behalf
b of thee Acquirer.
th
4 Page 45
POI P
Protection Profile
203 Risk
k Managerr
204 The Risk Manaager is an entity
e interaacting with
h the IC Card, the Term
rminal Man nagement
Systtem and thee Acquirer System
S durring a paym
ment transaction. The innputs from all three
entitties helps thhe Risk Mannager determ mining whiich type of ENC_PIN
E ((online encrrypted or
offliine encrypteed) shall be used.
5.2.3 Userrs in each base

b PP
205 Table 5 definess the users of

o each basee PP.
User PE
ED-ONLY POI--COMPREHENSIVE
E POI-CHIIP-
ONLY
Cardhoolder X X X
Attendaant X X X
Merchaant X X X
Terminnal Adminisstrator X X X
Acquirrer System X X X
Terminnal Managem
ment X X X
System
IC Cardd X X X
Magnetic Stripe Card
C X X
Local D
Device X X X
Paymennt Applicatiion X X X
Risk M
Manager X X X
Table 55: Users by base PP
5.3 Sub
bjects
206 Subjjects are acttive compon

nents of thee TOE that act
a on the behalf of useers.
207 Subjjects appliccable to each
h base PP arre defined in
i section 5..3.1.
208 Payyment Appllication Log

gic (PAL) { XE "Paym
ment Appliication " }
209 The Payment Application
A Logic mannages the appplications running onn the POI. The
T PAL
incluudes softwaare and all the relatedd internal in
nterfaces needed to acccess to the POI pe-
riphherals and exxternal deviices.
th
Page 46 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
210 Appplication note: The PAL L is responnsible for providing
p acccess to thee POI SM (Security
(
Moddule) that performs
p crryptographiic operatio ons on acco ount data uusing POI_ _SK and
POII_PK (or thee relevant subset
s assetss defined in
n section 5.1
1), althoughh as noted in
n section
3.2.22.1, the POI
OI SM may not
n be a sepaarate component in alll cases.
211 Terminal Man

nagement
212 The Terminal Managemen
M nt executes POI manag
gement commmands issuued by the Terminal
T
Mannagement System. It may
m also act of its own, for examplee when an aattack is dettected.
213 IC C
Card Read
der and IC Card
C Read
der SM (Seccurity Mod
dule)
214 The IC Card Reader
R wh
hich managees the comm municationss between thhe IC Card
d and the
POII. The IC Card
C Readerr SM decryypts the Cip
phertext PLA
AIN_PIN to be sent to o the IC
Cardd in cleartexxt.
215 PED
D: (PED) keypad,
k (PE
ED) displayy, (PED) SM
M
216 The PED as Caardholder Verification
V Device and d its (PED)) keypad w where the PIIN is en-
teredd, its (PED
D) display where
w the Caardholder iss asked to enter its PIN
N and its (PE
ED) SM
(Seccurity Moduule) which processes
p kkeys or mannages them (PIN encryyption, MAC C verifi-
catioon for CORRE_SW).
217 Corre Loader

218 The loader dow
wnloading CORE_SW
C iinto the POI.
219 PED
D Middle Loader
L
220 The loader dow
wnloading PED_MIDD
P DLE_SW intto the POI.
221 Mid
ddle Loaderr
222 The loader dow
wnloading POI_SW
P intoo the POI.
223 ICC
CR Loader
224 The loader dow
wnloading IC
CCR_SW innto the POII.
225 Payyment Appllication Loa

ader
226 Loaader for dow
wnloading an
nd updatingg payment applications
a .
227 Maggnetic Strip

pe Reader
th
4 Page 47
POI P
Protection Profile
228 The Magnetic Stripe
S Readder reads thee Magnetic Stripe Tracck Data of tthe Magnetic Stripe
Cardd of the Carrdholder.
5.3.1 Sub
bjects in eacch base PP
229 Table 6 definess the subjectts of each bbase PP.

Subbject PED- POI-COM
MPREHEN
NSIVE POII-CHIP-ONLY
ONLY
Paayment Applicatio
on X X X
Logic
Teerminal Mannagement X X X
PE
ED X X X
IC
C Card Readder X X
M
Magnetic Striipe Reader X X
Coore Loader X X X
PE
ED Middle Loader
L X X X
M
Middle Loadeer X X
IC
CCR Loaderr X X
Paayment Applicatio
on X X
Loader
Table 6: Subjects by
y base PP
5.4 Thrreats
230 Anyy user of thhe TOE maay behave aas threat agent. The atttack paths that implem ment the
threats may invvolve physiical and/or logical meaans. (Wheree assets aree identified for each
threat then thesse are stated at the higghest level:: subset assets, such ass PAN (a subset
s of
PAYY_DAT), arre not separately identi fied.)
231 T.M
MerchUsurp p (Mercha ant Identityy Usurpation) { XE "T.MerchhUsurp (M
Merchant
Iden
ntity Usurp
pation)" }
232 A frraudulent Merchant
M is credited foor transactio
ons that Carrdholders inntended forr another
Merrchant by manipulating
m g another MMerchant's TOE
T to maake the Carddholders isssue pay-
mennt instructioons modifyiing the amoount in pay yment transsaction dataa PAY_DA AT to his
beneefit or stealiing and moddifying anoother Merchant's paymeent transactiion data PAAY_DAT
befoore they are collected oro by modify fying risk management
m data, POI UUnique Idenntifier or
the M
Merchant Iddentifier in the MAN_D DAT.
233 Relaated assets: MAN_DAT
T, PAY_DA
AT, POI_SW
W, POI_PK
K, POI_SK.
th
Page 48 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
234 Appplication notte: The atta
ack on the P
POI Uniquee Identifier can
c be execcuted by ma anipulat-
ing the MiddleTSF or at the t externa l interface to the Acquuirer whichh is also part of the
MidddleTSF.
235 T.C
CardholderU
UsurpEPIN
N (Cardh holder Ideentity Usu urpation ENC_PIN) { XE
"T.C
CardholderUsurpEPIIN (Cardhoolder Identtity Usurpa
ation Encryypted-PIN))" }
236 Frauudsters withh POI-Modeerate attackk potential level
l gain unauthorised
u d access to a Card-
holdder's accounnt by disclossing the EN
NC_PIN via any manipu ulation of thhe POI.
237 Frauudsters withh POI-High h attack poteential (for POI-CHIP-O
P ONLY POII-Moderate because
onlyy IC card based
b transaactions are accepted) level gain unauthorised
holdder's accounnt by disclossing the EN
NC_PIN viaa penetration n of the POII and/or mo onitoring
of thhe POI emaanations (inccluding powwer fluctuatiions) that would
w result in the discllosure of
the EENC_PIN__SK.
238 The goal of thee attacker is
 eeither to steeal also the IC Card andd to perform
m a transacttion based oon payment transac-
ttion data PA AY_DAT withw the capttured PIN and a the stoleen IC Card
 oor to get a copy
c of the magnetic sstripe data and
a to perfo orm a transaaction with the cap-
ttured PN annd a fake caard using thee magnetic stripe data.
239 Forr the POI-C CHIP-ONLY Y configuraation hardw ware attacks on the PINNs are not seen
s as a
threat because the combin ned effort off attacking the hardwaare of the TO
OE and to steal the
IC CCard is conssidered to be
b too unlikkely in this case
c (note that
t there iss no magnettic stripe
in thhis case).
240 Relaated assets: ENC_PIN, CORE_SW
W, CORE_H
HW, ENC_P
PIN_SK, EN
NC_PIN_PK
K.
241 T.C
CardholderUUsurpCiph
hPPIN (CCardholderr Identity
y Usurpaation Cip phertext
PLAAIN_PIN){ XE "T.CardholderU
UsurpEncPPPIN (Carddholder Iddentity Usu
urpation
Enccrypted PLAIN_PIN)"
"}
l gain unauthorised
holdder's accounnt by disclo
osing the C
Ciphertext PLAIN_PIN
P N via any m manipulation of the
POII.
243 Frauudsters withh POI-Highh attack poteential level gain unautthorised acccess to a Cardhold-
er’s account byy disclosing
g the Cipheertext PLAIN N_PIN via penetrationn of the PO OI and/or
monnitoring thee POI eman nations (inccluding pow wer fluctuattions) that w
would resuult in the
discclosure of thhe PLAIN_P
PIN_SK.
244 Frauudsters withh POI-EnhaancedLow aattack potenntial level gain unauthhorised acccess to a
Carddholder’s account
a by disclosing the Cipherrtext PLAIN N_PIN via penetrating g the IC
Cardd Reader (IICCR_SW, ICCR_HW W) making any additio ons, substituutions or modifica-
m
tionns.
245 The goal is to steal
s later th
he IC Card aand to perfo
orm a transaaction basedd on paymeent trans-
actioon data PAY
Y_DAT witth the captuured PIN and d the stolen
n IC Card.
th
4 Page 49
POI P
Protection Profile
246 Relaated assets: Ciphertext PLAIN_PIN
N, CORE_S
SW, CORE
E_HW, ICCRR_SW, ICC
CR_HW,
PED
D_MIDDLE E_SW, PED D_MIDDLE E_HW, PLA
AIN_PIN_SK
K, PED_MIIDDLE_PKK.
247 Appplication notte: This threeat applies to POI with
h separated PED and IC Card Rea
ader.
248 T.C
CardholderU UsurpClearPPIN ((Cardholdeer Identitty Usurppation Cleartext
C
PLAAIN_PIN){ XE "T.Ca ardholderU
UsurpPlainPPIN (Carrdholder Iddentity Usu
urpation
Plaiintext PLA
AIN_PIN)" }
l gain unauthorised
holdder's accounnt by disclossing the Cleeartext PLA
AIN_PIN viaa any manippulation of the
t POI.
250 Frauudsters withh POI-EnhaancedLow aattack poten ntial level gain unauthhorised acccess to a
Carddholder's acccount by disclosing
d thhe Cleartextt PLAIN_PIIN via peneetrating the IC Card
Reaader (ICCR__SW and IC CCR_HW) m making any additions, substitution
s ns or modifiications.
251 The goal is to steal
s later th
he IC Card aand to perfo
orm a transaaction basedd on paymeent trans-
actioon data PAY
Y_DAT witth the captuured PIN and d the stolen
n IC Card.
252 Relaated assets: Cleartext PLAIN_PIN
P N, CORE_S
SW, CORE_
_HW, ICCR
R_SW, ICC
CR_HW,
PED
D_MIDDLE E_SW, PED D_MIDDLEE_HW, PEDD_MIDDLE_PK.
253 Appplication notte: This threeat applies to POI with
h integrated
d PED and IIC Card Rea
ader.
254 T.PromptConttrol (M
Manipulatiion off Prommpt C
Control){ XE
"T.C
CardholderUsurpEnccPPIN (CCardholderr Identity
y Usurpaation En ncrypted
PLAAIN_PIN)"
"}
255 Frauudsters gaiin unautho orised acceess to the Prompt Control (ee.g. by co orrupting
PEDD_MIDDLE E_SW) and use the Proompt Contrrol to ask th he Cardhollder to enterr his/her
PIN
N in order to disclose it (e.g. by proocessing it in
n unprotected areas).
256 Relaated assetts: PED_
_MIDDLE__SW, PED
D_MIDDLE
E_HW, PPED_MIDD
DLE_SK,
PED
D_MIDDLE E_PK.
257 T.Transactionn (Transaction with ussurped Carrdholder id

dentity) { X
XE "T.Tran
nsaction
(Traansaction with
w usurpeed Cardhollder identitty)" }
aa) Frauudsters perfform paym
ment transacctions and manipulate
m TOE hard dware or
softwware (POI_
_SW) to acccept counterrfeit or stoleen IC cards.. Before thee modifi-
catioon the TOE would deteect such cards.
bb) Frauudsters use good IC caards and manipulate

m th
he TOE haardware or software
(POII_SW) to generate
g paayment transactions thaat debit thee wrong account in
paymment transaction data P
PAY_DAT.
cc) Frauudsters (including a frraudulent Cardholder)

C use good IIC cards an
nd later,
durinng transactiion collectioon, tap the line
l between TOE andd Acquirer anda erase
theirr transaction
ns manipulaating paym ment transacttion data PA
AY_DAT stored
s in
the TOE.
T
th
Page 50 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
258 Notee that if thee SRED PP hen an addittional refineement to th
P-Module iss adopted th his threat
appllies, as speccified in 12.
259 Relaated assets: POI_SW, PAY_DAT,
P , POI_PK, POI_SK.
P
260 T.FundsAmou unt (Funds transfer otther than correct

c amo
ount) { XE
E "T.TransA
Amount
(Fun
nds transfeer other tha
an correct amount)" }
aa) Frauudulent Merrchants mannipulate the TOE in ord der to makee the Cardhholder is-
sue payment in nstructions for more thant he thinks modifyying the am mount in
paymment transaaction data P PAY_DAT T or to makee the Cardhholder issuee several
paymment instrucctions insteaad of one generating seeveral sets oof payment transac-
tion data PAY__DAT.
bb) Frauudsters use good cards and manippulate TOE to generatee transaction
ns based
on manipulated
m d payment ttransaction data PAY_
_DAT that are rejected d by the
Acqquirer when collected.
cc) A frraudulent Cardholder

C issues valiid payment instructionns generatin
ng valid
paymment transaction data P
PAY_DAT but later deestroys paym ment transacction da-
ta PA
AY_DAT before
b they aare collecteed.
dd) Frauudsters moddify the inteerface betw

ween TOE and
a Acquireer; modify payment
p
instrructions by modificatioon of paymment transacction data PPAY_DAT into re-
fundds.
261 Relaated assets: POI_SW, PAY_DAT,

P , POI_PK, POI_SK.
P
262 T.BadDebt (Account oveerdraft, bad

d debt) { XE "T.BadD
Debt (Accouunt overdrraft, bad
debt)" }
263 A frraudulent Cardholder
C manipulates
m s the TOE not
n to go online, thus preventing the Ac-
quirrer to collecct funds and
d making thee Merchantt think the trransaction pperformed correctly
c
wheereas no funnds have beeen collectedd.
264 Relaated assets: POI_SW, MAN_DAT
M T.
265 T.SeecureComm
munication
nLines{ XE
E "T.DisclossurePerson
nalData" }
266 An aattacker maanipulates or misuses thhe POI serv
vices underllying the prrotection of external
commmunicationn lines in order to discl ose or modify the PAY
Y_DAT sennt or receiveed on ex-
ternnal communication lines.
267 Relaated assets: PAY_DAT
T, POI_SW,, POI_PK, POI_SK.
P
268 Appplication note: This is a threat aggainst the services
s pro
ovided by th the POI. Th he assets
PAYY_DAT and POI_SW are indirectly ly threateneed if the servvices are ussed to proteect them.
th
4 Page 51
POI P
Protection Profile
Notee that the protection
p off PAY_DAT T on the extternal comm
munication lines is a choice
c of
the ppayment app
pplication (ccf. definitionn of PAY_D
DATA).
269 T.M
Magstripe
270 An aattacker triees to penetrate the POII to make ad
dditions, sub
bstitutions, or modifications to
the Magnetic Stripe
S d hardware or softwaree, in order to
Readeer head andd associated t deter-
minne or modifyy Magnetic Stripe data..{ XE "T.D DisclosurePeersonalDatta" }
271 Relaated assets: Magnetic Stripe
S Trackk Data.
272 T.IlllegalCodeIInstall
273 An attacker maay try to vio olate the inttegrity and the authentticity of thee downloadeed appli-
catioon by accesssing the co ommunicatiion channell between th he POI andd the terminnal man-
agem ment devicee or falsely authenticatiing himselff as a trusted
d authority and thus beeing able
to innstall untrussted code.
274 Relaated assets: PAYMENT
T_APP.
5.4.1 Thrreats in each

h base PP
275 Table 7 definess the threats to each basse PP.

276 or those connfigurations containing the threatenned assets.
A thhreat is relevvant only fo
Threat OI-
PO PPOI-CHIP-
PED-O
ONLY
CO
OMPREHEN
NSIVE OONLY
T.M
MerchUsurpp X X
T.C
CardholderU
UsurpEPIN X X X
T.C
CardholderU
UsurpCiphP
PPIN X X
X X
T.C
CardholderU
UsurpClearP
PPIN
T.P
PromptConttrol X X X
T.T
Transaction X X
T.F
FundsAmouunt X X
T.B
BadDebt X X
X X
T.SeecureComm
municationL
Lines
T.IlllegalCodeIInstall X X
T.M
Magstripe X X
th
Page 52 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
Table 7: Threats by
y base PP
5.5 Orgganisational Security P

Policies
277 OSP
P.WellForm
medPayAppp (Welll-formed Paymennt Appllications) { XE
"OS
SP.WellForrmedPayAp yment Appllications)" }
pp (Well-foormed Pay
278 Paym ment Appliications imp
plemented oon the POI shall
s use the security m
mechanismss provid-
ed bby the TOE in a sense that the secuurity of the assets is enssured.
279 OSP OSP.AppS

P.ApplicatiionSeparation { XE "O Separation"
"}
280 The TOE shall implementt an applicaation separaation mechaanism if it pprovides a multi
m ap-
plicaation enviroonment.
281 OSP
P.POISurvey
282 Proccedural meaasures like inspectionss and guidaance will bee implemennted preventting ma-
nipuulations of the
t TOE en nclosure. In particular procedural
p measures shhall reveal manipu-
latioons of the IC
I card intterface in oorder to preevent attackks based onn electronicc circuits
mouunted at the IC card intterface of thhe TOE's Caard Reader. Those whoo are responnsible for
the TOE shall establish an nd implemeent procedurres for train
ning and vet
etting admin nistrators
of thhe TOE, or training thee supervisorrs.
283 OSP
P.Merchan
ntSurvey { XE
X "OSP.M
MerchantSurvey" }
284 In case of a fraaudulent Meerchant perfforming attaacks via maanipulationss of the encllosure or
the iinterfaces of
o the TOE, especially the IC cardd interface, the
t paymennt schemes shall de-
tect manipulatiions of a larrge numberr of paymen nt transactio
ons at the ssame merchhant with
theirr surveillance systems.
285 The payment scchemes imp
plement orgganisational measures to
o detect succh manipulaations.
286 Appplication notte: The OSPP is necessaary to countteract the fo
ollowing sceenario: A Merchant
M
deplloys a fakedd POI in ord
der to perfoorm payment transactio ons.
287 OSP
P.KeyManaagement { XE
X "OSP.K
KeyManagem
ment" }
288 Crypptographic keys have to t be securrely manageed. Especiallly the geneeration and installa-
tionn of cryptographic keyss and certifiicates have to be done in a manneer that privaate or se-
cret cryptograpphic keys aree protected against discclosure and that all cryyptographic keys are
prottected againnst modificcation whenn they are processed outside thee POI. Furtthermore
therre are procedures that support
s andd maintain thhe unique id
dentificationn of the TO
OE based
on uunique crypttographic keys
k for the pprotection of
o the online interface.
th
4 Page 53
POI P
Protection Profile
5.5.1 OSP
P in each ba
ase PP
289 All the OSP P listed above appply to each e of the

t base PPs exceept the
OSPP.ApplicatioonSeparatio
on which dooes not apply
y to PED-O
ONLY config
iguration.
5.6 Assu
umptions
290 A.U
UserEducation { XE "A
A.UserEdu
ucation" }
291 It is assumed thhat Cardhollders are infformed by their
t issuing
g banks aboout a properr use and
abouut their respponsibilitiess when usinng the TOE.. Especially
y Cardholdeers shall be asked to
keepp the PIN secret
s and notn to handd their IC cards
c her persons than a trusstworthy
to oth
merrchant.
292 A.SeecureDevicces
293 It iss assumed that the paayment appllication pro oviders havve chosen aappropriate security
meaasures to prootect devicees interactinng with the TOE
T e.g. the IC or Maggnetic Strip
pe cards.
294 A.P
PinAndCard
dManagem
ment{ XE "A
A.PinAndCardManagem
ment" }
295 It is assumed thhat the user PINs as weell as the IC
C Cards are securely mmanaged by thet Issu-
er. EEspecially it
i is assumeed that the PIN as welll as IC Carrd transfer bbetween Issuer and
Carddholder takkes place in a manner tthat the con nfidentially of the PINss is ensured
d and the
misuuse of the cards is prev
vented by orrganisationaal measures.
5.6.1 umptions in
Assu n each basee PP
296 All tthe assumpttions listed above applyy to each off the base PPs.
th
Page 54 Version 4.0
4 6 March,
M 2015
POI P rotection Profile
6 Secu
urity Objecctives
6.1 Secu
urity Objecctives for th
he TOE
th
4 Page 55
A1.1 { X
XE "A1.1" }
XE "A1.2" }
A1.2 { X
A4 { XE
E "A4" }
A5 { XE
E "A5" }
A6 { XE
E "A6" }
A7 { XE
E "A7" }
A8 { XE
E "A8" }
A9 { XE
E "A9" }
A10 { X
XE "A10" }
B1 { XE
E "B1" }
B2 { XE
E "B2" }
B3 { XE
E "B3" }
B4 { XE
E "B4" }
B5 { XE
E "B5" }
B6 { XE
E "B6" }
B7 { XE
E "B7" }
B8 { XE
E "B8" }
B9 { XE
E "B9" }
B10 { X
XE "B10" }
C1 { XE
E "C1" }
C2 { XE
E "C2" }
C3 { XE
E "C3" }
C4 { XE
E "C4" }
th
Page 56 Version 4.0 6 March,
M 2015
C5 { XE
E "C5" }
C6 { XE
E "C6" }
C7 { XE
E "C7" }
C8 { XE
E "C8" }
D2 { XE
E "D2" }
D3 { XE
E "D3" }
D4.1 { X
XE "D4.1" }
D4.2 { X
XE "D4.2" }
D4.3 { X
XE "D4.3" }
D4.4 { X
XE "D4.4" }
D5 { XE
E "D5" }
E1 { XE
E "E1" }
E2 { XE
E "E2" }
E3 { XE
E "E3" }
E4 { XE
E "E4" }
E4.1 { X
XE "E4.1" }
E4.2 { X
XE "E4.2" }
E4.3 { X
XE "E4.3" }
E5 { XE
E "E5" }
E6 { XE
E "E6" }
F1 { XE
E "F1" }
F1.1 { X
XE "F1.1" }
F1.2 { X
XE "F1.2" }
th
6 March, 2015 Version 4.0 Page 57
POI P
Protection Profile
F1.3 { X
XE "F1.3" }
XE "F1.4" }
F1.4 { X
F2 { XE
E "F2" }
G1 { XE
E "G1" }
G2 { XE
E "G2" }
G3 { XE
E "G3" }
G3.1 { X
XE "G3.1"
"}
G3.2 { X
XE "G3.2"
"}
G3.3 { X
XE "G3.3"
"}
G3.4 { X
XE "G3.4"
"}
G4 { XE
E "G4" }
G5 { XE
E "G5" }
G { XE "G" }
297 O.P
PINEntry
298 The TOE shalll provide th he functionaality to prottect the con
nfidentialityy of the PIN
N during
PIN
N entry (e.g.. against maanipulationss of the Caardholder keeypad, key presses being seen,
key sounds beinng distinguiished or keyy emanationns being distinguished)).
299 Upoon failure duuring PIN Entry,
E if thee failure trig
ggers a tamp
per-responssive mechan
nism, the
TOEE shall erasse any PIN value and related seccret data. Otherwise, thhe TOE shaall make
them
m inaccessibble.
300 For the POI-CH HIP-ONLY Y configurattion PIN en
ntry is only protected bby softwaree means,
sincce T.CardhoolderUsurpE
EPIN makess an explicitt exception for this casee.
301 O.E
EncPIN
302 The TOE shalll protect thee confidentiiality of EN
NC_PIN until it is encciphered by tamper-
respponsive and tamper-dettection meanns.
303 The TOE shall immediatelly delete EN
NC_PIN after having en
nciphered itt.
304 The TOE shall neither disp
play nor priint any ENC
C_PIN in cleear.
305 Thiss objective entails
e the following
f deerived objecctives:
aa) The TOE shall protect the confidentiaality of ENC
C_PIN_SK.
th
Page 58 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
bb) The TOE shall provide statte-of-the-arrt cryptograp
phy for crypptographic means.
m
306 Upoon failure of

o any autheenticity andd integrity check
c or up
pon incorreect executio
on, if the
failuure triggers a tampeer-responsivve mechan nism, the TOE
T erasee any PIN N value,
ENC C_PIN_SK and any oth her related secret data.. Otherwise, the TOE sshall make them in-
acceessible.
307 Thiss objective applies
a to Online
O ENC
C_PIN as weell as Offline ENC_PIN
N.
308 For the POI-CH HIP-ONLY Y configurattion tamperr-responsivee and tampeer-detection
n protec-
tionn mechaniisms do not applly for th he protection of ENC_PIN,, since
T.CardholderUUsurpEPIN makes
m an eexplicit exception for this
t case. FFor same reeason, in
the POI-CHIP-ONLY co onfigurationn describedd above, tamper-respoonsive and tamper-
deteection meanns apply for ENC_PIN__SK but at a lower leveel.
309 O.C
CipherPPIN
N
310 The TOE shall protect thee confidentiaality of Cip
phertext PLA
AIN_PIN uuntil it is enciphered
by tamper-responsive and tamper-deteection mean ns.
311 The TOE shall immediatelly delete Cipphertext PL
LAIN_PIN after
a havingg enciphered
d it.
play nor prinnt any Ciph
hertext PLA
AIN_PIN in clear.
e the following
aa) The TOE shall protect the confidentiaality of PLA
AIN_PIN_SK
K.
bb) The TOE shall provide statte-of-the-arrt cryptograp

m
314 Upoon failure of

o any autheenticity andd integrity check
c or up
pon incorreect executio
on, if the
failuure triggerss a tamper--responsive mechanism m, the TOE E shall eraase any PINN value,
PLAAIN_PIN_S SK and any other relateed secret daata. Otherw
wise, the TO
OE shall maake them
inacccessible.
315 Appplication notte: This objjective appllies to POI architecturees with sepaarated PEDD and IC
Carrd Reader (ee.g. differen
nt tamper-reesponsive boundaries).
b . Other aspeects of the separate
s
IC C
Card Readeer are addreessed under O.ICCardR Reader.
316 O.C
ClearPPIN
317 The TOE shall protect the confidentiaality of Cleaartext PLAIN_PIN untiil it is transferred to
the IIC Card Reader by tam
mper-responnsive and tam mper-detecttion means.
318 The TOE shall immediatelly delete Cl eartext PLA
AIN_PIN affter having ttransferred it.
play nor priint any Cleaartext PLAIN
N_PIN in cllear.
320 Upoon failure ofo any autheenticity andd integrity check
c or uppon incorreect executio
on, if the
failuure triggers a tamper-rresponsive m
mechanism, the TOE shall erase any PIN vaalue and
relatted secret data.
d Otherw
wise, the TO
OE shall mak ke them inaaccessible.
321 Appplication notte: This objjective appliies to POI architecture
a es with integgrated PED
D and IC
Carrd Reader (ee.g. one tam
mper-responnsive bounda ary).
th
4 Page 59
POI P
Protection Profile
322 O.C
CoreSWHW
W
323 The TOE shaall ensure the
t authentticity, the integrity and
a the coorrect execu
ution of
CORRE_SW andd CORE_HW (softwarre and relateed hardwaree).
e the following
aa) The TOE shall check the aauthenticity and integritty of CORE
E_SW and CoreTSF
C
crypptographic keys
k upon ddownloadingg of new coomponents aand updatin
ng of ex-
istinng ones.
bb) The TOE shall periodicallly check thee authenticitty and integgrity of CO
ORE_SW
softw
ware.
cc) The TOE shall periodicallyy check the authenticity and integr
grity of COR
RE_ HW
relatted hardwarre.
325 Upoon failure off any authennticity and iintegrity ch

heck or upon
n incorrect execution, the
t TOE
shalll make inacccessible an
ny PIN valuee, ENC_PIN N_SK and any
a other reelated secrett data.
326 O.P
PEDMiddleeSWHW
327 The TOE shaall ensure the
t authentticity, the integrity and
a the coorrect execu
ution of
D_MIDDLE
PED E_SW and PED_MIDD
P DLE_HW (ssoftware and d related haardware).
e the following
aa) The TOE shall check the aauthenticity y and integriity of PED__MIDDLE__SW and
PED
DMiddleTSF F cryptograp
aphic keys upon
u downlo oading of neew compon
nents and
updaating of exissting ones.
bb) The TOE shall periodiically checck the au

uthenticity and integ
grity of
PED
D_MIDDLE
E_SW softwware.
cc) The TOE shaall periodiccally check

k the autheenticity andd integrity
y of the
D_MIDDLE
PED E_HW hardw ware.
329 Upoon failure off any authen

nticity and iintegrity ch
heck or upon
t TOE
will make inacccessible anny PIN valuue, PED_M MIDDLE_SK K and any oother relateed secret
dataa.
330 O.IC
CCardReader
331 The TOE shall ensure that the TOE reesists attemp pts to penettrate the PO
OI to make any
a addi-
tionns, substitutiions, or mod
difications tto the IC Card Reader hardware oor software, in order
to determine orr modify PIN N values.
332 O.P
PaymentTraansaction
333 The TOE shalll protect th he authenticcity and inttegrity of POI manageement and payment
p
trannsaction dataa when processed by tthe TOE. Th he TOE shaall protect tthe authentiicity and
integgrity of POI management data whhen sent or received
r at the interfacces of the TOE. The
th
Page 60 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
TOE E shall provvide securityy services ffor protectin
ng PAY_DA AT from unnauthorized d modifi-
catioon and disclosure at the external in
interface to the Acquireer as well ass between physical-
p
ly seeparated parrts of the PO
OI.
e the following
aa) The TOE shall protect the confidentiaality of POI_
_SK.
bb) The TOE shall protect the authenticity

y and integrrity of POI__PK.
cc) The TOE shall ensure the ccorrect execcution of PO

OI_SW.
dd) The POI calcu ulating Messsage Authentication Codes C (MA ACs) or Signatures
shall be uniquelly identifiabble if the MAC
M and thee signaturess are calculaated over
softw
ware or datta related too POI management orr a payment nt transactio
on which
are sent via thee external innterfaces of the TOE to an exterrnal commu unication
partyy.
ee) Anyy informatioon about thee payment transaction shall be diisplayed, prrinted or
acouustic signallled in an auuthentic waay (controlleed by the ppayment app plication
baseed on user data)
d withouut deceiving
g either the Cardholder
C or the atten
ndant.
ff) The TOE shall provide statte-of-the-arrt cryptograp

m
335 Upoon failure off any authen

nticity and iintegrity ch
heck or upon
t TOE
erasses any MidddleTSF secret data.
336 In thhe POI-CHIIP-ONLY configuratio
c on POI_PayD DatSK havee in additionn to be prottected by
tampper-responssive and tam
mper-detectiion means.
337 Appplication notte: Especiallly the TOE
E will protecct cryptogra
aphic keys fo
for Acquirerr authen-
ticattion and Teerminal Maanagement SSystem auth hentication as well as cryptograpphic keys
usedd to verify the
t authentiicity and inttegrity of POI
P manageement data aand paymen nt trans-
actioon data traansferred beetween TOE E and Acqu uirer or TOOE and Termrminal Management
Systtem.
338 O.PPOI_SW{ XEX "O.POI__SW_HW (Authenticc and integeer usage off POI softw
ware and
relaated hardware)" }
339 The TOE shall ensure the authenticityy, the integrrity and thee correct exeecution of POI_SW
P
proccessing POII managemeent and payyment transaaction data and Encryppted ENC_P PIN (on-
line authenticattion).
e the following
f deerived objecctive:
aa) The TOE shall check the aauthenticity and integrity of POI_SSW and Mid
ddleTSF
crypptographic keys
k upon ddownloadingg of new coomponents aand updatin
ng of ex-
istinng ones.
341 Upoon failure off any authenticity and integrity ch

heck the TO
OE will mak
ake inaccesssible any
MidddleTSF seccret data.
th
4 Page 61
POI P
Protection Profile
342 O.P
PaymentAp
pplicationDownload
343 The TOE shall ensure the integrity annd authenticcity of the payment
p appplication du
uring ap-
plicaation downlload or upd
date.
344 O.P
POIApplicaationSepara
ation (Appllication Sep
paration)
345 The TOE shall support thee separationn of paymen nt applications from otther applicaations. If
appllications aree simultaneeously proccessed, the security of the paymennt applicatiion shall
not be impactedd by any otther applicat ation. Any POI
P manageement, paym ment transacction da-
ta, P
POI_SK, PO OI_PK own ned by an appplication arre only allo
owed to be aaccessed byy another
appllication if thhe other app
plication ha s the necesssary access rights.
346 Thiss objective entails the following
f dderived objeective: the TOE
T shall eensure that no
n resid-
ual iinformationn remains in
n resources rreleased by the paymen nt applicatioon.
347 O.P
PromptCon
ntrol
348 If thhe PED keyypad can bee used to ennter non-PIN N data, then prompts ddemanding for PIN
entrry at the PE
ED display shall
s never lead to a PIN
P disclosu ure (e.g. byy processing
g the en-
teredd PIN data in clear in unprotectedd areas). Th
he authenticcity and prooper use of prompts
shalll be ensured and modiification of the promptts or impropper use of thhe prompts shall be
prevvented.
349 O.M
MSR (TOE Protection
n of Magnettic Stripe Reader)
R
350 The TOE shall ensure that the TOE reesists attemp pts to penettrate the PO
OI to make any
a addi-
tionns, substitutions, or moodificationss to the Maagnetic Striipe Read hhead and asssociated
harddware or sofftware, in order to deteermine or modify
m Magnnetic Stripe data.
6.1.1 Secu
urity objectives for th
he TOE in each
e base PP
P
351 The table below w defines th

he objectivees applicablle to each base
b PP andd shows, wh
hich TSF
partts contributee to each ob
bjective. Noote that the TSF
T part "M MSR TSF" hhas no colummn of its
ownn, since it onnly contribu
utes to O.MS SR as indiccated in the relevant
r cellls.
PED-O
ONLY POI- POI-CHIIP-
COMPRE
EHENSIVE
E ONLY
th
Page 62 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
PEDMiddleTSF
PEDMiddleTSF
PEDMiddleTSF
IC Card Reader
IC Card Reader
CoreTSF Keys
CoreTSF Keys
CoreTSF Keys
MiddleTSF
MiddleTSF
MiddleTSF
CoreTSF
CoreTSF
CoreTSF
Objectivve for the TO
OE
O.PINEnntry x x x
O.EncPIIN x x x x x
O.CipheerPPIN x x x x x x
O.ClearP
PPIN x x x x
O.CoreS
SWHW x x x x x
O.PEDM
MiddleSWH
HW x x x
O.ICCarrdReader x x x
O.PaymentTransacttion x x
O.POI_S
SW x x
O.PaymentApplicattionDownlo
oad x x
O.POIA
ApplicationS
Separation x x
O.PrompptControl x x x
O.MSR MS
SR TSF MSR TSF
F
Table 8: Objectiives for the TOE by base PP
6.2 Secu
urity Objecctives for th
he Operatio
onal Environment
352 OE..POISurveyy { XE "OE

E.POI_Surrvey" }
353 Proccedural meaasures like inspections
i and guidan
nce will prevvent manipuulations of the
t TOE
encllosure. Proccedural meaasures like iinspections and guidannce for maninipulations of
o the IC
cardd interface will
w preventt attacks baased on elecctronic circu uits mounteed at the IC card in-
terfaace of the TOE's
T Card Reader. Thhose responssible for thee TOE estabblish and im mplement
proccedures for training and
d vetting addministratorrs of the TOE, or traininng the superrvisors.
354 OE..MerchantS
Survey { XE
X "OE.MeerchantSurvey" }
355 In case of a fraaudulent Meerchant perfforming attaacks via maanipulationss of the encllosure or
the interfaces of
o the TOE, especiallyy the IC carrd interface, payment sschemes wiill detect
mannipulations ofo a large number
n of ppayment trannsactions att the same mmerchant with
w their
survveillance sysstems.
th
4 Page 63
POI P
Protection Profile
356 OE..UserEducaation { XE "OE.UserE

Education"
"}
357 The Cardholderr shall be in
nformed by his/her ban
nk to keep th
he PIN secreet.
358 OE..SecureDevvices { XE "OE.Secur

" reDevices" }
a providers
p hhave chosenn appropriatte security m
measures to
o protect
deviices interactting with th
he TOE, e.g.. the IC card
d.
360 OE..KeyManaggement { XE
X "OE.KeeyManagem
ment" }
361 Crypptographic keys are seecurely mannaged. Esp pecially the generation and installlation of
crypptographic keys
k and certificates aare done inn a manner that privatte or secrett crypto-
grapphic keys are
a protecteed against ddisclosure and
a all cryp ptographic keys are protected
p
agaiinst modificcation whenn they are prrocessed ouutside the POI. Furtherrmore there are pro-
ceduures that suupport and maintain
m thhe unique id
dentification
n of the TO
OE based on n unique
crypptographic keys
k for the protection of the onlin
ne interface.
362 OE..PinAndCaardManageement { XE
E "OE.PinA
AndCardM
Managementt" }
363 User PINs as well
w as the IC Cards aree securely managed
m by
y the Issuer. Especiallyy the PIN
as w
well as the IC
C Card trannsfer betweeen Issuer an
nd Cardhold
der takes plaace in a man nner that
the confidentiaally of the PINs
P is ensuured and th
he misuse off the cards is preventeed by or-
ganiisational meeasures.
364 OE..WellForm
medPayApp { XE "O
OE.EMV_o
other (Welll-formed P
Payment Applica-
A
tion
n)" }
365 Paym ment Appliications impplemented oon the POI will
w make use u of the seecurity mecchanisms
provvided by thee TOE in a sense that the security y of the deffined assets as specifieed in this
PP ccannot be affected.
a Thhe payment application n is especiallly responsiible for the transac-
tionn flow of a payment
p transaction (e..g. performiing a paymeent transacttion as resullt of ver-
ificaation of riskk managemment parameeter and oth her verificaation resultss like PIN verifica-
tionn).
366 OE..LocalDevices { XE "O

OE.Local_D
_Devices" }
367 The environmeent of the TOOE shall prootect the co
onnection beetween Loccal Devices and oth-
er P
POI componnents via security orgganisational measures or o by usingg the crypto
ographic
meaans providedd by the PO
OI.
368 Appplication note: Due to the broad sspectrum off POI archiitectures, thhis PP doess not re-
quirre any speciific protectiion mechannism to be used
u for thee connectionn between local
l de-
vicees and the POI.. Hence, the th hreats T.T Transactionn, T.MercchUsurp,
T.CaardholderUUsurpCipherrPPIN, T.C CardholderrUsurpClearrPPIN, T.F FundsAmou unt and
T.BaadDebt shaall be partiaally counterred in the environmen
e t of the TO
OE. Neverthheless, in
thosse POI archhitectures where the PO OI mechanissms are useed to protectt the connecction be-
tweeen Local Devices and other POI componentts, e.g. the TOE basedd hardware security
th
Page 64 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
mecchanisms orr cryptograp phic means,
s, the ST au
uthor shall introduce
i aan additiona
al objec-
tive ffor the TOE
E, with the appropriate
a e associated
d SFRs.
6.2.1 Secu
he TOE env
vironment by
b base PP
Ps
369 All tthe objectivves for the TOE

T environnment listed
d above app
ply to each oof the base PPs.
th
4 Page 65
POI P
Protection Profile
7 Ratiionale betw
ween SPD aand security
y objectives
7.1 Thrreats
370 Thiss section prresents geneeric rationalles between

n threats and
d objectivess that are in
ndepend-
ent oof the base PPs.
371 T.C
CardholderU
UsurpEPIN
N (Cardhollder Identitty Usurpation ENC_P
PIN)
372 Cappturing the ENC_PIN
E when
w it is entered and
d processed
d is counterred by O.PIINEntry,
O.E
EncPIN andd O.CoreSWWHW (Authhentic and integrity-prrotected ussage of COORE_SW
and CORE_HW W).
373 Withh OE.UserE Education th
he user willl be educateed not to disclose the PPIN. PIN diisclosure
by aattacking coommunicatioon (e.g. durring CORE SW update) with the T TOE or due to a bad
key management are preveented by OE E.SecureDev vices and OE.KeyMan
O nagement.
374 The Security obbjective forr the enviroonment OE.PPinAndCardManageme ment ensuress that the
Carddholder PIN
N is securedd by organissational meaasures durin
ng transportt between issuer and
Carddholder.
375 Cappturing the ENC_PIN
E by
b enclosurre manipulaation is coun
ntered by pprocedural measures
m
like inspectionss and guidan
nce due to O
OE.POISurv vey.
376 OE.WellFormeedPayApp enforces
e payyment appliications performing a ppayment traansaction
flow
w as required by the pay
yment schemme.
377 T.M
MerchUsurp
p (Merchan
nt Identity Usurpation
n)
378 Moddifying anotther Merchaant's TOE bby enclosuree manipulattion is counntered by procedural
meaasures like innspections and guidancce due to OE.POISurveey.
379 Furtthermore OE.Merchan
O ntSurvey ennsures that the paymennt schemess detects fraudulent
merrchants withh their surv veillance syystems if a large num
mber of maanipulated payment
p
trannsactions aree presented by the samee merchant..
380 o another Merchant'ss TOE by attacks on the paymeent transaction data
Mannipulation of
PAYY_DAT is countered by O.Paym mentTransaaction (Authhentic and integrity-pprotected
paymment transaaction) and
d O.POI_SWW (Authenttic and inteegrity-proteected usage of POI
softw
ware).
381 Moddifying the TOE by attacking deviices commu
unicating with the TOE
E/ TOE com
mponents
or ddue to a bad key management is prevented by OE.SeccureDevicess, OE.LocallDevices
(Connnection Prrotection) an
nd OE.KeyM
Managemennt.
flow yment schemme.
th
Page 66 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
383 T.T
Transaction
n (Transaction with ussurped Carrdholder id
dentity)
384 Mannipulating the
t TOE by y enclosuree manipulatiion is coun
ntered by prrocedural measures
m
nce due to O
OE.POISurv vey.
385 Mannipulating thhe TOE by attacks on tthe paymennt transaction data PAY
Y_DAT is co ountered
by O.PaymenttTransaction n (Authentntic and in ntegrity-protected payyment transaction),
O.POI_SW (A Authentic annd integrity--protected usage
u of PO
OI softwaree and relateed hard-
waree) and O.PO
OIApplicationSeparatioon (Applicaation Separaation).
386 Moddifying the POI by attaacking deviices commu
unicating wiith to the T
TOE or due to a bad
key managemeent is preven nted by OEE.SecureDev
vices, OE.L
LocalDevicees (Connecttion Pro-
tectiion) and OE
E.KeyManagement.
387 The security obbjective for the TOE ennvironment OE.MerchaantSurvey su
supports thee defence
of frraudulent trransactions.
flow
yment schemme.
389 Notee that if thee SRED PP--Module is aadopted theen the mapp
ping of T.Trransaction to
o securi-
ty obbjectives is extended as
a describedd in 12.
390 T.IlllegalCodeIInstall (Insttallation of iillegal codee coming fro

om untrusteed authority)
t TOE by y attacks onn the paym
ment applicaation authennticity and integrity
duriing appliication doownload is counttered by the seecurity objective o
O.PaymentAppplicationDow
wnload.
392 The protection of the TOE
E software aalready in th
he TOE is en
nsured by O
O.POI_SW.
393 T.FundsAmou
unt (Funds transfer
t otheer than corrrect amount)
t TOE by y enclosuree manipulatiion is coun
ntered by prrocedural measures
m
nce due to O
OE.POISurv vey.
395 Mannipulating thhe TOE by attacks on tthe paymennt transaction data PAY
Y_DAT is co ountered
by O.PaymenttTransaction n (Authentntic and in ntegrity-protected payyment transaction),
O.POI_SW (A Authentic annd integrity--protected usage
u of PO
OI softwaree and relateed hard-
waree) and O.PO
396 Mannipulating the POI by attacking ddevices com
mmunicating
g with to thhe TOE or due to a
bad key managgement is prevented
p byy OE.SecurreDevices, OE.LocalDDevices (Connnection
Prottection) andd OE.KeyManagement..
397 The security obbjective for the TOE ennvironment OE.MerchaantSurvey su
supports thee defence
of frraudulent trransactions.
flow yment schemme.
th
4 Page 67
POI P
Protection Profile
399 T.BadDebt (Acccount overrdraft, bad ddebt)
400 Mannipulation of
o the TOE in
i order thaat the TOE does
d not go online by eenclosure manipula-
m
tionn is counteered by procedural measures like inspecctions and guidance due to
OE.POISurvey.
o the TOE E in order that the TO OE does not
n go onlinne is counttered by
O.PaymentTrannsaction (Authentic
( and inteegrity-protected paym ment transaction),
O.POI_SW (A Authentic an
nd integrity--protected usage
u of PO OI softwaree and relateed hard-
waree) and O.PO
402 TOE E manipulattion or the destruction
d of paymentt transaction
n data PAYY_DAT or modifica-
m
tionn of paymennt transactio
on data PAY Y_DAT into o refunds byb attackingg devices co
ommuni-
catinng with the TOE or du ue to a bad kkey manageement is preevented by OE.SecureD Devices,
OE.LocalDevicces (Connecction Protecction) and OE.KeyMan
O nagement.
flow
yment schemme.
404 T.SeecureComm
munication
nLines
o the TOE enclosure iis countered
d by proced
dural measuures like insspections
and guidance due
d to OE.PO
OISurvey.
406 Mannipulating thhe TOE in order to gett personal information
i of the cardd holders du
uring the
proccessing of such
s data wiithin the TO
OE is preveented by O.P
POI_SW (A Authentic annd integ-
rity--protected usage of POII softwarre and related hardware) and
O.POIApplicattionSeparatiion (Applicaation Separaation).
407 The disclosuree of PAY_ _DAT via the onlinee interfaces of the TTOE is secured by
O.PaymentTrannsaction (Authentic annd integrity-protected payment trannsaction) prrotecting
dataa against dissclosure by cryptographhic means.
408 TOE E manipulattion in ordeer to spy ouut personal data by attaacking deviices commu
unicating
withh the TOE or due to a bad keyy managem ment is prev vented by OE.SecureD Devices,
OE.LocalDevicces (Connecction Protecction) and OE.KeyMan
O nagement.
flow yment schemme.
410 T.PromptConttrol
411 Unaauthorized manipulatio
m on of PED_M
_MIDDLE_S
SW, which manages thhe prompts, is cov-
eredd by O.PED
DMiddleSWH HW.
412 The separation of PIN and d non-PIN data entered through the same keeypad is enssured by
the ssecurity objjective O.PrromptContrrol.
th
Page 68 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
7.2 OSP
P
413 OSP
P.WellForm
medPayApp
p
414 The security obbjective OE
E.WellForm
medPayApp correspondss to the orgganisational security
policy.
415 OSP
P.POISurvey
E.POISurveyy correspon
nds directly
y to the orgganisational security
policy.
417 OSP
P.Merchan
ntSurvey
E.MerchantS
Survey rresp
ponds direcctly to this oorganisation
nal secu-
rity policy.
419 OSP
P.KeyManaagement
420 The security obbjective OE.KeyManaggement corrresponds to the OSP.
421 OSP
P.ApplicatiionSeparation
422 The TOE securrity objectiv ve O.POIAppplicationSeparation directly
d impllements thee organi-
satioonal securitty policy OS
SP.ApplicattionSeparatiion.
7.3 Assu
umptions
423 A.U
UserEducation
424 The security obbjective OE.UserEducaation corresp
ponds to thee assumptioon.
425 A.SecureDevicces
426 The security obbjective OE.SecureDevvices corresp
ponds to thee assumptioon.
427 A.P
PinAndCard
dManagem
ment
428 The security obbjective OE.PinAndCarrdManagem
ment reflectss directly thhe assumptio
on.
7.4 Ratiionale appllicable to P

PED-ONLY
Y configura
ation
429 Thiss section proovides the rationales

r appplicable to
o the PED-O
ONLY confiiguration.
430 T.PromptConttrol cf. 7.1
th
4 Page 69
POI P
Protection Profile
431 T.C
CardholderU
UsurpEPIN
N (Cardholdder Identity Usurpation
n ENC_PIN
N) cf 7.1
432 T.C
CardholderU
UsurpCiph
hPPIN ((Cardholderr Identity
y Usurppation En
ncrypted
PLA
AIN_PIN)
433 Cappturing the Ciphertext
C PLAIN_PIN
P N when it iss processed is counteredd by O.Ciph
herPPIN
(Cipphertext PL
LAIN_PIN Processing)), O.CoreSW WHW, O.P PEDMiddle SWHW (A Authentic
and integrity-pprotected usage
u of PPEDMiddleeTSF SW and relateed hardwaare) and
O.ICCCardReadeer.
434 Withh OE.UserE Education thhe user willl be educateed not to disclose the PPIN. PIN diisclosure
by aattacking deevices commmunicating with the TOE
T or due to a bad keey managem ment are
prevvented by OE.LocalDe
O evices (Connnection Prootection), OE E.SecureDeevices and OE.Key-
O
Mannagement.
Carddholder PIN
N is securedd by organissational meaasures durin
ng transportt between issuer and
Carddholder.
C PLAIN_PIN N by enclosure manipulation is ccountered by proce-
duraal measures like inspecctions and guuidance duee to OE.POIISurvey.
flow yment schemme.
438 T.C
CardholderU
UsurpClearPPIN (Caardholder Id
dentity Usurpation Plainntext PLAIN
N_PIN)
439 Cappturing the Cleartext PLAIN_PIN
P N when it is entered and a processsed is counttered by
O.PIINEntry, O.ClearPPIN
O N (Clearteext PLAIN N_PIN Proccessing) annd O.CoreSWHW,
O.PEEDMiddleS SWHW (Au uthentic annd integrity--protected usage
u of PE
EDMiddleTTSF SW
and related harddware) and O.ICCardR Reader.
440 Withh OE.UserE Education th
he user willl be educateed not to disclose the PPIN. PIN diisclosure
by aattacking deevices communicatingg with the TOE
T or duee to a bad kkey manageement is
prevvented by OE.LocalDev
O vices (Connnection Prottection), OEE.SecureDevvices.
Carddholder PIN
N is secured ng transportt between issuer and
d by organissational meaasures durin
Carddholder.
C PLAIN_PIN N by enclosure manipulation is ccountered by proce-
duraal measures like inspecctions and guuidance duee to OE.POIISurvey.
flow
yment schemme.
444 T.M
Magstripe
445 The security obbjective O.M
MSR correspponds to thee threat.
446 Ratiionales for the

t followin
ng OSP are provided in
n section 7.2
2:
th
Page 70 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
 OSP.WeellFormedP
PayApp
 OSP.PO
OISurvey
 OSP.MeerchantSurv
vey
 OSP.KeeyManagem
ment

t followin
ng assumptiions are pro
ovided in secction 7.3:
 A.UserE
Education
 A.SecurreDevices
 A.PinAnndCardMan
nagement
th
4 Page 71
POI P
Protection Profile
T.SecureCommunicationLines
T.CardholderUsurpClearPPIN
T.CardholderUsurpCiphPPIN
A.PinAndCardManagement
A PinAndCardManagement
OSP.ApplicationSeparation
OSP.WellFormedPayApp
T.CardholderUsurpEPIN
OSP.KeyManagement
OSP.MercahntSurvey
OSP MercahntSurvey
T.IllegalCodeInstall
T.Prompt_Control
T.MerchantUsurp
OSP.POI_Survey
A.UserEducation
A.SecureDevices
T.FundsAmount
T.Transaction
T.Magstripe
T.BadDebt
g
O.PINEntry X X
O.EncPin X
O.CoreSWHW
W X X X
O.ClearPPIN X
O.CipherPPIN
N X
O.PEDMiddleeSW X X X
HW
O.PaymentTrransac
tion
O.POI_SW
O.POIApplicaation
Separation
O.PromptConntrol X
O.ICCardReaader X X
O.MSR X
OE.WellForm
medPa X X X X
yApp
OE.POISurveey X X X X
OE.MerchanttSurv X
ey
OE.UserEduccation X X X X
OE.SecureDeevices X X X X
OE.KeyManaageme X X X
nt
OE.PinAndCaardM X X X X
anagent
OE.LocalDevvices X X
Table 9: SPD cov

verage by oobjectives in
n PED-ON
NLY configuuration
th
Page 72 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
POI-COMP
PREHENSIIVE configuuration
448 Thiss section provides the rationales

r ap
applicable to
o the POI-C
COMPREHE
ENSIVE co
onfigura-
tionn.
t followin
ng threats arre provided in section 7.1:
7
 T.MerchhUsurp (Meerchant Idenntity Usurpaation)
 T.PrompptControl
 T.Transsaction (Transaction wiith usurped Cardholderr identity)
 T.FundssAmount (F
Funds transffer other thaan correct am
mount)
 T.BadD
Debt (Accou
unt overdraft
ft, bad debt))
 T. SecurreCommunicationLinees
 T.IllegaalCodeInstalll
 T.CardhholderUsurp
pEPIN (Carrdholder Ideentity Usurp
pation ENC__PIN)
t followin
7
pCiphPPIN (Cardhollder Identity Usurp
rpation En
ncrypted
PLAIN__PIN)
pClearPPIN
N (Cardho
older Iden
ntity Usuurpation Plaintext
P
PLAIN__PIN)
 T.Magstripe
t followin
n section 7.2
2:
PayApp
 OSP.PO
OISurvey
vey
 OSP.KeeyManagem
ment
 OSP.AppplicationSeeparation
t followin
 A.UserE
Education
nagement
th
4 Page 73
POI P
Protection Profile
T. SecureCommunicationLines
T.CardholderUsurpCiphPPIN
A PinAndCardManagement
OSP.KeyManagement
OSP.MercahntSurvey
OSP MercahntSurvey
A.UserEducation
A.SecureDevices
T.PromptControl
T.FundsAmount
OSP.POISurvey
T.MerchUsurp
T.Transaction
T.Magstripe
T.BadDebt
g
O.PINEntry X X
O.EncPin X
O.CoreSWHW
W X X X
O.ClearPPIN X
O.CipherPPIN
N X
O.PEDMiddleeSW X X X
HW
O.PaymentTrransac X X X X
tion X
O.POI_SW X X X X X X
O.PaymentAppplica X
tionDownloadd
O.POIApplicaation X X X X X
Separation
O.Prompt_Coontrol X
O.ICCardReaader X X
O.MSR X
OE.WellForm
medPa X X X X X X X X X
yApp
OE.POISurveey X X X X X X X X X
OE.MerchanttSurv X X X X
ey
OE.UserEduccation X X X X
OE.SecureDeevices X X X X X X X X X
OE.KeyManaageme X X X X X X X X
nt
OE.PinAndCaardM X X X X
anagent
OE.LocalDevvices X X X X X X X
Tab
ble 10: SPD
D coverage by objectivves in POI--COMPRE
EHENSIVE
E configura
ation
th
Page 74 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
POI-CHIP-ONLY con
nfiguration
453 Thiss section proovides the rationales

r appplicable to
o the POI-CH
HIP-ONLY
Y configurattion.
t followin
7
pEPIN (Carrdholder Ideentity Usurp
pation ENC__PIN)
 T.MerchhUsurp (Meerchant Idenntity Usurpaation)
 T.PrompptControl
 T.Transsaction (Transaction wiith usurped Cardholderr identity)
 T.FundssAmount (F
Funds transffer other thaan correct am
mount)
 T.BadD
Debt (Accou
unt overdraft
ft, bad debt))
 T. SecurreCommunicationLinees
 T.IllegaalCodeInstalll
t followin
n section 7.2
2:
PayApp
 OSP.PO
OISurvey
vey
 OSP.KeeyManagem
ment
 OSP.AppplicationSeeparation
t followin
 A.UserE
Education
nagement
th
4 Page 75
POI P
Protection Profile
T.CardholderUsurpCipherPPIN
T. SecureCommunicationLines
T CardholderUsurpClearPPIN
dP A
OSP.KeyManagement
OSP.MercahntSurvey
A.UserEducation
A.SecureDevices
T.PromptControl
T.FundsAmount
OSP.POISurvey
T.MerchUsurp
T.Transaction
T.Magstripe
OSP W llF
T.BadDebt
TF d A
O.PINEnntry X
O.EncPinn X
O.CoreSW
WHW X
O.ClearP
PPIN
O.CipherrPPIN
O.PEDM
MiddleSW X
HW
O.PaymeentTransac X X X X X
tion
O.POI_SW
W X X X X X X
O.PaymeentApplica X
tionDownnload
O.POIAppplication X X X X X
Separatioon
O.PrompttControl X
O.ICCarddReader
O.MSR
OE.WellF
FormedPa X X X X X X X
yApp
OE.POIS
Survey X X X X X X X
OE.MercchantSurv X X X X
ey
OE.UserE
Education X X
OE.SecurreDevices X X X X X X X
OE.KeyM
Manageme X X X X X X X
nt
OE.PinAnndCardM X X
anagent
OE.LocallDevices X X X X X
Table 11: SPD coverrage by objeectives in POI-CHIP-

P -ONLY connfiguration
n
th
Page 76 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
8 Exteended Requ
uirements
457 Thiss PP extendds CC Part 2 with the families off functionall requiremeents FCS_R
RND and
FPT
T_EMSEC and a CC Partt 3 with the family of assurance
a reequirementss AVA_POII.
8.1 Defiinition of th
he Family F
FCS_RND
458 To define the IT securitty functionnal requirem ments of thhe TOE ann additional family
(FCS_RND) off the Class FCS (crypptographic support)
s is defined herre. This fammily de-
scribbes the funcctional requ
uirements foor random number
n genneration useed for crypto
ographic
purpposes.
459 The family “Geeneration off random nuumbers (FCS_RND)” is specified aas follows.
460 FCS
S_RND Genneration of random
r num
mbers
461 F
Family behaviour
462 y requiremeents for the generation of random numbers which
Thiss family deffines quality w are
intennded to be used
u for cry
yptographic purposes.
463 C
Componentt levelling:
FCS_RN
ND Generation of rand
dom numbers 1
464 FCSS_RND.1 Generation

G o random numbers, requires thatt random nnumbers meeet a de-
of
fined quality metric.
m
465 M
Managemennt: FCS_RN
ND.1
466 There are no management
m activities fooreseen.
467 A
Audit: FCS
S_RND.1
468 There are no acctions defineed to be audditable.
FCS_R
RND.1 Gen
neration of random nu
umbers
469 H
Hierarchicaal to: No oth
her componnents.
470 D
Dependencies: No dependencies.
471 FCSS_RND.1.1 The TSF shall proviide a mech hanism to generate
g ranndom numb
bers that
meeet [assignmeent: a defineed quality m
metric].
he Family F
FPT_EMSE
EC
472 The additional family FPT T_EMSEC ((TOE Eman nation) of th

he class FPT
T (Protectio
on of the
TSF
F) is definedd here to deescribe the IIT security functional requiremennts of the TO
OE. The
th
4 Page 77
POI P
Protection Profile
TOE E shall prevvent attacks against seccret data whhen the attacck is based on externall observ-
ablee physical phenomena
p of the TOEE. This fam
mily describes the functctional requiirements
for tthe limitatioon of intelliigible emannations whicch are not directly
d addr
dressed by any
a other
com
mponent of CC C part 2.
473 The family “TO
OE Emanatiion (FPT_E
EMSEC)” is specified as
a follows.
474 FPT
T_EMSEC TOE
T Emanaation
475 F
Family behaviour:
476 Thiss family deffines requireements to m
mitigate inteelligible emaanations.
477 C
Componentt levelling:
FPT_EM
MSEC TOE E
Emanation 1
478 FPT
T_EMSEC.1 TOE emaanation
479 M
Managemennt: FPT_EM
MSEC.1
480 There are no management
m activities fooreseen.
481 A
Audit: FPT__EMSEC.1
482 There are no acctions defineed to be audditable.
FPT_EMSEC.1 TOE
T emana
ation
483 H
Hierarchicaal to: No oth
her componnents.
484 D
Dependencies: No dependencies.
485 FPTT_EMSEC..1.1 The TO OE shall noot emit [assiignment: typ
ypes of emisssions] in excess
e of
[assignment: sppecified limmits] enablinng access to
t [assignment: list of types of TS SF data]
and [assignmennt: list of typ
pes of user ddata].
486 FPTT_EMSEC..1.2 The TS SF shall enssure [assignnment: type of users] arre unable to
o use the
folloowing interrface [assign
nment: typee of connecttion] to gainn access to [assignmen nt: list of
typees of TSF daata] and [assignment: liist of types of user data
a].
he Family A
AVA_POI
487 The family “Vuulnerabilityy analysis off POI (AVA A_POI)” deefines requirrements forr evalua-
tor iindependentt vulnerabillity search aand penetrattion testing of POI.
488 The main charaacteristics of the new faamily, comp
pared to AV
VA_VAN, aare the follo
owing:
 The scoope of the requiremennts in AVA A_POI can be either th the whole POI
P (the
TOE) or o a consistent set of P
POI compo onents. Indeeed, the AV VA_VAN approach
a
that adddresses the TOE
T as a w
whole is nott suitable fo
or products w
with hetero
ogeneous
securityy levels.
th
Page 78 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
 In contrrast to AVA
A_VAN, thee assurance activities for
f vulnerabbility assesssment do
not varyy depending
g on the attaack potentiaal.
 A_POI10 onnly includess a single component A
Consequuently, AVA AVA_POI.1, which
is basedd on AVA_V
VAN.2 withh addition of
o POI-relateed specificitities.
 The attaack potentiaal is not fixeed in the deefinition of the
t componnent. The PP
P/ST au-
thor shaall directly assign the attack poteential that corresponds
c to the POII or POI
componnents to whiich the compponent appllies.
 The attaack potentiaal calculatioon table and the admisssible attackk potentialss are de-
fined inn [POI AttaackPot] whiich provides also a catalogue of POI-specifi fic attack
methodss. The miniimum attackk potential is i POI-Basiic. The geneeric AVA_V VAN at-
tack pottential calcu
ulation tablee defined in
n CEM and the resultinng scale do not
n meet
the POI specificitiees.
 AVA_P POI has dep pendencies oon ADV_F FSP, ADV_T TDS and A AGD. AVA_ _POI al-
lows to require (parrtial) implemmentation representatio
r on and the mmapping off SFR in-
to the immplementattion. The aiim is not to o evaluate the implemeentation rep presenta-
tion butt to use it to make peneetration testiing more effficient and m
more effecttive. The
mappingg shall allow the evaluuator to eassily find pieeces of harddware drawings and
source code
c that im
mplement thhe security functionality. In compparison, thee evalua-
tion of the
t TOE im mplementatioon representtation is reqquired from AVA_VAN N.3.
 AVA_PPOI does not pendent vuulnerability analysis
n mandatee any partiicular indep
method for the evaluator.
489 As uusual, the ST
S author is allowed to refine AVA_POI
A if
i needed, iin accordan
nce with
[CC
C1].
490 The actual set of
o AVA_PO OI requirem ments shall cover the wh hole TOE unnder evaluaation, i.e.
all tthe POI com
mponents th hat contribuute to the TSF
T being evaluated.
e A mapping between
the SFR and thhe implemen ntation reprresentation shall be req
quired to heelp the evalluator to
undeerstand the relation beetween the PPOI components and the TSF parrts under ev valuation
and gain confiddence that th
he set of PO
OI components are welll-defined.
491 The family “Vuulnerability analysis off POI (AVA
A_POI)” is defined
d as ffollows. Un
nderlined
text stands for additions
a with
w respect tto AVA_VA AN.2, thus allowing eaasy traceability.
492 We refer to Section 14
4 for a ddetailed ex
xplanation of the rellationship between
AVA
A_VAN.2 and
a AVA_P POI. { XE "A
AVA_VAN N.2/POI_1" }
493 AVA
A_POI Vullnerability analysis off POI
494 O
Objectives
10 Please note that the definition of AVA_POI haas changed co ompared to Veersion 2.0 of tthis document although
the same name for the family is kept. In the old vversion of AVA_POI, a specific attack pootential was in ncluded in
each hierrarchic level from AVA_P POI.1 to AVA A_POI.4; butt in the new version theree is only a sin ngle level
(AVA_PO OI.1) with thee attack potenttial completedd as a selectio
on for each iteration. This chhange might be
b confus-
ing betweeen devices certified underr different verrsions of the PP.
P Therefore,, if a readers oof the evaluattion docu-
mentationn (for examplle the according certificate)) encounter difficulties
d in interpreting
i thhe VAN-levell, they are
asked to check what version of th he PP applies (e.g. certifications under this PP will only use AV VA_POI.1,
whereas tthose under Version
V 2.0 of this documentt used up to AVA_POI.4).
A
th
4 Page 79
POI P
Protection Profile
495 POII vulnerabiliity analysis is an assesssment to determine whether poteential vulnerrabilities
idenntified in the POI couldd allow attaackers to violate the SF
FRs and thuus to perforrm unau-
thorrized accesss or modification to TO
OE assets, daata or functiionality.
496 Eachh of the seccurity requirrements of tthe new fam
mily AVA_P POI appliess either to th
he whole
TOE E (POI) undder evaluatiion or to a w well-defined set of TO
OE componeents selecteed by the
deveeloper. A seet of POI co omponents ccan be the target
t of a requirement
r t provided itt defines
the pphysical annd logical bo oundary of a TSF porttion, closed by SFR deependenciess. Hence,
the vvulnerabilitties identified on a set of POI commponents could comprromise one or more
of thhe SFRs witthin its boun ndary.
497 Wheen more thaan one instaantiation of AAVA_POI.1 is used in n a PP or STT, to apply to
t differ-
ent sets of absttract compo
onents, thenn it may be that
t the sep
parate instanntiations maap to the
sam
me concrete physical orr logical com mponents inn a particullar TOE (i.ee. more thann one of
the abstract com mponents maps
m to onee of the con
ncrete comp ponents). Inn this case the
t more
dem
manding requuirement ap pplies to thee concrete component.
498 C
Componentt Levelling
499 AVA A_POI inclludes a sing gle componnent; the atttack potenttial requiredd by an atttacker to
idenntify and exxploit the po
otential vulnnerabilities has
h to be asssigned by tthe PP or STT author
withhin the SAR R definition..
A
AVA_POI Vulnerability
V y analysis off POI 1
AVA_P
POI.1 POI vulnerabili
v ity analysiss
Depeendencies: ADV_ARC
A C.1 Security architecturre descriptio
on
ADV_F
FSP.2 Securrity-enforcin
ng functionaal specificattion
ADV_T
TDS.1 Basicc design
AGD_O
OPE.1 Operrational userr guidance
AGD_P
PRE.1 Prepaarative proccedures
Objeectives
500 A vuulnerabilityy analysis iss performedd by the evaaluator to asscertain thee presence of
o poten-
tial vvulnerabilitties.
501 The evaluator performs
p peenetration teesting on thee POI or PO
OI componeents, to conffirm that
the ppotential vuulnerabilitiees cannot bee exploited in
i the operaational envirronment of the POI.
Peneetration testing is perfformed by tthe evaluato or assumingg the attackk potential assigned
withhin the requuirement deffinition.
th
Page 80 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
Devveloper actioon elementss:
AVA_PPOI.1.1D The T develop per shall prrovide the [selection: POI, [assiggnment: listt of POI
componnents]] for teesting.
AVA_P POI.1.2D The

T develop per shall proovide the im
mplementattion represeentation andd a map-
ping of SFRs to thee implemen
ntation repreesentation of
o [selection
n: POI, [assiignment: lisst of POI
componnents amongg those in th
he scope of this requireement], nonee].
Conntent and preesentation elements:

e
AVA_P POI.1.1C The [selectio

on: POI, [asssignment: list
l of POI componentss]] shall be suitable
for testiing.
Evaaluator actioon elements::
AVA_P POI.1.1E Thhe evaluato he information providedd meets all require-

or shall conffirm that th
ments fo
for content and
a presentaation of eviddence.
AVA_P POI.1.2E Thhe evaluato or shall perrform a searrch of publlic domain sources to identify
potentiaal vulnerabilities in the [selection: POI, [assig
gnment: list of POI com
mponents]].
AVA_P POI.1.3E Thhe evaluato or shall perfform an indeependent vu ulnerability analysis off the [se-
lection: POI, [assiggnment: lisst of POI coomponents]]] using thee guidance documentation, the
functionnal specificaation, the design, the ssecurity arch
hitecture deescription [sselection: ass well as
the impplementationn representaation and thhe mapping of SFRs to o the implem mentation represen-
r
tation, nnone] to ideentify potenttial vulnerabbilities.
AVA_P POI.1.4E TheT evaluato or shall connduct penetrration testin

ng, based onn the identiified po-
on: POI, [assignment: list of POI compo-
tential vvulnerabilitiies, to deterrmine that tthe [selectio
nents]] is resistant to attacks performed
p bby an attack
ker possessing [assignm
nment: attack poten-
tial equaal to or highher than POOI-Basic atttack potentiial] [selectio
on: with a m
minimum atttack po-
tential ffor the [assignment: ideentification phase, explloitation phhase, attack potential faactor and
phase names] of [assignment: value and ((where applicable) unitts], empty].
{ XE "A AVA_VAN.2/POI_1" }
Applicaation note:
 The ‘emptyy’ value in the

t selectionn at the endd of AVA_P POI.1.4E inddicates thatt if there
aare no addditional consstraints on minimum attack
a poten
ntial in eithher identificcation or
eexploitationn phase then
n no text neeed be added
d at the end
d of the elem
ment.
 IIf more thann one constraint is requuired at thee end of AVA
A_POI.1.4E E, then thesee may be
cconcatenateed with the word “andd” between instances
i off the constaaint assignm
ment, e.g.
“…with a minimum
m atttack potenttial of 10 for
fo the explooitation phaase and a minimum
m
eelapsed tim
me attack potential factoor of 8 hourrs in the exp
ploitation phhase.”
th
4 Page 81
POI P
Protection Profile
9 Secu
urity Requirements
9.1 Secu
urity Functtional Requ
uirements
502 Thiss Protectionn Profile deffines the folllowing pacckages of SF

FRs that fullfil one or more
m ob-
jectiives for the TOE in eacch base PP:
 PIN Enttry Packagee
 ENC_PIN Packagee
 PLAIN__PIN Packaage
 IC Cardd Reader Package
 POI_DA
ATA Package
 CoreTSF Package
 PEDMiddleTSF Paackage
 MiddleT
TSF Packag
ge
 PED Proompt Contrrol Package
 Cryptoggraphy Pack
kage
 Physicaal Protection
n Package
503 The main SFRs of these packages

p arre mapped tot the EPC requiremennts they imp plement,
eitheer in the texxt of the SF
FR or in appplication no
otes, or both
h: EPC requuirements th hat come
directly from PCI
P PTS V4 are referennced with th he “PCI” ideentifier; othherwise, the identifi-
er “EEPC PLUS” or “EPC-C CHIP-ONL LY” is used.. The annexx in chapter 13.1 recallss the full
set oof EPC reqquirements anda the annnex in chaptter 13.2 preesents the m mapping of EPC re-
quirrements to SFR
S in this Protection
P P
Profile.
504 Som
me of PCI A.x
A and PCI D.x securitty requirem
ments have been
b identifiied not to be securi-
ty ffunctional ones. These securityy requirements are in ntroduced as refinem ments of
ADVV_ARC (seee section 9..2.2.31)
505 In thhe packagess, Security Function
F Poolicies (SFPP) are descriibed. Each SSFP is associated to
one package. Cryptograph
C hy and Physsical Protecction Packages do not have an asssociated
policy. The deffinition of th
he differentt entities paart of the SF
FPs has been
en determineed in the
folloowing mannner:
 Subjectss are SPD subjects (secction 5.3) orr SPD userss (section 5..2)
 Objects or information are asssets (section
n 5.1)
 Securityy attributes are assets oor subjects properties
p
 Roles arre SPD userrs (section 44.2)
 Operatioons are the operations uused in EPC
C requiremeents
th
Page 82 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
Value (forr security
Policy Entity
Name attributes) Definition
Cardhollder 5.2.1
Subject
keypad 5.3
PIN 5.1
any data thaat can be en-
PIN_E ENTRY Infor-- Informattion tered in the POI via the
mation fflow control SFP
S keypad whicch is not the
non-PIN
N data PIN
PIN digits capture on
try
PIN entr keypad
Operatio
on
non-PIN dig gits capture
non-PIN
N data entry on keypad
Subject PED 5.3

IC Cardd Reader 5.3
ENC_PIIN 5.1
Informattion
ENC_PIIN_SK 5.1
encrypteed (ENC_PIN
N) online 5.1
encrypteed (ENC_PIN
N) offline 5.1
ENC_P
PIN Informatioon Attributee
Flow
w Control SFP validity
(ENC_P PIN_SK) boolean based on exp
piration time
purposee encryptionn (key, PIN, key usage: encryption

e or
(ENC_P PIN_SK) data) or au
uthentication authenticatio
on
Terminaal Managemen
nt System 5.2.2
Role Terminaal Administrattor 5.2.1
Risk Maanager 5.2.2
Operatio
on send data transferr
PED 5.3
Subject
IC Cardd Reader 5.3
PLAIN__PIN 5.1
Informattion
PLAIN__PIN_SK 5.1
PLAIN N_PIN Infor-- validity
mationn Flow Controol (PLAIN N_PIN_SK) boolean based on exp
piration time
SFP Attributee
purposee encryptionn (key, PIN, key usage: encryption
e or
(PLAINN_PIN_SK) data) or au
on
Terminaal Managemen
nt System 5.2.2
Role
Terminaal Administrattor 5.2.1
Operatio
on send data transferr
Subject IC Cardd Reader 5.3
ICCarddReader Inforr-
mationn Flow Controol PLAIN__PIN 5.1
SFP Informattion
PLAIN__PIN_SK 5.1
th
4 Page 83
POI P
Protection Profile
Policy Entity
Terminaal Managemen
nt System 5.2.2
Role
Terminaal Administrattor 5.2.1
data receptio
on and trans-
Operatio
on
receive,, send fer
Subject POI andd its Payment Application Logic
L 5.3
Paymennt Transaction Data 5.1
POI Maanagement Daata 5.1
POI_SK
K 5.1
display, beeper, printer:
Object any commun nication in-
terface from
m the POI or
from an exteernal IT enti-
ty controlled
d by the POI
communicatting to the
Cardhollder communiication interface Cardholder
POI Management annd validity (POI_SK) boolean based on exp

piration time
Paymeent Transactionn encryptionn (key, PIN, key usage: encryption
e or
Data A
Access Controol purposee (POI_SK) data) or au
on
SFP
Attributee access rright right to acceess POI Man-

(MAN__DAT, agement Daata or Pay-
PAY_D DAT boolean ment Transaaction Data
authenticity of POI
authentiicity Managemen nt Data or
(MAN__DAT, Payment Traansaction
PAY_D DAT) boolean Data
Role Acquireer System 5.2.2
send data transferr
Operatio
on receive data receptio
on
access interface acccess
Subject Core Looader 5.3
Core L
Loader Accesss Object CORE__SW 5.1
Coontrol SFP
data or softw
ware down-
Operatio
on
downloaad load
Subject PED Miiddle Loader 5.3
PED Middle Loader Ac-
A
Object PED_M
MIDDLE_SW 5.1
cess Control SFP
Operatio
on downloaad data transferr
Subject Paymennt Application
n Loader 5.3
Paymeent Applicationn
Loader Access Contrrol Object PAYME
ENT_APP 5.1
SFP
Operatio
Subject Middle Loader 5.3
Middle Loader Access
Object POI_SW
W 5.1
Coontrol SFP
Operatio
th
Page 84 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
Policy Entity
Subject ICCR L
Loader 5.3
ICCR L
Loader Accesss
Object ICCR_S
SW 5.1
Coontrol SFP
Operatio
Subject POI com
mponents 3.2.1.4
PED Diisplay 5.3
PED Keeypad 5.3
Promptss cf Glossary
Object
PIN 5.1
PED_M
MIDDLE_PK 5.1
PED_M
MIDDLE_SK 5.1
entry digits capturre on keypad
Operatio
on
PED P
Prompt Controol display data display
y on screen
SFP PED Display usage
stands for diisplaying
PIN displaay PIN data
PED Display usage
stands for diisplaying
usage (P
PED Display) non-PIN display
d non-PIN datta
Attributee
PED Keypad usage
stands for en
ntering PIN
PIN entry data
PED Keypad usage
stands for en
ntering non-
usage (P
PED Keypad) non-PIN en
ntry PIN data
Taable 12: En
ntities defin
nition in Security Function Policcies
9.1.1 Defiinition of SFR

S packagges
9.1.1.1 PIN Entrry Package
FDP_IF
FC.1/PIN_E
ENTRY Su
ubset inform
mation flow
w control
Dependdencies: FDP P_IFF.1 Sub

bset inform
mation flow control
c not satisfied buut justified: there is
no rule to specify for
f PIN_EN NTRY SFP iin FDP_IFF F.1 apart from the one aalready in
FDP_IT TC.1/PIN_E ENTRY.
FDP_IF FC.1.1/PIN
N_Entry The TSF shalll enforce thhe PIN ENT
TRY Inforrmation Flo
ow Con-
trol SFPP on
subjects: Caardholder, PED keyp ad
innformation
n: PIN, non
n-PIN data
ooperations: PIN entry,, non-PIN d
data entry..
th
4 Page 85
POI P
Protection Profile
FDP_IT
TC.1/PIN_E
ENTRY Im
mport of usser data witthout securrity attribuutes
Dependdencies: FDP P_ACC.1 Subset

S accesss control, or
o FDP_IFC C.1 Subset innformation flow
control satisfied byy FDP_IFC.1/PIN_ENT TRY; FMT_ _MSA.3 Staatic attributte initialisation not
satisfiedd, but justifiied: The PIN i the TOE bbut at the Isssuer or
N verificatioon value is not stored in
in the ICC Card inseerted in the TOE.
T Thereefore neitherr access con
ntrol, nor innformation flow
f
control, no static atttribute initiialisation is required.
FDP_ITTC.1.1/PIN
N_ENTRY The T TSF sshall enforcce the PIN ENTRY Informatio on Flow
Control SFP whenn importing user data, ccontrolled under
u the SF
FP, from ouutside of the TOE.
FDP_IT TC.1.2/PIN N_ENTRY The T TSF shhall ignore any

a security
y attributes associated with the
user datta when impported from
m outside thee TOE.
FDP_IT TC.1.3/PIN N_ENTRY The T TSF shhall enforcee the follow wing rules w
when importting user
data conntrolled undder the SFP from outsidde the TOE:
P
PCIB15: PIIN is only allowed too be entereed at the keypad assiigned to Co oreTSF.
The enttry of any other dataa must be separate from f the PPIN entry process
avoidingg accidenta
al display oof PIN at thet display y. If any otther data and
a PIN
are enteered at thee same keyypad, the datad entry and the PPIN entry shall be
clearly separate
s op
perations.
[aassignmentt: additionaal control rrules].
Applicaation note:
If thee author of the
t ST has non additionaal rules fill it with nonee.
FPT_EMSEC.1/P
PIN_ENTRY
Y TOE Emanation
E
Dependdencies: No dependenciies.
FPT_EMSEC.1.1//PIN_ENTRY The TO OE shall nott emit

P
PCIA11: au udible tonees during PPIN entry, that,
t if useed, could alllow to disttinguish
the entered PIN digits,
P
PCIA5: sou und, electroo-magneticc emissionss, power co onsumptionn or any otther ex-
ternal ch
haracteristtic availablee for monittoring,
P
PCIB5: the entered PIIN digits aat the display (any arrray relatedd to PIN en ntry dis-
plays on
nly non-signnificant sym
mbols, e.g. asterisks)
in exxcess of nonne enabling
g access to entered an nd internallly transmiitted PIN digit
d and
nonee.
FPT_EMSEC.1.2//PIN_ENTRY The TS SF shall enssure that users are unnable to usee the fol-
lowing interface
P
PCIA11: au udible toness, if used,
th
Page 86 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
P
PCIA5: sou und, electroo-magneticc emissionss, power co onsumptionn or any otther ex-
ternal chharacteristtic availablee for monittoring,
P
PCIB5: the entered PIIN digits aat the display (any arrray relatedd to PIN en
ntry dis-
plays onnly non-signnificant sym
mbols, e.g., asterisks)
to gaain access too entered and internaally transmiitted PIN digit
d and noone.
Applicaation note:
PC CIA5 does not
n apply inn the POI-C CHIP-ONLY Y configurattion.
FIA_UA
AU.2/PIN__ENTRY User
U authen
ntication beefore any acction
Dependdencies: FIA
A_UID.1 Tim
ming of ideentification, satisfied by
y FIA_UID..1/PIN_ENT
TRY
FIA_UA AU.2.1/PINN_ENTRY The TSF shhall requiree each user to be succeessfully auth henticat-
ed beforre allowing any other TSF-mediat
T ted actions on
o behalf off that user.
Refinemment:
The TSF shall reqquire each user u to be ssuccessfullyy authenticaated before allowing access
a to
sensitivve services on
o behalf off that user.
Applicaation note:
Acceess to sensittive servicess shall be eiither via duual control or
o resultingg in the deviice being
unnable to usee previouslyy existing keey data.
PCIB B7: Access to sensitivee services reequires auth hentication. Sensitive sservices pro
ovide ac-
ceess to the underlying
u sensitive
s funnctions. Sensitive funcctions are tthose functiions that
prrocess sensitive data such
s as cryp
yptographic keys, PINss, and passswords. Enttering or
exxiting sensittive servicess shall not rreveal or oth
herwise affe
fect sensitivee data.
FIA_UIID.1/PIN_E
ENTRY Timing of ideentification
n
FIA_UIID.1.1/PIN N_ENTRY The T TSF shhall allow access to noon sensitivee services on
o behalf
of the uuser to be peerformed before the useer is identifiied.
FIA_UIID.1.2/PIN N_ENTRY TheT TSF shhall require each user to o be successsfully identtified be-
fore alloowing any other
o TSF-m
mediated acttions on beh
half of that user.
FTA_SSL.3/PIN__ENTRY TS
SF-initiated
d terminattion
FTA_SSL.3.1/PIN N_ENTRY The TSF sshall termin nate an interractive sesssion after a limited
numberr of actionss that can be perform med and also after ann imposed ttime limit. In both
cases th
he PED is forced
f to reeturn to its normal mo
ode.
th
4 Page 87
POI P
Protection Profile
Applicaation note:
PCIB B8: To minnimize the risks
r from uunauthorizeed use of seensitive serv
rvices, limitts on the
nuumber of acctions that can
c be perfoormed and a time limit imposed, af after which the PED
11
is forced to return to its normal modde .
9.1.1.2 ENC_PIN
N Package
FDP_IF
FC.1/ENC__PIN Subseet informattion flow co
ontrol

bset inform
mation flow control
c
satisfiedd by FDP_IF
FF.1/ENC__PIN
FDP_IF FC.1.1/ENC C_PIN Thee TSF shall enforce thee ENC_PIN

N Informaation Flow Control
SFP on
subjects: PE
ED, IC Carrd Reader
innformation
n: ENC_PIN N, ENC_PIIN_SK
ooperations: send.
{ XE "FFDP_IFF.1/EENC_PIN" }
FDP_IF
FF.1/ENC__PIN Simplle security attributes
Dependdencies: F
FDP_IFC.1 Subset informaation flow
w controol satisfieed by
FDP_IF FC.1/ENC_P PIN,
FMT_M MSA.3 Statiic attribute initialisation
i n not formaally satisfied
d however jjustified as follows:
The maanagement of
o the attrib butes is defiined by FMMT_MSA.1/E ENC_PIN, where certaain roles
are allow
wed to mannage them. These roless are also reesponsible for initial vvalues, wherre appli-
cable.
FDP_IFFF.1.1/ENC C_PIN The TSF shall enforce thee ENC_PIN N Informat ation Flow Control
SFP bassed on the following
f ty
ypes of subj ect and info
ormation security attribbutes:
subjects: PE ED, IC Carrd Reader
nformation
in n: ENC_PIN N, ENC_PIIN_SK
sttatus of EN NC_PIN: on nline encryypted, offlinne encrypteed
sttatus of EN NC_PIN_SK K: validityy, purpose [assignmen nt: other EN NC_PIN_S SK secu-
rity attrributes].
FDP_IF FF.1.2/ENC C_PIN The TSF shall ppermit an in nformation flow

f betweeen a controllled sub-
ject andd controlled information
n via a conttrolled operation if the following rrules hold:
TThe PED seends the EN NC_PIN in n encrypted d form to the
t IC Carrd Reader (offline)
or to thee Acquirer (online).
11 "Normmal mode" meaans a mode, where

w use of seensitive functiions or servicees is not possiible without new au-
thenticatiion of the userr.
th
Page 88 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
P
PCIB6: Thee PED encciphers EN NC_PIN witth the appropriate deedicated on nline or
offline encryption
e key immed diately afteer ENC_PIIN entry is complete and has
been siggnified as su
uch by the Cardholdeer.
PCID4.1: Iff the PED encryptingg the PIN and
P a the IC CC reader aare not inttegrated
into the same secure module,, and the cardholder verificationn method is i deter-
mined too be: Encip phered PIN N, the PIN block shalll be enciphhered betw ween the
PED an nd the ICC reader ussing either an authen nticated encciphermentt key of
the IC card, or in accordance
a e with ISO 9564.
P
PCID4.3: Iff the PED encryptingg the PIN and a the ICC reader aare integra ated into
the samee secure module, and the cardho older verifiication metthod is deteermined
to be: Enciphered
E PIN, the P PIN block shall be en nciphered uusing an authenti-
cated ennciphermen nt key of th
he IC card.
P
PCIB10, EPPCPlusB10.a: The PE ED uses cryyptographicc means to prevent th he use of
the PEDD for exhaustive PIN d determination.
FDP_IF C_PIN The TSF shall enforce th

FF.1.3/ENC he [assignm
ment: addittional information
flow control SFP rules].
r
FDP_IF FF.1.4/ENC C_PIN The TSF shall eexplicitly auuthorise an informationn flow baseed on the
followinng rules: [aassignment:: rules, bassed on secu
urity attribu
utes, that eexplicitly au
uthorise
informaation flowss].
FDP_IF FF.1.5/ENC C_PIN The TSF shall eexplicitly deny d an info

ormation floow based on n the fol-
lowing rrules:
T
The PED dooes not send ENC_PIN N or ENC_ _PIN_SK before
b beingg encrypted d to any
other suubject outside CoreTS SF.
P
PCIB13: It is not posssible to enc rypt or deccrypt any arbitrarya ddata using any
a PIN
encryptiing key or keyk encryp pting key co ontained in n the PED. T The PED must
m en-
force thhat data keeys, key en nciphermen nt keys, and PIN enccryption keeys have
different values.
P
PCIB14: Th here is no mechanism
m m in the PE ED that wou uld allow tthe outputtting of a
private oro secret clleartext keyy or clearteext PIN, th he encryptioon of a key y or PIN
under a key that might itsellf be disclo osed, or thee transfer of a clearttext key
from a component
c of high seccurity into a componeent of lesserr security.
Applicaation note:
If thee author of the ST has no additionnal informattion flow co ontrol SFP rrules or rules based
onn security attributes thee corresponnding assign nments shalll be filled wwith none.
Validdity and purrpose are seecurity attriibutes which h are only immplicitly ussed in the ru
ules.
PCIB B10, EPCPlusB10.a: The T intendeed meaning of “preven nt” is to stop
op an attackk; exam-
plles (not exhhaustive) arre the use of unique keey per transsaction, or the use of ISO I PIN
bllock format 1 (random included). B By contrastt, slowing down
d an attaack is considered as
a ‘deterrent’ that does not
n meet thiss requiremeent.
This SFR forcees the imm mediate enciipherment of ENC_PIIN. The ennciphering must be
unnique to thee transactionn, e.g. it is nnot allowed
d to producee the same eenciphered formf for
a PIN in diifferent tra ansactions tto avoid recognition of PIN vaalues. Addiitionally,
ENNC_PIN is only allowed to be ennciphered with w cryptog graphic keyss only used d for PIN
th
4 Page 89
POI P
Protection Profile
enncipherment and not used for any other purpose. The SFR enforces that t any
ENNC_PIN_SK K is differennt from anyy other cryptographic key.
k Howeveer accidenta
al choice
off the same value
v is allo
owed.
FMT_M
MSA.1/ENC
C_PIN Management oof security attributes

o FDP_IFC C.1 Subset innformation flow
control satisfied byy FDP_IFC.1/ENC_PIN N
FMT_S SMR.1 Secuurity roles saatisfied by F
FMT_SMR.1/ENC_PIN N
FMT_S SMF.1 Specification of Managemeent Function ns not satisffied but justitified. Theree is no
need to specify addditional man
nagement fuunctions beccause modiffication of ssecurity attrributes
is sufficcient.
FMT_M MSA.1.1/EN NC_PIN Th he TSF shalll enforce th

he ENC_PIIN Informaation Flow Control
SFP too restrict the
t ability to modiffy the seccurity attrib butes of E ENC_PIN and of
ENC_P PIN_SK to Risk Man nager and [[selection: Terminal Managemeent System m and/or
Termin nal Adminisstrator].
Applicaation note:
Statuus of ENC_P PIN may bee modified bby the Risk Manager.
M Status
S of EN
NC_PIN_SKK may be
modified by Terminal
T Management
M System and d/or Termin
nal Administtrator.
FMT_S
SMR.1/ENC
C_PIN Security roles
Dependdencies: FIA
A_UID.1 Tim
ming of ideentification satisfied
s by FIA_UID. 1/ENC_PIN
N
FMT_S SMR.1.1/EN NC_PIN Th he TSF shaall maintain

n the roles [sselection: T
Terminal Manage-
M
ment Syystem and//or Terminal Adminisstrator] andd Risk Man nager.
FMT_S SMR.1.2/EN NC_PIN Th he TSF shalll be able too associate users

u with rooles.
Applicaation note:
Termminal Manaagement Syystem and/oor Termina al Administtrator is reelated to status
s of
EN NC_PIN_SK K, Risk Man
nager is rellated to stattus of ENC_
_PIN.
FIA_UIID.1/ENC__PIN Entry
y Timing off identificattion
FIA_UIID.1.1/ENC C_PIN Thee TSF shall allow [assignment: list of TSF--mediated actions]
on behaalf of the useer to be performed befo
fore the userr is identifieed.
th
Page 90 Version 4.0
4 6 March,
M 2015
Protection Profile
POI P
FIA_UIID.1.2/ENC C_PIN The TSF shall rrequire each h user to bee successfullly identifieed before
allowingg any other TSF-mediaated actionss on behalf of
o that user.
Applicaation note:
The timing of identificatio
i on for actioons is relatted to the Terminal
T M
Managementt System
annd/or the Teerminal Adm
ministrator and/or the Risk
R Manag ger.
FDP_R
RIP.1/ENC__PIN Subseet residual informatio
on protectio
on
FDP_R RIP.1.1/ENC C_PIN Thee TSF shall ensure that any previous informattion contentt of a re-
source iis made unaavailable up pon the [sellection: alloocation of thhe resourcee to, dealloccation of
the resoource from]] the follow wing objectss: [assignmeent: sensitiv ve objects w with residu
ual infor-
mation].
Refinem ment:
FDP_R RIP.1.1/ENC C_PIN Thee TSF shall ensure that any previous informattion contentt of a re-
source iis made unnavailable uponu the deeallocation of the reso ource from m the follow wing ob-
jects: E
ENC_PIN im mmediately y after beinng encryptted, temporrary cryptoographic keys k [as-
signmen nt: sensitivve objects with
w residuaal informattion].
Dealloccation may occur upon n completioon of the trransaction or if the PE ED has tim
med-out
waitingg from the Cardholder
C r or merchhant.
Applicaation note:
PCIB B6: Sensitivve data shall not be reetained any longer, or used moree often, than n strictly
neecessary. Online
O PINs are encryppted within the PED immediatelyy after PIN N entry is
coomplete andd has been signified ass such by th he cardhold der, e.g., viaa pressing the
t enter
buutton. The PED
P must automaticall
a ly clear its internal
i buff
ffers when eeither: The transac-
tioon is complleted, or thee PED has ttimed out wa aiting for th
he responsee from the ca ardhold-
err or merchaant.
If noo other senssitive objectts with residdual inform mation exist the assignm ment shall be filled
with none.
th
4 Page 91
POI P
Protection Profile
FDP_IT
TT.1/ENC__PIN Basicc internal trransfer pro
otection

o FDP_IFC
C.1 Subset innformation flow
control satisfied byy FDP_IFC.1/ENC_PIN N
FDP_IT TT.1.1/ENC C_PIN Thee TSF shalll enforce th he [assignm ment: acceess controll SFP(s)
and/or informatioon flow con ntrol SFP((s)] to preveent the [sellection: dissclosure, modifica-
m
tion, losss of use] of
o user data when it is ttransmitted between ph hysically-seeparated parrts of the
TOE.
Refinemment:
FDP_IT TT.1.1/ENC C_PIN Thee TSF shalll enforce the ENC_PIN N Informaation Flow Control
SFP to prevent thee disclosuree of ENC_P PIN and ENC_PIN_S
E SK [assignm ment: otheer secret
informaation, like administra
a ation passwwords] when n they are trransmitted bbetween phy ysically-
separateed parts of the
t CoreTS SF and wheen they are processed by the CorreTSF.
Applicaation note:
The rrefinement replaces thee SFR abovve, thus the SFR above shall not bbe considereed by the
auuthor of thee ST. This SFR
SF requiress that ENC_C_PIN and ENC_PIN_S
E SK shall be protect-
edd when theyy are transmmitted betweeen physicallly-separateed parts of tthe POI.
FTP_TRP.1/ENC__PIN Trusted path
FTP_TRP.1.1/EN NC_PIN The TSF shalll provide a communiccation path between ittself and
remote users that is logically distinct froom other co ommunication paths annd providess assured
identificcation of itss end pointss and proteection of thee communiccated data ffrom unautthorized
ENC_P PIN_SK rep placement anda ENC_P PIN_SK misuse.
m
FTP_TRP.1.2/EN NC_PIN Thee TSF shalll permit rem

mote users to initiate communicaation via
the trustted path.
FTP_TRP.1.3/EN NC_PIN Th he TSF sshall requiire the usse of the trusted path p for
ENC_P PIN_SK rep placement anda ENC_P PIN_SK ussage.
Applicaation Note:
PCIC C1: If the PED
P can hold multiple PIN encryp ption keys and
a if the keey to be useed to en-
crrypt the PIN
N can be exxternally seelected, then n the PED prohibits
p unnauthorisedd key re-
pllacement annd key misusse.
Notee that this is relevant for the onlinee PIN case, usually not for the offlline PIN casse.
If thee PED doess not hold multiple
m PINN encryptioon keys or iff the key too be used to
o encrypt
thhe PIN cannnot be exterrnally selectted, this req
quirement isi not appliccable, and is there-
foore considerred to be satisfied.
The tterm “exterrnally selected” meanss: selected by b an interfface functioon to the PE ED com-
poonent that performs
p th
he PIN encrryption. Both human in nterfaces aand comman nd inter-
faaces are connsidered, annd both direect and inddirect. Exterrnal selectioon also inclludes in-
th
Page 92 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
teerference wiith or manippulation of tthe data by which the PED
P selectss the key to be used.
K
Keys may be selected th hrough the P PED keypad d, or comm
mands sent fr from anotheer device
suuch as an electronic
e caash registerr. Any commmands sentt from anotther device must be
crryptographiically autheenticated too protect ag gainst mann-in-the-midddle and reeplay at-
taacks, this reqquirement is
i not appliccable to devvices that do not includde command d for ex-
teernal key selection, or cannot holdd multiple key
k hierarch hies relatedd to PIN enccryption.
Iff an applicaation can seelect keys fr
from multiplle key hieraarchies, thee PED mustt enforce
auuthenticatioon of comma ands used ffor externall key selectiion. If the P
PED only allows an
appplication to
t select keyys from a siingle hierarrchy, then command
c auuthenticatio
on is not
reequired.
9.1.1.3 PLAIN_P
PIN Packag
ge
FDP_IF
FC.1/PLAIIN_PIN Sub
bset inform
mation flow
w control
FDP_IF FC.1.1/PLAAIN_PIN The

T TSF shaall enforce the
t PLAIN_
_PIN Inforrmation Flo
ow Con-
trol SFPP on
subjects: PE
ED, IC Carrd Reader
innformation
n: PLAIN_PPIN, PLAIIN_PIN_SK K
ooperations: send.

bset inform
mation flow control,
c
FF.1/PLAINN_PIN
FDP_IF
FF.1/PLAIN
N_PIN Sim
mple securitty attributees
Dependdencies: F
FDP_IF FC.1/PLAIN N_PIN,
The maanagement of the attriibutes is deefined by FMT_MSA
F .1/PLAIN_PPIN, wheree certain
roles arre allowed to
t manage them.
t Thes e roles are also respon nsible for innitial values, where
applicabble.
FDP_IF FF.1.1/PLA AIN_PIN The TSF shaall enforce the t PLAIN_ _PIN Inforrmation Flo ow Con-
trol SFP
P based on the followin ng types off subject and
d informatio
on security aattributes:
subjects: PEED, IC Carrd Reader
in
nformation n: PLAIN_P PIN, PLAIIN_PIN_SK K
sttatus of PLLAIN_PIN_SK: valid dity, purpose [assignm ment: otherr PLAIN_P PIN_SK
security attributes]]
FDP_IF FF.1.2/PLA
AIN_PIN The TSF shaall permit an a informatiion flow beetween a co ontrolled
subject and controllled information via a controlled operation iff the follow
wing rules hold:
h [se-
lection:: PCID4.2, PCID4.4] where
w
P
PCID4.2: Iff the PED and the IC CC reader area not integrated intto the samee secure
module, and the cardholdeer verificattion metho od is deteermined to o be: A
th
4 Page 93
POI P
Protection Profile
Plaintexxt PIN, thee PIN block k shall be encipheredd from thee PED to thet ICC
reader (the ICC reader wiill then decipher th he PIN forr transmisssion in
plaintexxt to the IC card) in acccordance with
w ISO 9564.
PCID4.4: If the PED and the IICC readeer are integ
P grated intoo the samee secure
module, and the cardholdeer verificattion metho od is deteermined to o be: A
Plaintexxt PIN, thenn encipherm ment is not required if the PIN block is trransmit-
ted whoolly through h a protectted environ
nment (as defined inn ISO 9564). If the
plaintexxt PIN is trransmitted to the ICC C reader thhrough an unprotecteed envi-
ronmentt, the PIN block
b shall be encipheered in acco
ordance wiith ISO 956 64.
FDP_IF FF.1.3/PLA AIN_PIN The TSF shhall enforce the [assign

nment: addditional info
ormation
flow conntrol SFP ruules].
FDP_IF FF.1.4/PLA AIN_PIN The TSF shaall explicitly y authorise an informaation flow based
b on
the folloowing ruless: [assignm
ment: rules,, based on
n security attributes,
a that expliccitly au-
thorise informatioon flows].
FDP_IF FF.1.5/PLA AIN_PIN The TSF shaall explicitly y deny an information

i n flow based on the
followinng rules:
T
The PED doesd not seend Cipherrtext PLAIIN_PIN (en ncrypted oor in clearrtext) or
Cleartexxt PLAIN_PIN to anyy other subjject than th he IC Cardd Reader.
T
The PED doesd not sen nd the Cip phertext PL LAIN_PIN to any subbject beforre being
encrypteed.
T
The PED doesd not sen nd PLAIN N_PIN_SK (if any) beefore beingg encrypted d to any
other su
ubject beforre being en ncrypted.
P
private or
o secret clleartext keyy or clearteext PIN, th he encryptioon of a key y or PIN
from a component
Applicaation note:
onn security attributes thee corresponnding assignnments shalll be filled w
with none.
Ciphhertext PLAIIN_PIN hollds in POI aarchitectures with phyysically sepaarated PED D and IC
Ca
Card Readerr.
Cleartext PLAIN N_PIN hold ds in POI arrchitecturess with PED and IC Carrd Reader integrat-
i
edd in the sam
me tamper-reesponsive bboundary.
Validdity and purrpose are seecurity attriibutes whichh are only im
mplicitly ussed in the ru
ules.
This SFR is relaated to tran nsfer of PLA AIN_PIN mandating
m th
he implemen entation of PCID4.2
P
orr PCID4.4 depending
d on
o the choseen implemen ntation.
th
Page 94 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
FDP_R
RIP.1/PLAIIN_PIN Sub
bset residu
ual informa
ation protecction
FDP_R RIP.1.1/PLA AIN_PIN The T TSF shaall ensure th hat any prev vious inform mation content of a
resourcee is made unnavailable upon
u the [seelection: alllocation of the
t resourcee to, dealloccation of
the resoource from] the following objects: [assignmen nt: list of ob
bjects]
Refinemment
The TSF F shall ensuure that any
y previous innformation content of a resource iis made unaavailable
upon the deallocattion of the resource
r frrom the following objects:
[sselection: Ciphertext
C PLAIN_P PIN immed diately afterr being enccrypted, Cleartext
C
PLAIN__PIN immeediately afteer being sent to the IC C Card Reaader]
teemporary cryptograp
c phic keys,
[aassignmentt: sensitive objects witth residuall informatio on].
med-out
C r or merchhant.
Applicaation note:
neecessary. Online
t enter
buutton. The PED
P must automaticall
i buff
he responsee from the ca ardhold-
err or merchaant.
If noo other senssitive objectts with residdual inform mation exist the assignm ment shall be filled
with none.
FDP_IT
TT.1/PLAIIN_PIN Bassic internall transfer protection
p

o FDP_IFC
control satisfied byy FDP_IFC.1/PLAIN_P PIN
FDP_IT TT.1.1/PLA AIN_PIN The T TSF shaall enforce the [assign nment: acccess controll SFP(s)
and/or informatioon flow con ntrol SFP((s)] to preveent the [sellection: dissclosure, modifica-
m
tion, losss of use] of
o user data when it is ttransmitted between ph hysically-seeparated parrts of the
TOE.
Refinem ment:
The TSF F shall enfoorce the PLLAIN_PIN Informatio on Flow Co ontrol SFP P to prevent the dis-
closure of [sselection: Cleartexxt PLAIN N_PIN, (Ciphertexxt PLAIIN_PIN,
PLAIN N_PIN_SK)] when they y are transm
mitted betweeen physically-separateed parts of the
t PED
or to thhe IC Card Reader.
Applicaation note:
auuthor of thee ST. This SFFR requiress that PLAIIN_PIN and d PLAIN_PIIN_SK shalll be pro-
teected when they
t are transmitted beetween physsically-separated parts of the POI.
th
4 Page 95
POI P
Protection Profile
FMT_M
MSA.1/PLA
AIN_PIN Managemen
M nt of securiity attributes
Dependdencies:
FDP_ACC.1 Subseet access co ontrol, or FDDP_IFC.1 Subset inform mation flow w control sattisfied
by FDP P_IFC.1/PLA AIN_PIN
FMT_S SMR.1 Secuurity roles saatisfied by F
FMT_SMR.1/ENC_PIN N
FMT_S SMF.1 Specification of Managemeent Function ns not satisffied but justitified. Theree is no
need to specify addditional man
nagement fuunctions beccause modiffication of ssecurity attrributes
is sufficcient.
FMT_M MSA.1.1/PL
LAIN_PIN N The TSF shall enforrce the PLAIN_PIN Informatio on Flow
Control SFP too restrict the abilityy to mod dify the security atttributes status of
PLAIN N_PIN_SK to
t [selection
n: Terminaal Managem
ment System and/or T
Terminal Adminis-
A
trator]..
FIA_UIID.1/PLAIN
N_PIN Enttry Timingg of identification
FIA_UIID.1.1/PLA AIN_PIN The T TSF shhall allow [assignmen nt: list of T

TSF-media
ated ac-
tions] oon behalf off the user to be perform
med before th
he user is id
dentified.
FIA_UIID.1.2/PLA AIN_PIN The T TSF shaall require eache user to

o be successsfully identified be-
fore alloowing any other
o TSF-m mediated acttions on behhalf of that user.
Applicaation note:
The ttiming of iddentification
n for actionns is related
d to Termina al Managem ment Systemm and/or
Teerminal Adm ministrator..
9.1.1.4 IC Card Reader

R Pacckage
FDP_IF
FC.1/ICCardReader Subset
S infoormation flow control

bset inform
mation flow control,
c
FF.1/IC Carrd Reader
FDP_IFFC.1.1/ICCCardReaderr The TSF shall enfo orce the IC

C Card Reeader Information
Flow Control SFPP on
subjects: IC
C Card Rea ader
innformation
n: PLAIN_P PIN, PLAIIN_PIN_SK
K
ooperations: receive, seend.
th
Page 96 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
FDP_IF
FF.1/ICCarrdReader Simple
S secu
urity attrib
butes
Dependdencies: F
FDP_IF FC.1/ICCarddReader,
The maanagement of the attriibutes is deefined by FMT_MSA
F .1/PLAIN_PPIN, wheree certain
roles arre allowed to
t manage them.
t Thes e roles are also respon nsible for innitial values, where
applicabble.
FDP_IF FF.1.1/ICC CardReaderr The TSF shall enfo orce the IC

C Card Reeader Information
Flow CControl SFP P based on the followiing types of
o subject an
nd informat
ation securitty attrib-
utes:
subjects: ICC Card Rea ader
in
nformation n: PLAIN_P PIN, PLAIIN_PIN_SK K
sttatus of PLLAIN_PIN_SK: valid dity, purpose [assignm
ment: otherr PLAIN_P PIN_SK
security attributes]]
FDP_IF FF.1.2/ICCCardReaderr The TSF shall perm mit an inforrmation floow between n a con-
trolled subject andd controlled
d informatioon via a coontrolled op
peration if tthe followiing rules
hold: [selection: PCID4.2, PC CID4.4] wh here
PC
CID4.2 (PED and IC C Card R Reader are not integrated intoo the one tamper- t
responsivve bounda ary): the IC Card d Readerr receives the Cip phertext
PLAIN_P PIN, deciph hers it and sends it to the IC Carrd,
PC
CID4.4 (PE ED and IC C Card Reeader are integrated into one ttamper-ressponsive
boundaryy): the IC Card
C Readeer receives the Clearttext PLAIN N_PIN and sends it
to the IC Card.
FDP_IFFF.1.3/ICC
CardReaderr The TSF shall enfo
orce the [asssignment: additiona
al infor-
mation flow contrrol SFP rulees].
FDP_IF FF.1.4/ICCCardReaderr The TSF shall expliccitly authorise an inforrmation flow based
on the ffollowing ruules: [assign
nment: rulees, based on
o security attributes,, that expliccitly au-
thorise informatioon flows].
FDP_IF FF.1.5/ICCCardReaderr The TSF shall expliccitly deny an informat ation flow based
b on
the folloowing rules:
The IC Carrd Reader does not seend PLAIN
T N_PIN (neither Cipheertext PLA AIN_PIN
nor Cleaartext PLAAIN_PIN) too any otherr entity tha an the IC CCard. The IC I Card
Reader does not seend PLAIN N_PIN_SK (if ( any) to any
a entity.
P
private or
o secret clleartext keyy or clearteext PIN, th
he encryptioon of a keyy or PIN
from a component
th
4 Page 97
POI P
Protection Profile
Applicaation note:
Ciphhertext PLAIIN_PIN hollds in POI aarchitectures with phyysically sepaarated PED D and IC
Ca
Card Readerr. Cleartext PLAIN_PIN N holds in POI
P architeectures withh PED and IC Card
Reeader integrrated in thee same tampper-responsive boundarry.
If thee author off the ST hass no "additi tional inform
mation flow w control SF FP rules" or
o "rules
baased on secuurity attribu
utes" the coorresponding g assignmen nts shall bee filled with "none".
This SFR is relaated to tran nsfer of PLA AIN_PIN mandating
m th
he implemen entation of PCID4.2
P
orr PCID4.4 depending
d on the chossen implementation. Both are reppeated here (related
too the PLAINN_PIN Packkage) becausse of the diff fferent attacck potential.l.
FDP_R
RIP.1/ICCardReader Subset
S resiidual inform
mation pro
otection
FDP_R RIP.1.1/ICC CardReaderr The TSF shall ensuree that any previous
p info
formation coontent of
a resourrce is made unavailable upon the [selection: allocation of o the resouurce to, dealllocation
of the reesource from owing objec ts: [assignm
m] the follo ment: list of objects]
Refinemment
upon the deallocattion of the resource
r frrom the following objects:
[sselection: Ciphertext
C PLAIN_PIIN immediiately after being decrrypted and d sent to
the IC Card,
C Clea
artext PLA AIN_PIN im mmediately y after beiing sent to o the IC
Card]
teemporary cryptograp
c phic keys,
[aassignmentt: sensitive objects witth residuall informatio on].
med-out
C r or merchhant.
Applicaation note:
neecessary. Online
t enter
buutton. The PED
P must automaticall
i buff
he responsee from the caardhold-
err or merchaant.
If noo other senssitive objectts with residdual informmation exist the correspponding asssignment
shhall be filledd with none.
th
Page 98 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
FDP_IT
TT.1/ICCardReader Basic
B intern
nal transfeer protectio
on

o FDP_IFC
control satisfied byy FDP_IFC.1/ICCardReeader
FDP_IT TT.1.1 The TSF shall enforce thee [assignmeent: access control SF FP(s) and/oor infor-
mation flow contrrol SFP(s)] to prevent tthe [selectio on: disclosuure, modifiication, losss of use]
of user ddata when it
i is transmitted betweeen physicallly-separated d parts of the
he TOE.
Refinemment:
FDP_IT TT.1.1/ICC CardReaderr The TSF F shall enfo orce the ICC Card Reeader Information
Flow Control SFP P to preventt the disclossure of [seleection: Cleartext PLA AIN_PIN, (Cipher-
(
text PLLAIN_PIN,, PLAIN_P PIN_SK)] w when they area transmittted to the IC Card or o when
they are processed d by the ICC Card Reaader.
Applicaation note:
auuthor of thee ST. This SFFR requiress that PLAIIN_PIN and d PLAIN_PIIN_SK shalll be pro-
teected when they are trransmitted between ph hysically-sepparated paarts of the IC
I Card
Reeader.
FDP_A
ACC.1/ICCR
RLoader Subset
S acce ss control
Dependdencies: FDP P_ACF.1 Security attriibute based access conttrol not sati sfied but ju
ustified:
the corrrespondent access
a contrrol is satisfiied by FDP_
_ITC.1/ICC
CRLoader
FDP_A ACC.1.1/ICCRLoaderr The TSF sshall enforcee the ICCR R Loader AAccess Conttrol SFP
on
subject: ICC CR Loaderr
oobjects: ICCR_SW, [assignmentt: list of data, d in particular crryptograph
hic keys,
controlleed under th his policy]
ooperation: download.
d
Applicaation note:
The "cryptograpphic keys" stands for PIIN encryptiion keys (e.gg. PLAIN_P PIN_SK) orr for any
otther key. Thhe operation ns are any managemen nt operation
n on IC Car
ard Reader software
s
annd data.
If no list of dataa exist the asssignment sshall be filleed with “non
ne”.
FDP_IT
TC.1/ICCR
RLoader Im
mport of us er data witthout securrity attribut
utes
Dependdencies:
FDP_ACC.1 Subseet access co ontrol, or F FDP_IFC.1 Subset info ormation floow control satisfied
by FDP
P_ACC.1/ICCCRLoader
FMT_MMSA.3 Statiic attribute initialisatioon not satisffied but justtified: theree are no seccurity at-
th
4 Page 99
POI P
Protection Profile
tributes to be mannaged for downloadingg objects. Terminal
T Management
M System deecides to
update/ddownload thhem or not.
FDP_ITTC.1.1/ICCCRLoader The T TSF shhall enforcee the ICCR Loader A Access Conttrol SFP
when im
mporting user data, con
ntrolled undder the SFP, from outsid
de of the TO
OE.
FDP_IT TC.1.2/ICC CRLoader TheT TSF shhall ignore any

a security
user datta when impported from
m outside thee TOE.
FDP_IT TC.1.3/ICC CRLoader TheT TSF shhall enforcee the followwing rules wwhen importting user
data conntrolled undder the SFP from outsidde the TOE:
T
The ICCR Loader
L dowwnloads onnly authenttic and inteegrity-proteected objeccts com-
ing fromm the Termminal Managgement Sysstem.
D
Downloadin ng is an ato
omic operattion. Eitherr it succeed
ds or the TSSF rollbackks to the
previouss state and all downlooaded data a is cleared or if the rrollback is not
n pos-
sible all ICCR TSF F secret datta are eraseed.
P
PIN encryp ption keys are
a only sttored in the Security Module off the device or en-
crypted..
[aassignmentt: additiona al importattion contro
ol rules]
Applicaation note:
PCIB B2: The functionality shhall not be influenced by logical anomalies
a su
such as (butt not lim-
iteed to) unexppected commmand sequeences, unkno own commaands, comm mands in a th he clear-
tex
ext PIN or other sensitivve data.
PCIB B4: If crypttographicallly authenticcates the firrmware and
d if the authhenticity is not con-
firrmed, the firmware upd date is rejeccted and deleted.
Updaate of softwware or dataa may be a cconsequencce of the download opeeration. Thee assign-
ment of addiitional importation coontrol ruless shall man nage the doownload op perations
whhich have ana update ass a consequuence.
9.1.1.5 POI_DAT
TA Packag
ge
FDP_A
ACC.1/POI__DATA Su
ubset Accesss Control
Dependdencies: FDPP_ACF.1 Security attriibute based access conttrol,

satisfiedd by FDP_A
ACF.1/POI_
_DATA
FDP_AACC.1.1/PO OI_DATA The T TSF shhall enforce the POI Managem ment and Payment
P
Transaction Data Access Control SFP oon
subjects: POOI and its Payment
P A
Application Logic
oobjects: Payyment Trannsaction Daata, POI Managemen
M nt Data, PO
OI_SK, Carrdholder
commun nication intterface, [asssignment: list of paym
ment appliccation internal da-
ta]
ooperations: send, receiive, access..
th
Page 100 Version 4.0
4 6 March,
M 2015
POI P
Protection Profile
{ XE "FDP__IFF.1/POI_
_DATA" }
FDP_A
ACF.1/POI__DATA Seccurity attriibute based
d access con
ntrol

S Acceess Control,
satisfiedd by FDP_A ACC.1/POI_ _DATA, FM MT_MSA.3 3 Static attriibute initiallisation not satisfied
but justiified: no maanagement functions
f arre required for POI_DA ATA.
FDP_AACF.1.1/PO OI_DATA The T TSF shhall enforcee the POI Managem ment and Payment
P
Transaction Data Access Control SFP bbased on th he followingg:
subjects: PO OI and its Payment
P A
Application Logic
oobjects: Payyment Tran nsaction Daata, POI Managemen
M nt Data, PO
OI_SK, Carrdholder
commun nication intterface, [asssignment: list of paymment appliccation internal da-
ta]
security attrribute of POI_SK: pu urpose and validity
security atttribute of Payment
P T
Transaction
n Data, PO OI Managem ment Data a: access
right of Payment Application
A n and autheenticity stattus
[aassignmentt: list of seccurity attrib
butes]
FDP_A ACF.1.2/PO OI_DATA The T TSF shaall enforce the followin ng rules to determine if
i an op-
eration among conttrolled subjects and conntrolled objjects is allow
wed:
E
EPCN2.1: The
T securitty of paym ment applica ation in the POI musst not be im mpacted
by any other appllication. Paayment app plication issolation shaall be ensuured: no
other ap
pplication shall
s have u
unauthorizzed access to t applicatiion data (PPayment
Transacction Data, POI Manaagement Da ata, POI_SK K).
E
EPCN2.2: The
T securitty of paym ment applica ation in the POI musst not be im mpacted
by any other appllication. Paayment ap pplication isolation shhall be ensured: it
shall not be possibble for anotther appliccation to in nterfere witth the execution of
the paymment application, by accessing internal
i daata (such ass state macchine or
internal variables).
E
EPCN2.3: Payment
P appplication iisolation shhall be ensured: it shhall not be possible
for anotther appliccation to d deceive thee Cardhold der duringg execution n of the
payment application, by acccessing Carrdholder co ommunicattion interfa ace (e.g.
display, beeper, prrinter) used
d by the pay yment appllication.
P
PCIB17: If the POI su upports mu ultiple appllications, itt must enfoorce the sepparation
betweenn applicatioons. It musst not be possible
p thaat one appplication in
nterferes
with or tampers with
w anotheer applicatiion or the OS O of the P POI includding, but
not limited to, mod difying datta objects belonging
b to
t another application n or the
OS.
FDP_A ACF.1.3/PO OI_DATA TheT TSF shhall explicitlly authorisee access off subjects to
o objects
based onn the follow
wing additio
onal rules:
P
POI Managgement Datta and Paym ment Transsaction Datta shall be accepted iff the da-
ta are auuthentic.
th
4 Page 101
POI P
Protection Profile
A Paymentt Applicatiion will bee allowed to t access POI
P Manaagement Data and
Paymennt Transacttion Data iff the Payment Application has aaccess rightts to the
data.
[aassignmentt: rules, baased on secu
urity attrib
butes, that explicitly aauthorise access
a of
subjectss to objects]].
FDP_A ACF.1.4/PO OI_DATA The T TSF shaall explicitly y deny acceess of subjeects to objeccts based
on the ffollowing addditional rulles:
P
POI Managgement Datta and Paym ment Transsaction Datta shall nott be accepteed if the
data aree not authen ntic.
T
The POI dooes not send d POI_SK iin cleartextt to any extternal IT enntity.
[aassignmentt: rules, ba ased on seccurity attriibutes, thatt explicitly deny information
flows].
Applicaation note:
onn security attributes theese parts shhall be filled
d with none.
FDP_IT
TT.1/POI_D
DATA Bassic internal transfer protection

o FDP_IFC
control satisfied byy FDP_ACCC.1/POI_DA ATA
FDP_IT TT.1.1 The TSF shall enforce thee [assignmeent: access control SF FP(s) and/oor infor-
mation flow contrrol SFP(s)] to prevent tthe [selectio on: disclosuure, modifiication, losss of use]
of user ddata when iti is transmitted betweeen physicallly-separatedd parts of the
he TOE.
This is rreplaced byy the followiing refinemeent:
FDP_IT TT.1.1/POII_DATA Th he TSF shhall enforcee the POI Managem ment and Payment
P
Transaction Dataa Access Co ontrol SFP P to preventt the modiffication of POI Mana agement
Data an nd Paymen nt Transacttion Data aand to prev vent the dissclosure of POI_SK when w one
of thesee data items is transmittted betweenn physicallyy-separated parts
p of thee TOE.
Applicaation note:
EPCN
CN1.2: Paym ment Transa action Dataa shall be handled
h witth authenticcity and inteegrity in
thhe POI (thiss includes prreventing mmodificationn of the tran
nsaction amoount in the TOE af-
teer it has beeen acknowleedged by enttry of the ca
archolder’s PIN).
EPCN
CN1.3: POI Managemeent Data muust be proteected again nst unauthorrized chang ge in the
PO OI.
EPCN
CN4: Protection of POI_ I_SK in a POOI componeent against disclosure.
{X XE "FDP_U UIT.1/POI_ _DATA" }
th
4 6 March,
M 2015
POI P
Protection Profile
FDP_U
UIT.1/POI__DATA Datta exchangee integrity
Dependdencies: FDPP_ACC.1 Subset

S accesss control orr FDP_IFC..1 Subset innformation flow
f
control, FTP_ITC.1 Inter-TSF
F Trusted Chhannel or FT TP_TRP.1 Trusted
T pathth
satisfiedd by FDP_A
ACC.1/POI__DATA, FT TP_ITC.1/P POI_DATA
FDP_U UIT.1.1 Thee TSF shall enforce thee [assignmeent: access control SF FP(s) and/o
or infor-
mation flow contrrol SFP(s)] to [selectioon: transmit, receive] user data inn a manner protect-
ed from
m [selection:: modification, deletioon, insertion, replay] errors.
e
FDP_U UIT.1.1/POII_DATA The T TSF shhall enforcee the POI Managem ment and Payment
P
Transaction Dataa Access Co ontrol SFP P to transm
mit and recceive POI M
Managemeent Data
and Payyment Transaction Data in a maanner proteccted from modification
m n errors.
FDP_U UIT.1.2/POII_DATA Th he TSF shhall be ablee to determ mine on recceipt of usser data,
whetherr modification has occcurred.
Applicaation note:
The rrefinementss FDP_UIT. T.1.1 and .1.22 replaces the originall FDP_UITT.1.1 above, thus the
orriginal elemment shall no ot be considdered by thee author of the
t ST.
EPCNCN1.3: POI Managemeent Data muust be provvided to the POI in an authentic way w and
must be proteected againsst unauthorrized changee.
The P POI shall protect
p in either
e case PPOI Manag gement Datta sent or re received by the POI
ovver externaal lines ag gainst modif ification byy cryptograaphic mechhanisms. Prrotection
aggainst modifification inccludes proteection of thee authenticitty of POI M
Managementt Data.
EPCNCN1.1: POI must have the t capacityy to protectt communications overr external co ommuni-
caation channnels, meaniing that P POI Applica ation Logicc must provvide crypto ographic
means: To protect all Payment
P Traansaction Data
D sent or received by the POII against
modification..
The P POI shall provide
p meaans to protecct Paymentt Transactio on Data sennt or receiveed by the
PO OI over external liness against m modification n by cryptog graphic meechanisms. Whether
thhe means arre used or no ot is contro lled by the payment
p ap
pplication ussing that meeans.
Exterrnal means ‘external to t the POI’.. Thereforee, this requirement adddresses com mmunica-
tioons with loccal devices (e.g. cash rregisters, puump controllers), comm munications with the
Accquirer(s) and
a communications w with the Terrminal Mana agement Syystem. The object
o of
evvaluation foor this requ uirement coonsists of the
t securityy functions that provid de those
crryptographiic means. TheTh security ffunctions should not enforce
e prottection of co
ommuni-
caations, but the cryptog graphic meaans must bee available,, would thee external entitye re-
quuires protecction.
th
4 Page 103
POI P
Protection Profile
FDP_U
UCT.1/POI__DATA Ba
asic data exxchange con
nfidentiality
Dependdencies: FTP P_ITC.1 Intter-TSF trussted channel, or FTP_T

TRP.1 Trustted path
satisfiedd by FTP_IT
TC.1/POI_DDATA
FDP_ACC.1 Subseet access co ontrol, or FDDP_IFC.1 Subset informmation flow
w control
satisfiedd by FDP_A
ACC.1/POI_ _DATA
FDP_U UCT.1.1: Thhe TSF shaall enforce tthe [assignment: acceess control SFP(s) an nd/or in-
formatiion flow coontrol SFP((s)] to [seleection: tran nsmit, receiive] user daata in a man nner pro-
tected fr
from unauthhorised discllosure.
FDP_U UCT.1.1/PO OI_DATA The T TSF shhall enforcee the POI Managem ment and Payment
P
Transaction Data Access Co ontrol SFP to transmiit and receiive POI_SK K and to bee able to
transmit and receeive Paymeent Transacction Data in a manneer protectedd from unau uthorised
disclosuure.
Applicaation note:
EPCN
CN1.1: POI must have the t capacityy to protectt communications overr external co ommuni-
caation channnels, meaniing that P POI Applica ation Logicc must provvide crypto ographic
means: To prrotect all tra ansaction ddata sent or received byy the POI aggainst disclo osure.
CN4: Protection of POI_
EPCN I_SK in a PO OI componeent against disclosure.
The P POI shall provide
p meaans to protecct Paymentt Transactio on Data sennt or receiveed by the
PO OI over extternal lines against dissclosure byy cryptograp phic mechaanisms. Wheether the
means are ussed or not iss controlledd by the paym ment appliccation usingg that meanss.
Exterrnal means ‘external to t the POI’.. Thereforee, this requirement adddresses com mmunica-
tioons with loccal devices (e.g. cash rregisters, pu
ump controllers), comm munications with the
accquirer(s) and
a communications w with the termminal mana ager. The oobject of evvaluation
foor this requiirement con nsists of thee security fu
unctions tha
at provide tthose crypto ographic
means. The security
s funcctions shouuld not enforrce protectiion of comm municationss, but the
crryptographiic means mu ust be availaable, wouldd the externaal entity reqquires proteection.
FDP_R
RIP.1/POI_D
DATA Sub
bset residuaal informattion protecttion
FDP_R RIP.1.1/POII_DATA Th he TSF shaall ensure th hat any prev vious inform
mation conttent of a
resourcee is made unnavailable upon
u the [seelection: alllocation of the
t resourcee to, dealloccation of
the resoource from] the following objects: [assignmen nt: list of ob
bjects]
Refinemment:
upon thhe deallocattion of the resource
r frrom the folllowing objeects: tempoorary cryptograph-
ic keys, [assignment: sensitive objectss with residual inform mation, temmporary payment
p
transacction data].
Dealloccation may occur
o upon completionn of the transaction or iff the PED hhas timed-ou ut wait-
ing fromm the Cardhholder or meerchant.
th
4 6 March,
M 2015
POI P
Protection Profile
Applicaation note:
Conttribution to EPCN2.1 to o EPCN2.33.
This SFR requirres that sensitive inform mation shalll not be present any loonger or ussed more
offten than sttrictly necesssary. Buffeers shall bee cleared im
mmediately aafter exporrting any
PIIN, upon payment transaction is completed d and when MiddleTSF F componen nts have
timme-out waitting for a reesponse.
FTP_IT
TC.1/POI_D
DATA Inteer-TSF tru sted chann
nel
FTP_IT TC.1.1/POII_DATA Th he TSF shalll provide a communication channnel between itself
and anoother trustedd IT productt that is logiically distin
nct from oth
her communnication channels
and provvides assureed identification of its end points anda protectiion of the chhannel dataa from
modificcation or dissclosure.
FTP_ITTC.1.2/POII_DATA Th he TSF shaall permit [selection: the

t TSF, aanother tru usted IT
product] to initiatee communiccation via thhe trusted ch
hannel.
Refinem
ment:
The TSFF shall perm
mit Acquireer System tto initiate co ommunication via the ttrusted chan
nnel.
FTP_IT TC.1.3/POII_DATA Th he TSF shaall initiate communication via the trusted chaannel for
transmitting and receiving Payment
P Trransaction Data and POI_SK, [[assignmen nt: list of
functionns for whicch a trusted d channel iss required]].
Applicaation note:
The cchannel is used
u to prottect the conffidentiality and authenticity of datta.
Conttribution to EPCN1.1 and a EPCN44.
EPCN
CN1.1: The POI
P shall prrovide meanns for autheentication off its uniquee identifier by b an ex-
teernal IT entiity that it co
ommunicatees with.
For uunique idenntification, uniqueness
u is only requ
uired in a given
g contexxt: the exterrnal enti-
tyy should be able
a to distiinguish onee POI from another.
a Ass an examplele, use of un
nique key
peer POI guarrantees thatt POI can b e uniquely authenticate
a ed.
9.1.1.6 CoreTSF Package
FPT_TST.1/CoreT
TSF TSF teesting
FPT_TST.1.1/CorreTSF The TSF shall ru run a suite of

o self tests at
a the condditions
sttart-up
aat least oncee per day
to demoonstrate the correct opeeration of th
he CoreTSF F PED (CO ORE_SW annd CORE_ _HW).
th
4 Page 105
POI P
Protection Profile
FPT_TST.1.2/CorreTSF The TSF shall pprovide auth horised users with the capability to
t verify
the integgrity of [sellection: [assignment: p
parts of TS
SF data], TSF data].
FPT_TST.1.3/CorreTSF The TSF shall pprovide auth horised users with the capability to t verify
the integgrity of storred TSF exxecutable coode.
Applicaation note:
"TSF F executablee code" stannds for CoreeTSF softwa are within the
t PED.
PCIB B1: The PEDED performss a self-test,, which inclludes integrrity and autthenticity teests upon
sttart-up and at least oncce per day tto check whhether the PED
P is in a compromissed state.
Inn the event of
o a failure, the PED annd its functionality faill in a securee manner. The
T PED
must reinitiallize memoryy at least evvery 24 hourrs.
If no other partss of TSF exiist the assiggnments shall be filled with
w none.
FPT_FL
LS.1/CoreT
TSF Failurre with presservation of
o secure sta
ate
FPT_FL LS.1.1/CorreTSF The TSF shall ppreserve a secure statee when the following types of
failures occur:
faailure of CoreTSF sellf-test
loogical anommalies of CoreTSF
[aassignmentt: list of typpes of failurres in CoreeTSF].
Applicaation note:
The "secure staate" does no ot provide aaccess to an ny PIN valuue, PIN enccryption keyy or any
otther CoreTSSF secret da ata.
sttart-up and at least oncce per day tto check wh hether the PED
Inn the event of
T PED
PCIB B2: The PEDED’s functio onality shalll not be inflluenced by logical
l anoomalies such
h as (but
noot limited too) unexpected commannd sequencces, unknow wn commandds, comman nds in a
wrrong devicee mode and d supplying wrong para ameters or data whichh could resu ult in the
PE ED outputtiing the cleaar-text PIN oor other sennsitive data.
If no list of addiitional failure types exiist the assig
gnment shalll be filled w
with none.
FDP_A
ACC.1/CoreeTSFLoadeer Subset aaccess contrrol
ustified:
_ITC.1/CorreTSFLoadeer
FDP_AACC.1.1/CooreTSFLoader The TS
SF shall en
nforce the Core
C Loadeer Access Control
SFP on
th
4 6 March,
M 2015
POI P
Protection Profile
subject: Core Loader
oobjects: CO ORE_SW, [assignmen nt: list of data,
d in pa
articular crryptograph
hic keys,
controlleed under th his policy]
d
Applicaation note:
The "cryptograpphic keys" stand for P PIN encrypttion keys (ee.g. ENC_P PIN_SK) orr for any
otther key. Thhe operation ns are any mmanagemen nt operation on CoreTSSF softwaree and da-
taa.
ne”.
FDP_IT
TC.1/CoreT
TSFLoaderr Import off user data without seecurity attrributes
Dependdencies:
by FDP P_ACC.1/CooreTSFLoad der
FMT_M MSA.3 Statiic attribute initialisatioon not satisffied but justtified: theree are no seccurity at-
T Management
FDP_ITTC.1.1/CorreTSFLoad der The TSF F shall enfforce the Core

C Loadeer Access Control
SFP whhen importinng user dataa, controlledd under the SFP, from outside
o of thhe TOE.
FDP_IT TC.1.2/CorreTSFLoad der The TSF F shall igno

ore any secu
urity attribuutes associaated with
the userr data when imported frrom outsidee the TOE.
FDP_IT TC.1.3/CorreTSFLoad der The TSF F shall enfforce the following rulles when im mporting
user datta controlledd under the SFP from ooutside the TOE:
T
TThe Core Loader
L dow
wnloads on nly authentiic and inteegrity-proteected objeccts com-
ing fromm the Term minal Managgement Sysstem.
DDownloadin ng is an ato
omic operattion. Eitherr it succeed
ds or the TSSF rollback ks to the
n pos-
sible all CoreTSF secret
s data are erasedd.
PPIN encryption keys are a only stoored in the Security Module
M of P
PED or encrrypted.
[aassignmentt: additiona al importattion controol rules]
Applicaation note:
PCIB B2: The PEDED’s functioonality shalll not be inflluenced by logical
l anoomalies such
h as (but
wrrong devicee mode and d supplying wrong para ameters or data whichh could resuult in the
PE ED outputtiing the clea
ar-text PIN oor other sennsitive data.
PCIB B4: If the PED
PE allows updates of ffirmware, the t device cryptographhically autheenticates
thhe firmwaree and if the authenticitty is not coonfirmed, th he firmwaree update is rejected
annd deleted.
th
4 Page 107
POI P
Protection Profile
Updaate of softw
ware or data
a may be a cconsequencce of the download opeeration. Thee assign-
ment of addiitional importation coontrol ruless shall mannage the doownload op perations
whhich have an
a update ass a consequuence.
9.1.1.7 PEDMidd
dleTSF Pacckage
FPT_TST.1/PEDM
MiddleTSF
F TSF testin
ng
FPT_TST.1.1/PED DMiddleTS SF The TSF F shall run a suite of self tests at thhe conditio
ons
sttart-up
aat least oncee per day
to demoonstrate the correct opeeration of th
he PEDMid ddleTSF.
FPT_TST.1.2/PED DMiddleTS SF The TSF F shall prov

vide authorissed users w
with the capaability to
verify thhe integrity of [selectio
on: [assignm
ment: parts of TSF da ata], TSF ddata].
FPT_TST.1.3/PED DMiddleTS SF The TSF F shall prov

vide authorissed users w with the capaability to
verify thhe integrity of stored TSF
T executtable code.
Applicaation note:
"TSF F executablle code" sta ands for PE EDMiddleT TSF softwarre within thhe PED and d the IC
Ca
Card Readerr.
sttart-up and at least oncce per day tto check whhether the PED
Inn the event of
T PED
If no other partss of TSF exiist the assiggnments shall be filled with
w none.
FPT_FL
LS.1/PEDM
MiddleTSF
F Failure wiith preserv
vation of secure state
FPT_FL LS.1.1/PED DMiddleTS SF The TSF F shall preserve a seccure state w

when the foollowing
types off failures occcur:
faailure of PEEDMiddleT TSF self-teest
loogical anom malies of PE
EDMiddleT TSF
[aassignmentt: list of typ
pes of failurres in PED
DMiddleTSF F].
Applicaation note:
The "secure staate" does no ot provide aaccess to an
ny PIN valuue, PIN enccryption keyy or any
otther PEDM MiddleTSF seecret data.
th
4 6 March,
M 2015
POI P
Protection Profile
sttart-up and at least oncce per day tto check wh hether the PED
Inn the event of
o a failure, the PED annd its functionality faill in a securee manner. TheT PED
PCIB B2: The PEDED’s functio onality shalll not be inflluenced by logical
l anoomalies such
h as (but
wrrong devicee mode and d supplying wrong para ameters or data whichh could resu ult in the
PE ED outputtiing the cleaar-text PIN oor other sen nsitive data.
If no list of typess of failuress exist the asssignment shall
s be filleed with nonee.
FDP_A
ACC.1/PED
DMiddleTSF
FLoader Su
ubset accesss control
ustified:
_ITC.1./PED
DMiddleTSSFLoader
FDP_A ACC.1.1/PE EDMiddleT TSFLoader The TSF shall enforce the PED D Middle Loader
Access Control SF FP on
subject: PED Middle LoaderL
oobjects: PED_MIDDL LE_SW, [asssignment: list of data a, in particcular cryptograph-
ic keys, controlled under this policy]
d
Applicaation note:
The "cryptograpphic keys" stand for P PIN encryption keys (P PLAIN_PIN N_SK) or an ny other
keey. The opeerations aree any manaagement operation on PEDMiddlleTSF softw ware and
daata.
ne”.
{X XE "FDP_IITC.1/Plain nPinMiddleT TSFLoader"" }
FDP_IT
TC.1/PEDM
MiddleTSF
FLoader Im
mport of useer data without securi
rity attributtes
Dependdencies:
by FDP P_ACC.1/PE EDMiddleT TSFLoader
T Management
FDP_IT TC.1.1/PEDDMiddleTSSFLoader T The TSF shhall enforce the PED M Middle Loa ader Ac-
cess Coontrol SFP when impo
orting user data, contrrolled underr the SFP, ffrom outsid
de of the
TOE.
FDP_IT TC.1.2/PED DMiddleTS SFLoader TThe TSF sh hall ignore any

a securityy attributes associat-
a
ed with the user daata when imp
ported from
m outside the TOE.
th
4 Page 109
POI P
Protection Profile
FDP_IT TC.1.3/PED DMiddleTS SFLoader T The TSF sh hall enforce the followwing rules when
w im-
porting user data coontrolled un
nder the SFP P from outsside the TOE E:
T
The PED Middle
M Loadder downlooads only au uthentic annd integrityy-protected
d objects
coming from the Terminal
T M
Management System.
D
Downloadin ng is an ato
omic operattion. Eitherr it succeed ds or the TSSF rollback
ks to the
n pos-
sible all PEDMiddlleTSF secrret data aree erased.
[aassignmentt: additiona al importattion contro ol rules]
Applicaation note:
PCIB B2: The PEDED’s functioonality shalll not be inflluenced by logical
l anoomalies suchh as (but
wrrong devicee mode and d supplying wrong para ameters or data whichh could resuult in the
PE ED outputtiing the clea
ar-text PIN oor other sennsitive data.
PCIB B4: If the PED
PE allows updates of ffirmware, the t device cryptographhically autheenticates
thhe firmwaree and if the authenticitty is not coonfirmed, th he firmwaree update is rejected
annd deleted.
Updaate of softwware or dataa may be a cconsequencce of the download opeeration. Thee assign-
whhich have ana update ass a consequuence.
9.1.1.8 MiddleTS
SF Packagee
FDP_A
ACC.1/AppllicationLoa
ader Subseet access con
ntrol
ustified:
_ITC.1./ApplicationLooader
FDP_A ACC.1.1/Ap pplicationLoader The TSF shall enforce e the Payment

P A
Applicationn Loader
Access Control SF FP on
subject: Payyment App plication Looader
oobjects: PAAYMENT_A APP, [assiggnment: lisst of data, in particuular crypto ographic
keys, conntrolled un nder this poolicy]
d
Applicaation note:
The "cryptograpphic keys" stand for PO OI encryptio on keys (POOI_SK).
If no list of dataa exist the asssignment sshall be filleed with “non ne”.
PCIB B4.1: The firmware
f must supportt the authen ntication off applicatioons loaded onto the
teerminal consistent with h PCIB4. Iff the device allows sofftware appliication and d/or con-
figguration uppdates, the device crypptographica ally authentticates updaates consisttent with
PC CIB4.
th
4 6 March,
M 2015
POI P
Protection Profile
FDP_IT
TC.1/AppliicationLoad
der importt of user da
ata without security atttributes
Dependdencies:
by FDP P_ACC.1/AppplicationLoader
T Management
FDP_ITTC.1.1/AppplicationLo
oader The TTSF shall en nforce the Payment
P A
Application Loader
Access Control SF
FP when im ntrolled undeer the SFP, from outsid
mporting useer data, con de of the
TOE.
FDP_IT TC.1.2/App plicationLo

oader The TSF shall ignore any security aattributes asssociated
with thee user data when
w imporrted from ouutside the TOE.
T
FDP_IT TC.1.3/App plicationLo oader The T TSF shall en nforce the following
fo ruules when im
mporting
T
T
The Paymeent Appliccation Loaader down nloads onlly authenttic and in ntegrity-
protecteed objects coming
c fromm the Term minal Mana agement Syystem.
P
Payment ap pplication downloadin
d ng is an atoomic operattion. Eitherr it succeed ds or the
TSF rolllbacks to the previoous state and a all do
ownloaded code and data is
cleared or if the ro
ollback is noot possible all MiddleTSF secrett data are erased.
e
Applicaation note:
In the fo
following EPPC rule, thee phrase “P POI softwarre” is interp preted as paayment app plication
softwarre
EPCN
CN3.1: POI software
s muust be proviided to the POI
P in an authentic
a waay and mustt be pro-
teected againsst unauthoriized changee.
EPCN
CN3.2: If thhe POI imp plements sofftware upd dates, a PAL L security componentt crypto-
grraphically authenticate
a es the softw
ware integritty and if thee authenticiity is not confirmed,
thhe software update is reejected or aall secret cryyptographicc keys are errased.
Updaate of softwware or data a may be a cconsequencce of the download opeeration. Thee assign-
whhich have an
PCIB B4.1: The firmware
f must supportt the authen ntication off applicatioons loaded onto the
teerminal consistent with h PCIB4. Iff the device allows sofftware appliication and d/or con-
figguration uppdates, the device crypptographica ally authentticates updaates consisttent with
PC CIB4.
th
4 Page 111
POI P
Protection Profile
FDP_A
ACC.1/Midd
dleTSFLoa
ader Subsett access con
ntrol
ustified:
_ITC.1/Mid
ddleTSFLoaader.
FDP_A ACC.1.1/MiiddleTSFLo oader The TSF shall enforce

e the Middle Looader Acceess Con-
trol SFP P on
subject: Middle Loadeer
oobjects: POOI_SW, [asssignment: llist of data, in particu ular cryptoographic keeys, con-
trolled under
u this policy]
p
d
Applicaation note:
The "cryptograpphic keys" stands for POOI encryptio on keys (POOI_SK). Thee operationss are any
management operation on o MiddleT TSF softwaree and data.
If no list of dataa exist the asssignment sshall be filleed with “nonne”.
{XXE "FDP_IITC.1/Midd dleTSFLoadder" }
FDP_IT
TC.1/Midd
dleTSFLoad
der Importt of user da
ata without security atttributes
Dependdencies:
by FDP P_ACC.1/MMiddleTSFLo oader
T Management
FDP_IT TC.1.1/Mid
ddleTSFLoader The T TSF shall enforce
e the Middle Looader Acceess Con-
trol SFP
P when impporting userr data, contrrolled underr the SFP, frrom outsidee of the TOE
E.
FDP_IT TC.1.2/Mid ddleTSFLoader The T TSF shall ignore

i any security at
attributes asssociated
with thee user data when
w imporrted from ouutside the TOE.
T
FDP_IT TC.1.3/Mid ddleTSFLoader The T TSF shall ennforce the fo

ollowing ruules when immporting
T
T
The Middlee Loader downloads oonly authen ntic and in
ntegrity-prootected objjects the
Terminaal Managem ment Syste m.
D
Downloadin ng is an atoomic operattion. Eitherr it succeedds or the TSSF rollback ks to the
n pos-
sible all MiddleTSF F secret daata are erassed.
Applicaation note:
EPCN
CN3.1: POI software
s muust be proviided to the POI
P in an authentic
a waay and mustt be pro-
teected againsst unauthoriized changee.
th
4 6 March,
M 2015
POI P
Protection Profile
EPCN
CN3.2: If thhe POI imp plements sofftware upd dates, a PAL L security componentt crypto-
grraphically authenticate
a es the softw
ware integritty and if thee authenticiity is not confirmed,
thhe software update is reejected or aall secret cryyptographicc keys are errased.
Updaate of softw
ware or dataa may be a cconsequencce of the download opeeration. Thee assign-
whhich have an
FPT_FL
LS.1/Midd
dleTSF Faillure with prreservation
n of secure state
FPT_FL LS.1.1/Mid ddleTSF Th he TSF shalll preserve a secure state when thee following types of
failures occur:
loogical anommalies of MiddleTSF
M
[aassignmentt: list of typpes of failurres in Midd dleTSF].
Applicaation note:
The "secure state" does not provide a ccess to anyy encryption key or anny other MiddleTSF
seecret data.
EPCNCN7: The fuunctionality shall not bbe influenceed by logica al anomaliees such as (but not
limmited to) unnexpected co ommand seequences, un nknown com mmands, com mmands in a wrong
deevice mode and supplying wrong pparameters or data wh hich could rresult in a breach
b of
thhe security requirement
r ts.
If no list of typess of failuress exist the asssignment shall
s be filleed with nonee.
9.1.1.9 PED Prom

mpt Contro
ol Packagee
FDP_A
ACC.1/PED
DPromptCo
ontrol Subsset access co
ontrol
Dependdencies: FDP
P_ACF.1 saatisfied by F
FDP_ACF.1
1/PEDProm
mptControl.
FDP_A ACC.1.1/PE EDPromptC Control Thee TSF shalll enforce th

he PED Proompt Conttrol SFP
on
subjects: POOI compon nents
oobject: PE ED displa ay, PED keypad, prompts, PIN, PE ED_MIDDLE_SK,
PED_M MIDDLE_PK K
ooperations: entry, disp
play.
Applicaation note:
Conttribution to A8. See app
plication noote of FDP_
_ACF.1/PED DPromptCoontrol.
th
4 Page 113
POI P
Protection Profile
FDP_A
ACF.1/PEDPromptControl Securrity attribu
ute based access contrrol
Dependdencies:
FDP_ACC.1 Subseet access co ontrol satisfiied by FDP_ _ACC.1/PE EDPromptC Control
tributes to be mannaged for PE ED Displayy. Terminall Management System m decides to o modify
promptss for PED Display
D (as part
p of the ccorrespondeent TSF softtware) or noot.
FDP_A ACF.1.1/PEDPromptC Control Thee TSF shalll enforce th

he PED Proompt Conttrol SFP
to objeccts based onn the followiing:
subjects: PO OI compon nents
sttatus of PE
ED display usage: PIN N display, non-PIN
n dissplay
sttatus of PE
ED Keypad d usage: PIN N entry, noon-PIN entrry
[aassignmentt: list of seccurity attrib
butes]
FDP_A ACF.1.2/PEDPromptC Control Thee TSF shall enforce the followingg rules to deetermine
if an opperation amoong controllled subjectss and contro
olled objectts is alloweed: If the PE
ED key-
pad can n be used to
t enter noon-PIN datta, then pro ompts dem manding forr PIN entrry at the
PED diisplay shalll never leadd to a PIN d disclosure (e.g.
( be pro
ocessing thee entered PINP data
in clearr in unprottected areaas). The au uthenticity and propeer use of prrompts and d use of
the proompts shalll be ensureed and mo dification of o the prom mpts or im mproper usse of the
promptts shall be prevented.
p
FDP_A ACF.1.3/PEDPromptC Control Thee TSF shall explicitly authorise acccess of sub
bjects to
objects based on thhe following
g additional rules: nonee.
FDP_A ACF.1.4/PEDPromptC Control Thee TSF shalll explicitly deny accesss of subjectts to ob-
jects baased on the following
f rule:
r unaut horised mo odification access to thhe text of prompts
p
shall alw ways be prrevented.
Applicaation note:
The SFR R can be imp
mplemented in different ways which h are descriibed in the ffollowing.
If the P
POI device has
h a keypa ad that can bbe used to enter non-P PIN data, thhe device must meet
at least one of the following:
f PCIA7,
P PCIIB16, or EPPC-CHIP-ON NLYB16.
PCIA A7 applies to any com mponents orr paths containing plaintext displlay signals between
thhe cryptograaphic processor and dis
isplay unit.
PCIB B16 appliess to PEDs that
t allow ffor updates of promptss or use cryyptography to com-
municate with a display,, whether peerformed byy the vendorr or the acqquirer.
EPCC-CHIP-ONL NLYB16 onlyy applies forr the POI-CCHIP-ONLY Y configurattion.
Prommpts can bee under con ntrol of thee security module.

m Thee security m
module controls the
diisplay. Thiss leads to PCIB16:
P Alll prompts fo or non-PIN data entry are under the con-
ryptographicc unit of thee device. Iff the promptts are storedd inside thee crypto-
trrol of the cry
grraphic unit, they canno ot feasibly be altered without cau using the errasure of th he unit’s
crryptographiic keys. If the
t promptss are stored d outside th
he cryptogrraphic unit, crypto-
grraphic mechanisms mu ust exist too ensure thee authenticity and thee proper usse of the
th
4 6 March,
M 2015
POI P
Protection Profile
prrompts and that modifi fication of thhe prompts or impropeer use of thhe prompts are pre-
veented.
Acceess control to
t prompts may be stoored in a lessser secure region thann the securrity mod-
ulle. This impplementationn requires tthat the cryp
yptographic unit controols the displlay. This
leeads to PCIAA7: The una authorized aalteration of
o prompts forf non-PINN data entryy into the
PIIN entry keyy pad such that PINs aare comprom mised, i.e., by
b promptinng for the PIN
P entry
whhen the outpput is not en
ncrypted, caannot occurr.
Apprropriate reqquirement for
f POI-CH HIP-ONLY is necessarry. This leaads to EPC C-CHIP-
O
ONLYB16: Cryptograph
C hic mechannisms must exist to en nsure the aauthenticity and the
prroper use off the promp pts and thatt modificatiion of the prompts or iimproper usse of the
prrompts are prevented.
p
9.1.1.100 Cryptogrraphy Pack

kage
The SFRRs of the Cryptography

C y Package sshall be iterrated as neeeded by the ST author. The de-
pendenccies shall bee adapted co
onsequentlyy.
FCS_R
RND.1 Geneeration of random
r nu mbers
FCS_R RND.1.1 Thee TSF shalll provide a mechanism m to generaate random numbers th hat meet
[RNGP PCI].
Applicaation note:
PCIB B9: If randdom numberrs are geneerated by th
he PED in connectionn with securrity over
seensitive dataa, the rando
om number generator has been asssessed to eensure it is generat-
g
inng numbers sufficiently unpredictaable.
FCS_C
COP.1 Cryp
ptographic operation
Dependdencies: FDP P_ITC.1 Immport of userr data witho out security attributes, oor
FDP_ITTC.2 Importt of user datta with secuurity attributtes, or
FCS_CK KM.1 Cryptographic keyk generatiion satisfied d by FDP_IT TC.2
FCS_CK KM.4 Crypptographic keyk destrucction not saatisfied but justified. N No specificc crypto-
graphic key destrucction metho
od is enforceed. Keys aree destroyed by erasing them.
FCS_C COP.1.1 Thee TSF shall perform PIIN encipheerment/decipherment in accordan nce with
a speciffied cryptoographic alg
gorithm [asssignment: cryptogra aphic algorrithm] and
d crypto-
graphic key sizes [aassignmentt: cryptogrraphic key sizes]
s that meet
m the folllowing: ISOO 9564.
Applicaation note:
The author of thet Securityy Target shhall iterate this SFR for
f each TS
TSF part (CCoreTSF,
PE EDMiddleT TSF, MiddleeTSF, ICCRR TSF) if neccessary.
Conttribution to PCIB10, EP PCPlusB100.a, PCIB12 2, PCID4.1, PCID4.2 aand PCID4.4 4.
th
4 Page 115
POI P
Protection Profile
FDP_IT
TC.2 Import of user data
d with seecurity attrributes

o
FDP_IFFC.1 Subsett information flow conttrol satisfied d (accordingg to the dataa concernedd) by
FDP_IFFC.1/ENC_P PIN or FDP P_IFC.1/PLA AIN_PIN or o FDP_IFC C.1/ICCardR Reader or
FDP_ACC.1/POI__DATA becaause the rellevant inform mation flow
w or access ccontrol is reelated to
the Crypptographic Key
K Importt
FTP_ITTC.1 Inter-TTSF trusted channel, or
FTP_TR RP.1 Trusteed path satissfied by FTPP_ITC.1/Crrypto
FPT_TD DC.1 Inter-TTSF basic TSF
T data coonsistency satisfied by FPT_TDC.1
F 1
FDP_IT TC.2.1 Thee TSF shall enforce thee [assignmeent: access control SF
FP(s) and/oor infor-
mation flow contrrol SFP(s)] when impoorting user data, contro olled under the SFP, frrom out-
side of tthe TOE.
FDP_IT
TC.2.2 Thee TSF shall use the secuurity attribu
utes associaated with the
he imported user da-
ta.
FDP_IT TC.2.3 Thee TSF shall ensure thatt the protocol used provides for thhe unambig
guous as-
sociatioon between the
t security
y attributes aand the userr data receiv
ved.
FDP_IT TC.2.4 The TSF shall ensure

e that interpretation of the seecurity attribbutes of thee import-
ed user data is as inntended by the
t source oof the user data.
d
FDP_IT TC.2.5 Thee TSF shall enforce thee following rules when importing uuser data co ontrolled
under thhe SFP fromm outside th
he TOE: ISO O 11568 an nd/or ANSII X9.24, suppporting th he ANSI
TR-31 key derivaation methodology orr an equiva alent methodology foor maintain ning the
TDEA K Key Bundlle.
Applicaation note:
Notee that this SF
FR is speciffically meannt for TDES S-keys and their handliing. So "Usser data"
inn the SFR is to read as "TDES-keysys".
The aauthor of thhe Security Target sha ll iterate th
his SFR for each TSF ppart (CoreT TSFKeys,
C
CoreTSF, PEDMiddleT
P TSF, MiddlleTSF, ICC CR TSF) and a assignn the relatted SFP
(EENC_PIN Innformation Flow Contrrol SFP, PL LAIN_PIN Information
I Flow Conttrol SFP,
PE ED Promptt Control SF FP, IC Carrd Reader In nformation Flow Contr trol SFP, POOI Man-
aggement andd Payment Transaction
T n Data Information Flo ow Controll SFP), if neecessary
(i..e. if TDES keys are ha
andled).
Conttribution to PCIB11, EP PCN6.
th
4 6 March,
M 2015
POI P
Protection Profile
FTP_IT
TC.1/Cryptto Inter-TS
SF trusted cchannel
FTP_IT TC.1.1/Cryypto The TSF shall prrovide a co ommunicatio on channel between ittself and
another trusted IT product thaat is logicaally distinct from otherr communiccation channels and
provides assured iddentification
n of its end points and protection of
o the channnel data from
m modi-
ficationn or disclosuure.
FTP_IT TC.1.2/Cryypto The TS SF shall perrmit [selecttion: the TS

SF, anotherr trusted IT prod-
uct] to iinitiate com
mmunication
n via the truusted channeel.
FTP_IT TC.1.3/Cryypto The TS SF shall iniitiate comm munication via

v the trustted channell for im-
portingg cryptograaphic keys, [assignmen nt: list of functions
f fo
or which a trusted ch hannel is
requireed].
Applicaation note:
If thee author of the n list of funnctions the assignmentt shall be fillled with none.
t ST has no
The author of the t Securityy Target shhall iterate this SFR forf each TS TSF part (C CoreTSF,
PEEDMiddleT TSF, MiddleeTSF. ICCR R TSF) if neccessary.
FPT_TDC.1 Interr-TSF basicc TSF data consistenccy
FPT_TDC.1.1 Thee TSF shalll provide thhe capability y to consisttently interppret crypto
ographic
keys, [aassignment: list of TSF
F data typees] when sh
hared between the TSF and anotheer trusted
IT produuct.
FPT_TDC.1.2 The TSF shalll use ISO 11568 and d/or ANSI X9.24, suppporting th he ANSI
TR-31 key derivaation methodology orr an equiva alent methodology foor maintain ning the
TDEA Key Bund dle, and [asssignment: list of intterpretation n rules to be applied d by the
TSF] wwhen interpreting the TS SF data from
m another trrusted IT prroduct.
Applicaation note:
If thee author of the ST has no list of innterpretation rules the assignmentt shall be fillled with
noone.
In a distributedd environment, a TOE E may need d to exchange TSF ddata (e.g. th he SFP-
atttributes asssociated wiith cryptoggraphic keyss) with ano other trusteed IT produ uct, This
faamily definees the requirrements for sharing an nd consistent interpretaation of thesse attrib-
uttes betweenn the TSF of the TOE and a diffe ferent trusteed IT produuct. If no suuch data
typ
ypes and rulles exist the ST author sshall fill thee assignmennt with nonee.
th
4 Page 117
POI P
Protection Profile
9.1.1.111 Physical Protection
P Package
FPT_PH
HP.3/CoreTSF Resisttance to ph
hysical attacck
FPT_PH HP.3.1/CorreTSF The TSF shall rresist the ph hysical tam

mpering sceenarios
P
PCIA1: Repplacement of o the frontt and rear casing,
c that shall be coonsidered ass part of
any attacck scenario.
P
PCIA3: Opeerational orr environmeental conditiions that aree not withinn the speciffied PED
operatingg range (e.g temperatuure or operrating voltaage outside the state operating
o
range).
P
PCIA6: Pennetration of the PED to disclose the PIN encry yption keys..
[aassignmentt: additiona al physical tampering g scenarios]]
to the p physical booundary of the CoreT TSF by resp ponding auttomatically such that th he SFRs
are alwaays enforced.
Refinem ment: The auutomatic ressponse shalll ensure at least
l the following behhaviour:
PCIA A1: The PE ED uses tammper-detectioon and respponse mechaanisms thatt cause it to become
immmediately inoperable and result iin the autom matic and immmediate errasure of an ny sensi-
tivve data thatt may be stored in the PED, such h that it becomes infeaasible to reccover the
seensitive dataa.
PCIA A3: The PE ED makes in naccessible any PIN value,
v secrett or private keys or oth her PED
seecret informmation when n operationnal or envirronmental conditions
c ooccurs thatt are not
w
within the sppecified PED D operatingg range (e.g. temperaturre or operatting voltagee outside
thhe state operrating rangee).
Applicaation note:
If thee author of the
t ST has no n additionaal physical tampering scenarios
s fifill it with no
one.
The CoreTSF shhall contain n at least thhe PIN keyp
pad and the PIN encrypption modu ule of the
PE ED.
Wherre the attacck scenario o consideredd requires the installa ation of a bbug (for co ollecting,
sttoring, proccessing, and d/or transmmitting PIN or key datta) then thiss installatio on is in-
clluded in the attack poteential calcullation.
This requiremeent is not applicablee in the POI-CHIP-OP ONLY conffiguration. Instead
FP PT_PHP.3//CHIP-ONL LY holds forr the POI-CCHIP-ONLY Y configurattion.
FPT_EMSEC.1/C
CoreTSF TO
OE Emanaation
FPT_EMSEC.1.1//CoreTSF The TOE sshall not em mit measurable signalls including g power
fluctuattions (PCIA
A6) in excess of none eenabling acccess to PIN
N encryptioon keys and none.
th
4 6 March,
M 2015
POI P
Protection Profile
FPT_EMSEC.1.2//CoreTSF The TSF shhall ensure all users are unable too use the fo ollowing
interface emanatioons (includ ding powerr fluctuatio ons) (PCIA A6) to gain access to PIN
P en-
cryption keys and none.
Applicaation note:
Suppports PCIA66. Recall that CoreTSF F shall conttain at leastt the PED kkeypad and the PIN
enncryption module
m (PEDD Security MModule).
This requiremeent is not applicablee in the POI-CHIP-O
P ONLY conffiguration. Instead
FPPT_EMSEC C.1/CHIP-O ONLY holdss for the PO OI-CHIP-ON NLY configguration. Thhis holds
beecause of thhe differencce risk anallysis where POI-CHIP P-ONLY only ly supports IC card
baased transcaations.
FPT_PH
HP.3/ICCaardReader Resistancee to physica
al attack
FPT_PH HP.3.1/ICC CardReadeer The TSF shall resist the physical tamperinng scenario os
P
PCID1: Pennetration off the IC Caard Reader to make any a additionns, substituutions or
modificaations to eitther the IC Card Readeer’s hardwaare or softw
ware, in ordeer to de-
termine oro modify any
a sensitivee data.
to the pphysical bou undary of the
t IC Carrd Reader by b respondiing automattically such
h that the
SFRs arre always ennforced.
Applicaation note:
If thee author of the ST has no n additionnal physical tampering scenarios th
the assignment shall
bee filled withh ”no additioonal tamperr scenario”
”.
Apply ly to the PED D componeents that bellong to the ICCR
I TSF.
This requiremennt is not app plicable in tthe POI-CHHIP-ONLY configuratio
c on.
FPT_PH
HP.3/MSR
R Resistancee to physicaal attack
FPT_PH HP.3.1/MS SR The TSF F shall resiist addition

ns, substitu
utions, or mmodificatio ons that
would allow deteermination or modifiication of Magnetic Stripe dataa to the Magnetic M
Stripe rread head and a associa ated hardw ware and so oftware by respondingg automaticaally such
that the SFRs are always
a enforrced.
Applicaation note:
Conttribution to PCIA9. "Reesponding aautomaticallly" includes the situatiion where the t phys-
iccal or logiccal TOE deesign simplyy prevents the changee from takinng place. The T TOE
shhould thereffore either prevent
p thee attempted changes orr respond inn a way tha at leaves
thhe TOE unaable to carrry out paym ment transa
actions or request PIN Ns. Any au uthorised
chhanges to TOE
T softwarre are assummed to be ap
pproved, annd hence noot to violate the pro-
th
4 Page 119
POI P
Protection Profile
teection of thee Magnetic Stripe dataa. The TOE E is preventted from carrrying out payment
p
trransactions as a resultt of any chhanges, but may be ab ble to carryy out admin
nistrator
fuunctions, subbject to the usual requiirements forr administra
ator authenntication.
This requiremennt is not app plicable in tthe POI-CH
HIP-ONLY configuratio
c on.
FPT_PH
HP.3/CHIP
P-ONLY Resistance
R t o physical attack
FPT_PH HP.3.1/CH HIP-ONLY The TSF shhall resist th he physicall tamperingg scenarios
P
PCIA3: Opeerational orr environmeental conditiions that aree not withinn the speciffied PED
operatingg range (e.g temperatuure or operrating voltaage outside the state operating
o
range).
E
EPC-CHIP--ONLYA6:: Penetratioon of the PED P to discclose POI_PPayDatSK and a PIN
encryptioon keys.
physical booundary of the CoreT
to the p TSF by respponding auttomatically such that th he SFRs
are alwaays enforced.
Applicaation note:
This requiremennt is only appplicable forr the POI_C
CHIP-ONLY Y configuraation.
Wherre the attacck scenario o consideredd requires the installaation of a bbug (for coollecting,
sttoring, proccessing, andd/or transmmitting PIN or key datta) then thiss installatioon is in-
clluded in the attack poteential calcullation.
FPT_EMSEC.1/C
CHIP-ONLY
Y TOE Em
manation
FPT_EMSEC.1.1//CHIP-ON NLY The T TOE shall notn emit measurable

m signals in
ncluding
power ffluctuation
ns in excess of none ennabling acceess to POI_
_PayDatSK
K and PIN Encryp-
E
tion Keeys and non
ne.
FPT_EMSEC.1.2//CHIP-ON NLY The TS SF shall ensure all userrs are unablle to use thee follow-
ing inteerface emannations (inccluding powwer fluctuaations) to gain
g access tto POI_PayDatSK
and PIN N Encryptiion Keys an nd none.
Applicaation note:
This requiremennt is only ap
pplicable forr the POI-C
CHIP-ONLY Y configurattion.
9.1.2 Secu
uirements in
i each basse PP
506 The table beloww shows thee SFRs incluuded in eacch base PP and
a the TSFF part the in
ndividual
requuirements arre associated with.
th
4 6 March,
M 2015
POI P
Protection Profile
Securityy fea-
PED- PO
OI- OI-CHIP-
PO
SFR Pacckage tures (seee sec- TSF
F part(s)
ONLY CO
OMPREHEN
NSIVE ON
NLY
tion 3.2..2)
PIN Entrry 1 CoreeTSF X X X
2 X
CoreeTSFKeys
ENC_PIIN X X (Co
oreTSF
CoreeTSF
only
y)
3, 4 CoreeTSFKeys
PLAIN__PIN X X
CoreeTSF
5 CoreeTSFKeys
IC Card Reader X X
IC C
Card Reader
POI_DA
ATA 8, 12 MidddleTSF X X
6, 7(if SR
RED, CoreeTSF
CoreTSF
F X X X
also 14)
11 (if SRRED al- PED DMiddleTSF
F
PEDMidddleTSF X X X
so 8)
MiddleT
TSF 9, 12 MidddleTSF X X
PED Proompt Controll 10 PEDDMiddleTSF
FX X X
(supportt various CoreeTSF X X X
Cryptogrraphy features)) PEDDMiddleTSF
FX X X
MidddleTSF X X
Physicall Protection
11 CoreeTSFKeys X
FPT_PH
HP.3/CoreTSF
F X
CoreeTSF
FPT_EMMSEC.1/ Co-- 11 CoreeTSFKeys X
X
reTSF
FPT_PHHP.3/ ICCar- 11 ICC
CR TSF
X X
dReaderr
FPT_PHHP.3/MSR 11 MSRR X X
FPT_PHHP.3/ CHIP- 11, 13 CoreeTSF
X
ONLY
FPT_EMMSEC.1/ 11 CoreeTSF
X
CHIP_OONLY
Table 13: SFR pack
kages inclu
uded in each
h base PP
9.1.3 Secu
uirements dependenci
d ies rationalle
507 The dependenccy analysis for

f the secuurity functioonal requireements showws that the basis
b for
muttual supportt and intern
nal consisteency betweeen all defin ned functionnal requirem
ments is
satissfied. All dependencie
d s between tthe chosen functional componentts are analy ysed, and
non--dissolved dependencie
d es are approopriately ex
xplained.
508 The dependenccy analysis has directlyy been mad de within th he descriptiion of each
h SFR in
secttion 9.1. Alll dependenccies from C CC part 2 annd defined by b the extennded compo onents in
secttion 8 are either fulfilleed or their no
non-fulfilmeent is justifieed.
th
4 Page 121
POI P
Protection Profile
9.2 Secu
urity Assurrance Requ
uirements
509 The minimum EAL appliccable to thee products evaluated

e ag
gainst this PPP is EAL POI de-
fined hereafter..
510 Mosst of the asssurance commponents b elonging to o EAL POI come from m EAL2 pree-defined
packkage. The additions
a to EAL2 conncern the ev valuation off the developpment enviironment
throough ALC_D DVS.2 (inclluding the ssite inspection of the In
nitial Key LLoading faciility) and
the vulnerabilitty analysis of the POI ’s TSF partts to the suuitable attacck potential through
the extended reequirement AVA_POII: POI-High h for Keys in CoreTSSF (except for f POI-
CHIIP-ONLY, where thesse keys are POI-Modeerate), POI--Moderate ffor CoreTS SF, POI-
EnhhancedLow for Plaintex xt PIN proccessing by the IC Carrd Reader, PPOI-Low for f PED-
MidddleTSF, annd POI-Basic for MiddlleTSF and MSR.M
t lists th
he Security Assurance Requiremen
nts includedd in EAL PO
OI:
 “STAND
DARD” meeans that thee CC requirrement applies as is,
 “REFINNED” mean ns that the C ment has beeen refinedd in this PP to meet
CC requirem
POI speecificities an
nd EPC requuirements,
 NDED” meeans that thee requiremeent does not belong to C
“EXTEN CC Part3,
 A greyeed cell mean
ns that the rrequirementt does not apply to the correspond
ding TSF
part.
512 Notiice that EAL L POI doess not includee AVA_VA AN.2 since each
e instancce of AVA_ _POI is a
refinnement of AVA_VAN
A N.2 restrictedd to the PO
OI componennts selectedd in the instaantiation
(cf. the annex inn chapter 14
4 for detailss).
513 The “STANDA
ARD” requirrements aree defined in CC Part3.
514 The “REFINED D” and the “EXTEND
DED” requirrements aree defined inn sections 9.2.2
9 and
9.2.33 respectiveely.
EA
AL POI
Securityy Assurancee Requiremeents PE
ED- POI-- POI-C
CHIP-
ON- COMMPREHEN-- ONLYY
LY
Y SIVE
E
AD
DV_ARC.1 RE
EFINED X X X
AD
DV_FSP.2 RE
EFINED X X X
AD
DV_TDS.1 RE
EFINED X X X
AG
GD_OPE.1 RE
EFINED X X X
EAL2
AG
GD_PRE.1 RE
EFINED X X X
AL
LC_CMC.2 RE
EFINED X X X
AL
LC_CMS.2 RE
EFINED X X X
AL
LC_DEL.1 RE
EFINED X X X
AT
TE_COV.1 STANDARD
D X X X
th
4 6 March,
M 2015
POI P
Protection Profile
AT
TE_FUN.1 STANDARD
D X X X
AT
TE_IND.2 RE
EFINED X X X
AV
VA_VAN.2
AL
LC_DVS.2 RE
EFINED X X X
AL
LC_FLR.1 RE
EFINED X X X
AV
VA_POI.1/MS
SR POI-Basic X X
attack potentiial
AV
VA_POI.1/PE
EDMiddleT POI-Low X X X
Extended Requirements
SF
F
attack potentiial
AV
VA_POI.1/MiiddleTSF POI-Basic X X
attack potentiial
AVVA_POI.1/IC Card POI-EnhanceedLow X X
Reeader
attack potentiial
AV
VA_POI.1/CooreTSF POI-Moderatte X X X
attack potentiial
AVVA_POI.1/CooreTSFKey POI-High X X
s
attack potentiial
Table 14: Definittion of EAL

L POI by base
b PP
9.2.1 Secu
uirements Rationale
R
515 The EAL POI was develo oped by thee Common Approval
A Scheme
S Initiiative (CAS
S) in co-
operration with the Joint In
nterpretationn Library Terminal Evaaluation Sub
ubgroup (JTE EMS) to
be uused for CCC evaluation n of POI. MMembers off JTEMS are bank asssociations, payment
p
scheemes, certiffication bodies, POI m manufacturrers and ev
valuation laaboratories whereas
memmbers of CA AS are the riisk owner oof the payment schemess.
 Fromm JTEMS point
p of vieew, the EALL POI packaage permitss a developeer to gain sufficient
assuurance from
m positive security
s enngineering based
b on good comm mercial deveelopment
pracctices whichh do not require
r subbstantial speecialist kno
owledge, skkills, and other
o re-
sourrces. Moreoover, the EAAL POI provvides the reequired assu urance in ecoonomically
y feasible
wayy.
 The starting pooint of EAL L POI was CAS risk analysis an nd its deriveed security require-
mennts (see the annex in chhapter 13.1) . Indeed, seelecting mosst of the asssurance com
mponents
from
m EAL2 forr EAL POI was suffici ent to meett the CAS security requuirements as a shown
in A
Annex 13.2 “Mapping from EPC B Book 4 to SFRs
S and SARs”.
S CASS requirements that
fall outside stanndard SAR R are addresssed by add ditions (like ALC_DVSS.2), by speecific re-
finements stateed in sectio on 9.2.2 annd by exteensions with h new assuurance com mponents
AVA A_POI, statted in sectio
on 9.2.3. AVVA_POI co omponents allow
a to goo beyond EA
AL2 vul-
neraability analyysis withou
ut significannt increase of documen ntation, dessign and testing ef-
fort.. Moreover, this new family
f fullyy meets CAAS security requiremennts regarding g the at-
th
4 Page 123
POI P
Protection Profile
tackk potential levels.
l The relationshiip between the family AVA_POII and the assurance
commponent AV VA_VAN.2 is shown inn the annex in chapter 14.1
 For the chosenn assurance componennts all the dependencie
d es are met or exceedeed in the
EALL POI assurrance package as shownn in section
n 9.2.4.
9.2.2 Refiined securiity assurancce requirem

ments
9.2.2.1 ADV_FSP
P Function
nal Specific ation
ADV_F
FSP.2 Securrity-enforccing functioonal specification
ADV_F
FSP.2.1D The developeer shall provvide a functtional specification.
ADV_F FSP.2.2D The developeer shall provvide a tracin

ng from thee functional specificatio
on to the
SFRs.
ADV_F
FSP.2.1C The function
nal specificaation shall completely represent
r the
he TSF.
ADV_F FSP.2.2C The function

nal specificaation shall describe
d the purpose annd method of
o use for
all TSFII.
ADV_F FSP.2.3C The

T function nal specificaation shall identify
i and
d describe aall parameteers asso-
ciated w
with each TS SFI.
Refinemment:
If the T
TOE claims conforman nce to packaage "SFR-su upporting features
f relaated to Opeen Proto-
cols", thhe followingg holds.
P
PCIF1: Thee TSFIs con nsisting in pprotocols or services sh
hall be consiidered at leaast SFR-
supportinng and shalll define the following parameters:
p
 Protoccol name
 Protoccol type:
 Link Layerr Protocols
 IP Protocolls
 Security Prrotocols
 IP Servicess
 Other
 Protoccol number (for IP prottocols)
 Port number
n (forr IP servicess)
ADV_F FSP.2.4C For each SFR R-enforcingg TSFI, the functional specificatioon shall desccribe the
SFR-ennforcing actiions associaated with thee TSFI.
ADV_F FSP.2.5C For each SFR R-enforcingg TSFI, the functional specificatioon shall describe di-
rect erroor messagess resulting from
f processsing associaated with th
he SFR-enfoorcing actio
ons.
th
4 6 March,
M 2015
POI P
Protection Profile
ADV_F FSP.2.6C The
T tracing shall
s demonnstrate that the SFRs trrace to TSFFIs in the fu
unctional
specificcation.
ADV_F FSP.2.1E The evaluato

he informatiion providedd meets all require-
ments fo
for content and
ADV_F FSP.2.2E Thhe evaluato or shall deteermine that the function

nal specificcation is an accurate
and commplete instanntiation of the
t SFRs.{ X XE "ADV_ _ARC.1/PCII__ONLY" }
9.2.2.2 ADV_TD DS Basic design
ADV_T
TDS.1 Basicc design
ADV_T
TDS.1.1D The
T developer shall proovide the design of the TOE.
ADV_T TDS.1.2D The T develop per shall prrovide a mapping

m from the TSFFI of the fu
unctional
specificcation to thee lowest leveel of decom
mposition av
vailable in th
he TOE dessign.
ADV_T
TDS.1.1C The
T design shall
s describbe the structture of the TOE
T in term
ms of subsysstems.
ADV_T
TDS.1.2C The
T design shall
s identiffy all subsysstems of thee TSF.
ADV_T TDS.1.3C The T design shall descrribe the beh haviour of each SFR-ssupporting or SFR-
non-inteerfering TSF F subsystem m in sufficieent detail to o determine that it is noot SFR-enforcing.
Refinemment:
In particcular, for SFFR-supportiing featuress related to OpenO Protocols, the folllowing hollds: The
design sshall describbe the behav viour of eacch SFR-supporting or SFR S non-intterfering TS SF sub-
system iin sufficiennt detail to determine
d thhat it is not SFR-enforc
S ing. For all SFR-suppo orting
TSF subbsystem impplementing a security pprotocol, the design shaall describee
P
PCII2: how w the device provides coonfidentiality of data sent over a nnetwork con nnection,
includingg
a) Encryyption mech hanism withh key sizes appropriatee for the alg lgorithm(s) in ques-
tion.
b) Encryyption proviided by usinng keys thatt are establiished in a seecure mann ner using
approopriate key-m managemennt procedurees, such as those t listed in NIST SPP800-21,
Guideelines for Im
mplementingg Cryptograaphy
P
PCII3: how w the devicee is able to provide thee integrity of o data thatt is sent oveer a net-
work connnection, in ncluding
a) Integrrity provided d by a MAC C as defined d in ISO 166609, or by a digital signnature.
b) Hashiing provided by at leasst one of th he following g algorithm ms: SHA-224, SHA-
256, SHA-384,
S and
a SHA-5112.
P
PCII4: how w the device uses a decllared securitty protocol to authenticcate the serv ver.
a) Serverr authenticaation with kkey sizes app propriate for the algoritthm(s) in qu
uestion.
b) Hashiing provided by at leasst one of th he following g algorithm ms: SHA-224, SHA-
256, SHA-384,
S and
a SHA-5112.
c) verificcation of thee validity off public key ys received by
b the platfform.
th
4 Page 125
POI P
Protection Profile
d) verificcation of thee authenticiity of publicc keys received by the pplatform.
P
PCII6: Howw the platforrm implemeents session n managemeent.
a) Trackking of all connections
c s and restriction of thee number oof sessions that can
remaiin active on the platform m to the minimum necessary numb mber.
b) Time limits for sessions
s andd insurance that sessions are not lleft open fo or longer
than necessary.
n
ADV_T TDS.1.4C The T design

n shall sum
mmarise thee SFR-enforcing behav
aviour of th
he SFR-
enforcinng subsystem
ms.
ADV_T TDS.1.5C TheT design shall provvide a desccription of the interacctions amonng SFR-
enforcinng subsystem
ms of the TSF,
T and bettween the SFR-enforci
S ing subsysteems of the TSF
T and
other suubsystems of
o the TSF.
ADV_T TDS.1.6C The

T mappin ng shall dem monstrate that
t all TSF
FIs trace too the behav
viour de-
scribed in the TOE
E design thatt they invokke.
ADV_T TDS.1.1E The T evaluattor shall coonfirm thatt the inform

mation provvided meets all re-
quiremeents for conntent and preesentation oof evidence.
ADV_T TDS.1.2E The T evaluato or shall deteermine that the design is

i an accuraate and com
mplete in-
stantiatiion of all seecurity functtional requiirements.
9.2.2.3 ADV_AR RC Security y Architectture
ADV_A
ARC.1 Secu
urity archittecture des cription
ADV_A ARC.1.1D The T develop per shall de sign and im

mplement the TOE so thhat the secu
urity fea-
tures off the TSF caannot be byp
passed.
ADV_A ARC.1.2D TheT develop per shall deesign and immplement th

he TSF so thhat it is ablee to pro-
tect itseelf from tam
mpering by untrusted
u acctive entitiess.
ADV_A
ARC.1.3D The
T develop
per shall proovide a secu
urity architeecture descrription of the TSF.
ADV_A ARC.1.1C TheT security y architectuure descriptiion shall be at a level oof detail com
mmensu-
rate witth the description of th
he SFR-enfoorcing abstrractions described in thhe TOE design doc-
ument.
ADV_A ARC.1.2C The T security y architectuure description shall describe

d thee security domains
maintainned by the TSF
T consisttently with tthe SFRs.
Refinemment:
If the POI_DATA package is included inn the set off evaluated SFRs, S the ssecurity arch
hitecture
descripttion shall describe
d thee security ddomains thaat result froom the appplication seeparation
principlle (requuirement EPCN2),, speciffied in FDP_A ACC.1/POI_ _DATA,
FDP_ACF.1/POI_D DATA and FDP_RIP. 1/POI_DAT TA. This deesign inform mation shalll explain
the mecchanisms used
u to achiieve applic ation separration. It shhall describbe how isollation of
th
4 6 March,
M 2015
POI P
Protection Profile
paymennt applicatioon data is acchieved, how
w the correct execution
n of the payyment application is
enforcedd as well ass the manag gement of CCardholder communicaation interfaace during payment
p
applicattion executiion and how
w interferencce from oth
her applications is avoidded.
ADV_A ARC.1.3C The T security y architectuure descriptiion shall deescribe how

w the TSF in nitialisa-
tion proocess is secuure.
Refinemment:
In particcular, for SFFR-supportiing featuress related to Open
O Protocols, the folllowing hollds:
P
PCIH2: In particular,
p the
t securityy architectu ure shall demmonstrate hhow the deffaut con-
figuratioon is secure for each TSSFI of the following
f ty
ypes : Link Layer Proto ocols, IP
Protocols, Security Protocols, IIP Services..
ADV_A ARC.1.4C The T security y architectuure descripttion shall demonstrate

d e that the TSF
T pro-
tects itself from tammpering.
Refinem ment:
In particcular, the seecurity architecture desscription shaall demonsttrate that,
P
PCIA4: Sennsitive functions or datta are only usedu in the protected aareas(s) of the
t PED.
This refiinement is not
n applicabble for the POI-CHIP-O
P ONLY confiiguration.
P
PCIA10: Seecure comp ponents intennded for un nattended deevices conta tain an anti--removal
mechanism to pro otect againsst unauthorized remo oval and/orr unauthoriized re-
installatiion. This refinement iss not applicable for thee POI-CHIPP-ONLY co onfigura-
tion. Thhis part of the T TSF is asssigned to PEDMidddleTSF an nd thus
AVA_PO OI.1/PEDM MiddleTSF hhas to be ap pplied to th
his propertyy of the seccurity ar-
chitecturre.
P
PCIB18: Thhe operating g system off the devicee must contain only thee software (compo-
nents annd services)) necessaryy for the in ntended opeeration. Thee operating g system
must be configured securely annd run with least privileege.
P
PCIB20: Thhe POI is capable
c of pperforming only its dessigned funcctions - i.e.,, there is
no hiddeen functionality. The oonly approv ved functioons perform med by the POI are
12
those allowed by thee policy.
P
PCID1: It is i neither feeasible to ppenetrate thee IC Card Reader
R to m
make any ad dditions,
substituttions, or moodifications to either th
he IC Card Reader's
R har
ardware or software,
s
in order to determin ne or modify fy any sensiitive data, nor
n is it posssible for bo oth an IC
card andd any other foreign objject to resid de within th he card inseertion slot. This re-
finementt is not appllicable for thhe POI-CHIP-ONLY configuratio
c on.
P
PCID2 : Thhe opening for the inseertion of thee IC card is in full view w of the caardholder
during card insertio on so that anny untoward d obstructioons or suspiicious objeccts at the
opening are detectable. This reefinement iss not applicable for thee POI-CHIP P-ONLY
configurration.
P
PCID3 : Thhe ICC read der is constrructed so thhat wires running out oof the slot ofo the IC
Card Reaader to a recorder or a transmitterr (an externaal bug) can be observeed by the
Cardholdder. This reefinement iss not applicable for thee POI-CHIPP-ONLY co onfigura-
tion.
Refinem ment:
12 This iss a part of the PCIB20 requiirement: the reemainder is ad

ddressed as a refinement off AGD_OPE.1
1.
th
4 Page 127
POI P
Protection Profile
In particcular, for SF FR-supportiing featuress related to Open
P
PCIH3: In particular
p th
he security architecturee shall dem monstrate hoow the TSF protects
an unautthorized tam mpering of kkeys or certiificates
ADV_A ARC.1.5C The T security ure description shall dem
y architectur monstrate thhat the TSF pre-
vents byypass of thee SFR-enforrcing functioonality.
Refinemment:
In particcular, the seecurity architecture desscription shaall demonsttrate that:
P
PCIA2: Faiilure of a single securrity mechan nism does not
n comprom mise PED security.
Protectioon against a threat is baased on a co ombination of at least ttwo indepen ndent se-
curity mechanisms
m (these mecchanisms maym be based on the same princciples or
technoloogy, such ass sensors, ass long as th heir operatioon is indepeendent – e.gg. multi-
ple switcches activatted on openning of the device casiing are not independen nt). This
refinemeent is not ap pplicable in the POI-CH HIP-ONLY configuratiion.
P
PCIB16: Alll prompts for f non-PIN N data entry are under thhe control oof the crypto
ographic
unit of thhe device. If
I the promppts are storeed inside the cryptograaphic unit, th hey can-
not feasiibly be alterred without causing thee erasure off the unit’s ccryptograph hic keys.
If the proompts are stored outsidde the crypttographic un nit, cryptoggraphic mecchanisms
must exiist to ensurre the autheenticity and d the proper use of the he prompts and that
modificaation of the prompts or improper use u of the prrompts are pprevented.
E
EPC-CHIP--ONLYB16 6: Cryptograaphic mechanisms musst exist to ennsure the au uthentic-
ity and the
t proper use u of the pprompts and d that modification of the promptts or im-
proper use of the pro ompts are pprevented.
Refinemment:
In particcular, for SF FR-supportiing featuress related to Open
P
PCIG2: Thee security arrchitecture sshall demon nstrate:
 How the TSF pro otects itselff from the exploitation of a public--knowledgee vulner-
abilityy on a TSF FI of the foollowing typ pes : Link Layer
L Protoocols, IP Prrotocols,
Securrity Protocols, IP Servicces, including
a) exploitattion of replaay of messages (PCII5)),
b) exploitattion of inseccure exception handling (PCII5).
P
PCIH3: Thee security arrchitecture sshall demon nstrate:
 How the TSF pro otects itselff from bypaass of the SFR-enforcinng function nality via
an unexpected ussage of keyss or certificates.
ADV_A ARC.1.1E TheT evaluattor shall coonfirm thatt the inform

{ XE "AADV_ARC..1/PCI__ON NLY" }
9.2.2.4 AGD_OP PE Operatio onal user gguidance
AGD_O
OPE.1 Opeerational usser guidancce
AGD_O OPE.1.1D The T develop per shall proovide operattional user guidance.
g
Refinemment:
In particcular, the usser guidance shall addrress the following topiccs:
th
4 6 March,
M 2015
POI P
Protection Profile
P
PCIB19: Thhe vendor must
m providde adequate documenteed security gguidance fo or the in-
tegrationn of any secuure componnent into a PIN
P entry POI Terminaal.
P
PCIB20: A user-availaable securityy policy fro om the vend dor addressees the propeer use of
the POI in a securee fashion, iincluding in nformation on key-mannagement responsi-
r
bilities, administrati
a ive responssibilities, deevice functionality, ideentification, and en-
vironmenntal requireements. Thee security policy
p must define the roles supported by
the POI and indicatte the servicces available for each role in a ddeterministicc tabular
format.133
P
PCID2: Thee opening forf the inserrtion of thee IC card is in full view w of the caardholder
during card insertioon so that anny untoward d obstructio
ons or suspiicious objeccts at the
opening are detectable. This reefinement iss not applicable for thee POI-CHIP P-ONLY
configurration.
P
PCIM8: Thhe user guid dance shall pprovide insstructions fo or the operaational management
of the TO OE. This includes instrructions for recording the
t entire liffe cycle of the
t TOE
componeents and of the mannerr in which th hose compo onents are inntegrated in
nto a sin-
gle POI, e.g.:
 Data on o production and perssonalisation n,
 Physical/chronological wherreabouts,
 Repaiir and mainttenance,
 Remooval from op peration,
 Loss or o theft.
T
The user guuidance shaall include guidance for f how thee POI is puut into main ntenance
mode, annd the vend dor’s requirrements forr secure han ndling of thhe POI. Thee vendor
guidancee is requiredd in additionn to any guiidance that may be issuued by the Acquirer
A
or Merchhant.
AGD_O OPE.1.1C The T operatio onal user gguidance shall describee, for each user role, the
t user-
accessibble functionns and priviileges that sshould be controlled
c in
n a secure pprocessing environ-
ment, inncluding apppropriate warnings.
w
AGD_O OPE.1.2C The T operatio onal user guuidance shaall describe, for each usser role, how to use
the avaiilable interffaces provid
ded by the TTOE in a seccure mannerr.
Applicaation Note:
In particular, for SFR-support
S ting featurees related to
o Open Prottocols, the fo
following hoolds:
D
DTR H1: The T device hash securityy guidance that t describ
bes how prootocols and services
must be used for each TSFI off the followin ng types: Link Layer PProtocols, IPP Proto-
cols, Seccurity Proto
ocols, IP Seervices. Thee operationa al user guiddance shall also de-
scribe hoow to use th
he availablee protocol oro service innterfaces prrovided by the TOE
in a secuure mannerr. The opera rational guidance not only
o describbes human interac-
tions witth the TOE but also thhe secure in ntegration with
w other ssystems, deevices or
applicatiions.
13 This iss a part of the PCIB20 requiirement: the reemainder is ad

ddressed as a refinement off ADV_ARC.1.
th
4 Page 129
POI P
Protection Profile
AGD_O OPE.1.3C The T operatio onal user guuidance shaall describe,, for each uuser role, thee availa-
ble funcctions and innterfaces, inn particularr all security
y parameters under the control of the user,
indicatinng secure values
v as app
propriate.
Applicaation Note:
following ho olds:
P
PCIH3: Thee device hass guidance ffor key man nagement describing hoow keys and d certifi-
cates muust be used.
a) The key-managem
k ment guidannce is at thee disposal of
o internal uusers, and/o or of ap-
plicattion develop pers, system
m integratorss, and end-uusers of thee platform.
b) Key-m management security gguidance desscribes the properties of all keys and cer-
tificattes that can be used by the platform m.
c) Key-mmanagementt security guuidance desscribes the responsibili
r ities of the platform
p
vendoor, applicattion developpers, system m integrators, and endd-users of the t plat-
form.
d) Key-mmanagementt security guuidance enssures securee use of keys ys and certifficates.
AGD_O OPE.1.4C The T operatio onal user guuidance shaall, for each user role, cclearly pressent each
type of security-reelevant even
nt relative tto the user--accessible functions thhat need too be per-
formed,, including changing the
t securityy characteriistics of enttities underr the contro ol of the
TSF.
AGD_O OPE.1.5C The T operatio onal user guuidance shaall identify all
a possible modes of operation
o
of the T
TOE (includding operattion followiing failure or operatio onal error), their conseequences
and impplications foor maintainiing secure ooperation.
AGD_O OPE.1.6C TheT operatio onal user guuidance shaall, for each user role, ddescribe the security
measurees to be followed in orrder to fulfiil the securiity objectives for the ooperational environ-
ment as described in
i the ST.
AGD_O
OPE.1.7C The
T operatio
onal user guuidance shalll be clear and
a reasonabble.
AGD_O OPE.1.1E TheT evaluattor shall coonfirm that the inform mation provvided meetss all re-
Applicaation Note:
following hoolds:
D
DTR H1: TheT evaluato or shall nott limit to thee human ussers of the TTOE. The evaluator
shall enssure that thhe mapping between alll SFR-supp porting TSFFIs and guidance is
completee and consisstent.
Applicaation note:
Developping and maanufacturing of the TO OE are part of the developer phasee. During th he devel-
oper phhase the inittial cryptogrraphic keyss are loaded d and if requ
uired also oother crypto
ographic
keys aree loaded intto the POI. Additionallly, cryptogrraphic keys can also bee loaded du uring the
user phase. The ST T author sh hall define w where the developer
d phase ends aand where the user
phase bbegins in rellation to cryyptographicc key loading g.
th
4 6 March,
M 2015
POI P
Protection Profile
9.2.2.5 AGD_PR
RE Prepara
ative proced
dure
AGD_P
PRE.1 Prep
parative procedures
AGD_P PRE.1.1D TheT develop per shall proovide the TO

OE includin ng its preparrative proceedures.
Applicaation Note:
following ho olds:
D
DTR H2: TheT device hash guidan ce that desscribes the default
d conf
nfiguration for
f each
TSFI of the followiing types: L Link Layer Protocols, IP Protocools, Securityy Proto-
cols, IP Services. The
T evaluattor shall en nsure that thhe mappingg between all a SFR-
supportinng TSFIs an
nd preparattive procedu ures is compplete and coonsistent.
AGD_P PRE.1.1C The T preparaative proceddures shall describe

d all the steps nnecessary fo
or secure
acceptannce of the delivered
d OE in accorrdance with the develop
TO per's deliverry procedurres.
AGD_P PRE.1.2C TheT preparaative proceddures shall describe

d all the steps nnecessary fo
or secure
installattion of the TOE and for
fo the securre preparatiion of the operational
o environmennt in ac-
cordancce with the security
s objectives for tthe operatio
onal environ
nment as deescribed in the
t ST.
AGD_P PRE.1.1E The T evaluattor shall coonfirm thatt the inform mation provvided meets all re-
Applicaation Note:
following hoolds:
D
DTR H2 Thhe device has h guidancce that desccribes the default
d conf
nfiguration for
f each
TSFI of the followiing types: L Link Layer Protocols, IP Protocools, Securityy Proto-
cols, IP Services. The
T evaluattor shall en nsure that th
he mappingg between alla SFR-
supportinng TSFIs an nd preparattive procedu ures is comp
plete and coonsistent.
AGD_P PRE.1.2E TheT evaluattor shall appply the preparative procedures tto confirm that the
TOE caan be preparred securely
y for operatiion.
9.2.2.6 ALC_CM
MC CM cap
pabilities
ALC_C
CMC.2 Usee of a CM sy
ystem
ALC_C
CMC.2.1D The
T develop
per shall proovide the TOE
T and a reeference forr the TOE.
ALC_C
CMC.2.2D The
T develop
per shall proovide the CM
C documen
ntation.
ALC_C
CMC.2.3D The
T develop
per shall us e a CM system.
ALC_C CMC.2.1C The T TOE sh hall be labellled with itss unique refference.
Refinem
ment:
ED in order to comply with the fo
The uniique identiffication shalll also applly to the PE ollowing
CAS reqquirement:
P
PCIM7: Eacch device sh hall have a unique visib ble identifieer affixed too it.
th
4 Page 131
POI P
Protection Profile
The uniqque identifieer applies too the tamperr-resistant boundaries
b ((e.g. PED, IC
I Card
Reader). They mustt be visible w without opeening the terrminal.
ALC_C CMC.2.2C The T CM do

ocumentatioon shall desccribe the meethod used tto uniquely
y identify
the conffiguration ittems.
ALC_C
CMC.2.3C The
T CM system shall uuniquely ideentify all co
onfigurationn items.
ALC_C CMC.2.1E The mation provvided meets all re-

T evaluaator shall coonfirm thatt the inform
9.2.2.7 ALC_CM
MS CM Sco
ope
ALC_C
CMS.2 Partts of the TO
OE CM covverage
ALC_C
CMS.2.1D The
T develop
per shall proovide a conffiguration liist for the T
TOE.
ALC_C CMS.2.1C TheT configu uration list sshall include the follow
wing: the TO
OE itself; th
he evalu-
ation evvidence requuired by thee SARs; andd the parts th hat comprisse the TOE.
ALC_C CMS.2.2C The

T configu uration list sshall uniqueely identify the configuuration items.
Refinem
ment:
P
PCIB3: Thee firmware, and any chhanges therreafter, havee been insppected and reviewed
r
using a documented
d d and auditaable process, and certified as beinng free from m hidden
and unauuthorized orr undocumeented functio ons.
ALC_C CMS.2.3C ForF each TS SF relevant configuratiion item, th

he configuraation list sh
hall indi-
cate thee developer of the item..
ALC_C CMS.2.1E The T evaluattor shall coonfirm thatt the inform

9.2.2.8 ALC_DE
EL Delivery
y
ALC_D
DEL.1 Delivvery proced
dures
ALC_D DEL.1.1D TheT develop

per shall doocument pro
ocedures forr delivery oof the TOE or parts
of it to tthe consumer.
ALC_D
DEL.1.2D The
T develop
per shall usee the deliverry procedures.
ALC_D DEL.1.1C The T delivery y documenttation shall describe alll proceduress that are necessary
to mainttain securityy when disttributing verrsions of thee TOE to th
he consumerr.
ALC_D DEL.1.1E The T evaluator shall coonfirm that the inform

mation provvided meetss all re-
th
4 6 March,
M 2015
POI P
Protection Profile
Refinem ment:
The evaaluator shalll confirm thhe use of thee delivery procedures
p by
b examinattion of the develop-
d
er's doccumentationn and eviden nces. The deelivery proccedures involving the IInitial Key Loading
Facilityy, shall be allso checked
d during a siite visit (cf. ALC_DVSS.2).
9.2.2.9 ALC_DV
VS Developm
ment Securrity
ALC_D
DVS.2 Suffiiciency of security meeasures
ALC_D DVS.2.1D The

T develop per shall prooduce and provide
p devvelopment ssecurity doccumenta-
tion.
Refinem ment:
The devvelopment environmen
e nt stands forr the designn, manufacturing, assem mbling and d mainte-
nance eenvironmentts of TOE componentts, including the final assembly aand the Iniitial Key
Loadingg facilities. The Initial Key Loadinng is defineed as the poiint where reesponsibilityy for the
TOE seecurity-related components (here aand in the following
f text "securityy-related" iss used in
the sensse of "SFR--enforcing".) falls to thhe acquirerss. The initiaal key here is not the Acquirer
A
key, butt is the keyy that assurees the autheentication of
o the hardwware device independen nt of the
its ultim
mate purposee and destinnation.
ALC_D DVS.2.1C The T develop pment secuurity docum mentation sh hall describbe all the physical,
p
proceduural, personnnel, and oth her securityy measures that
t are necessary to prrotect the confiden-
tiality annd integrityy of the TOEE design andd implemen ntation in itss developme
ment environ nment.
Refinem ment:
In the fo
following reequirementss ‘device’ reeflects the PED P and th
he POI secuurity-relatedd compo-
nents. Inn terms of Common
C Crriteria securrity-related means SFR R-enforcing..
The devvelopment security
s doccumentationn shall meet the followiing requirem ments:
T
The developpment secu urity docum mentation shall describee the entire device man nufactur-
ing lifecycle, up to and includding Initial Key Loadin ng, and shaall identify the sites
involvedd in each lifeecycle stagee.
PCIL2: Thee certified144 firmware is protected and storeed in such a manner ass to pre-
P
clude unnauthorized modificatioon during itts entire maanufacturingg life-cycle e.g., by
using duual control or standarddized cryptographic au uthenticatioon procedurres. This
requiremment addressses the firmwmware of thee device.
P
PCIL3: Thee device is assembled
a inn a manner that the com mponents oof the devicee used in
the manuufacturing process
p are those comp ponents thatt were certiified by the require-
ments off this PP (no ot to be appllied for SRE ED and SFR R-supportinng features for
f Open
Protocols) in the sccope of the evaluation n and unauthorized subbstitutions have
h not
been madde.
Applicattion Note: These
T compoonents belon ng to the TO
OE configurration list.
P
PCIL4: Prooduction sofftware (e.g.., firmware)) that is loaaded to devvices at thee time of
manufaccture is tran nsported, stoored, and used
u under the principple of dual control,
preventinng unauthorrized modiffications and d/or substitu
utions.
14 Certified here means that the Firmmware has beeen checked by

y the developer. Hence the FFirmware thatt is part of
the configguration itemss has been cheecked in integr
grity.
th
4 Page 133
POI P
Protection Profile
P
PCIL5: Subbsequent to productionn but prior to o shipment from the m manufacturerr's or re-
seller’s facility,
f thee device andd any of itss componen nts are storeed in proteccted, ac-
cess-conntrolled areaa or sealed w within tamp per-evident packaging
p tto prevent undetect-
u
ed unautthorized acccess to the ddevice or its componentts.
P
PCIL6: If thhe device willw be autheenticated att the key-loaading facilitty of initiall deploy-
ment by means of secret inforrmation plaaced in the device durring manufaacturing,
then thiss secret information is uunique to eaach device, unknown aand unpredictable to
any person, and insttalled in thee device und der dual con ntrol to ensuure that it iss not dis-
closed duuring installlation.
P
PCIL7: Seccurity measu ures are takken during developmen
d nt and mainntenance off POI se-
curity-reelated components. Thee manufactu urer must maintain
m a deevelopment security
documenntation desccribing all thhe physical,, procedurall, personnell, and other security
measuress that are necessary
n too protect thee integrity ofo the desiggn and impllementa-
tion of thhe POI secu urity-relatedd componen nts in their developmen
d nt environm ment. The
developm ment securiity documeentation shaall provide evidence that these security
measuress are follow wed during tthe develop pment and maintenance
m e of the POI securi-
ty-relatedd componen nts. The eviidence shalll justify thatt the securitty measuress provide
the neceessary levell of protecttion to maiintain the integrityi off the POI security-
s
related components.
P
PCIL8: Conntrols exist over the reppair processs and the inspection/tessting processs subse-
quent to repair to en nsure that thhe device haas not been subject to uunauthorizeed modi-
fication.
P
PCIM3: Whhile in transsit from thee manufactu urer's facilitty to the iniitial key-loaading fa-
cility, thee device is:
 Shippped and storred in tampeer-evident packaging;
p and/or,
a
 Shippped and sto ored containning a secreet that is im mmediatelyy and autom matically
erasedd if any phyysical or funnctional alteeration to thhe device is attempted, that can
be verified by th he initial keey-loading facility,
f but that cannoot feasibly be b deter-
minedd by unauth horized persoonnel.
P
PCIM4: Thhe device’s developmen
d nt security documentat
d tion must prrovide mean ns to the
initial keey-loading facility
f to aassure the au uthenticity of the TOE E’s security relevant
componeents.
P
PCIM5: If the t manufacturer is in charge of initiali key-lloading, theen the manu ufacturer
must verrify the auth henticity of tthe POI seccurity-relateed componeents.
PCIM6: If the manufaacturer is noot in chargee of initial key-loadingg, the manu
P ufacturer
must proovide the means
m to thee initial key-loading faccility to asssure the verrification
o the POI seecurity-relaated compon
of the auuthenticity of nents.
The devvelopment security
s doccumentationn shall describe all the delivery prrocedures necessary
to mainntain the seccurity of thee TOE compponents beffore assemb bling, subseqquent to pro oduction
and prioor to shipmeent and on the t way to the Initial KeyK Loading Facility. T The deliverry proce-
dures shhall contribuute enforcin ng the follow wing requirements:
P
PCIL4: Prooduction sofftware (e.g.., firmware)) that is loaaded to devvices at thee time of
manufaccture is tran nsported, stoored, and used
u under the principple of dual control,
preventinng unauthorrized modiffications and d/or substitu utions.
P
PCIM1: Thhe POI shou uld be prottected from m unauthorizzed modificcation with tamper-
evident security features, andd customerss shall be provided w with docum mentation
th
4 6 March,
M 2015
POI P
Protection Profile
(both shiipped with the productt and availaable securely y online) thhat providess instruc-
tion on validating
v th
he authenticcity and inteegrity of thee POI.
Where thhis is not possible,
p thee POI is shipped from the manuffacturer’s faacility to
the initiaal key-loadiing facility or to the faacility of initial deployyment and stored
s en
route undder auditablle controls tthat can acccount for the location oof every PO OI at eve-
ry point in time.
Where multiple
m partties are invoolved in org
ganizing thee shipping, iit is the resp
ponsibil-
ity of each party to ensure thatt the shippin ng and storaage they aree managing g is com-
pliant wiith this requuirement.
P
PCIM2: Procedures arre in placee to transferr accountab bility for thhe device from
f the
manufaccturer to the initial-key--loading faccility.
ALC_D DVS.2.2C The

T develoopment secuurity docum mentation shall
s justify
fy that the security
measurees provide the
t necessarry level of pprotection to maintain the confideentiality and
d integri-
ty of thee TOE.
ALC_D DVS.2.1E TheT evaluator shall coonfirm that the inform

mation provvided meetss all re-
ALC_D DVS.2.2E The

T evaluato or shall conffirm that thee security measures
m aree being appllied.
Refinem
ment:
E
EPC PlusL00: The evaluator shall confirm thaat the security measurees are being g applied
by exammination off the develooper's docu umentation and evideences. The security
measuress involvingg the final aassembly an nd the Initiaal Key Loaading facilitties shall
be checkked during a site visit to each releevant site (as determinned by the lifecycle
l
descriptiion for ALC
C_DVS.2.1C C).
9.2.2.100 ALC_FLR
R Flaw Remediation
ALC_F
FLR.1 Basic flaw rem
mediation
ALC_F FLR.1.1D The T develop per shall doccument and d provide flaaw remediaation proced dures ad-
dressed to TOE devvelopers.
Refinemment:
In particcular, for SF
FR-supportiing featuress related to Open
P
PCIG3: Thee notion off "reports off security flaws"
f inclu
udes all pubblic-knowledge vul-
nerabilitiies found on
n SFR-suppporting TSF FIs of the folllowing typpes: Link Laayer Pro-
tocols, IP
P Protocols,, Security P
Protocols, IP
P Services.
ALC_F FLR.1.1C The T flaw reemediation pprocedures documentaation shall ddescribe th

he proce-
dures ussed to trackk all reported
d security fllaws in each
h release off the TOE.
ALC_F FLR.1.2C The T flaw rem mediation pprocedures shall requirre that a deescription off the na-
ture andd effect of each
e securitty flaw be pprovided, ass well as thee status of ffinding a co
orrection
to that fflaw.
Refinemment:
th
4 Page 135
POI P
Protection Profile
The flaw w remediatiion procedu ures shall ennsure a timeely distributtion of inforrmation abo
out new-
ly foundd vulnerabillities and mitigations
m ffor the vulneerabilities; this
t informaation includ des iden-
tificatioon, descriptiion, and assessment of the vulneraabilities. Thee procedurees shall ensuure time-
ly creatiion of mitiggation meassures for neewly found vulnerabilitties that maay impact PO OI secu-
rity.
ALC_F FLR.1.3C The T flaw reemediation proceduress shall requ uire that coorrective acctions be
identifieed for each of the securrity flaws.
Refinemment:
The flaw w remediatiion procedu ures shall ennsure timely y detection of vulnerabbilities that apply to
the deviice by perioodical execu ution of a vvulnerabilityy assessmennt that incluudes activitties such
as: analyysis, surveyy of informaation availabble in the pu
ublic domaiin, and testiing.
ALC_F FLR.1.4C TheT flaw rem mediation pprocedures documentat

d tion shall deescribe the methods
used to provide flaaw informattion, correcttions and guidance
g on corrective actions to TOE
T us-
ers.
ALC_F FLR.1.1E The T evaluattor shall coonfirm thatt the inform

9.2.2.111 ATE_IND
D Independ
dent testingg - sample
ALC_IN
ND.2 Independent testing - sam
mple
ATE_IN
ND.2.1D Thhe developeer shall provvide the TO
OE for testin
ng.
ATE_IN
ND.2.1C Thhe TOE shaall be suitabble for testin
ng.
ATE_IN ND.2.1E Thhe evaluato

he information providedd meets all require-
ments fo
for content and
ATE_IN ND.2.2C Thhe developeer shall provvide an equ uivalent set of resourcees to those th
hat were
used in the developper's functio
onal testing of the TSF..
ATE_IN ND.2.2E Thhe evaluatoor shall test a subset off the TSF to confirm thhat the TSF operates
as speciified.
Refinemment:
P
PCII1: The evaluator shall
s verifyy that all seccurity proto
ocols presennt on the deevice are
describedd as SFR-su
upporting T TSFIs in the functional specificatioon.
F
For all thesee TSFI, the evaluator sshall assess that:
P
PCII2: The device is able
a to provvide confideentiality of data sent oover a network con-
nection.
 a) Enncryption mechanism
m uutilizes key sizes appro
opriate for the algorith
hm(s) in
questiion.
th
4 6 March,
M 2015
POI P
Protection Profile
 b) Enncryption is provided bby using key ys that are established
e in a securee manner
using appropriatte key-mannagement prrocedures, such as thoose listed in i NIST
SP8000-21, Guideelines for Immplementing g Cryptograaphy
P
PCII3: The device is able
a to provvide the integrity of daata that is ssent over a network
connection.
 a) Inteegrity is pro
ovided by a MAC as deefined in ISO 16609, oor by a digital signa-
ture.
 b) Haashing can be b providedd by at leasst one of th he followingg algorithm ms: SHA-
224, SHA-256,
S SHA-384,
S annd SHA-512.
P
PCII4: The device usess a declaredd security prrotocol to au uthenticate tthe server.
 a) Server authen ntication uttilizes key sizes appro opriate for the algorith hm(s) in
questiion.
 b) Haashing can be b providedd by at leasst one of th he followingg algorithm ms: SHA-
224, SHA-256,
S SHA-384,
S annd SHA-512.
 c) Thee platform isi able to veerify the vallidity of the public keyss it receivess.
 d) The platform is i able to veerify the autthenticity off the public keys it receeives.
P
PCII6: The platform immplements ssession man nagement.
 a) Thhe platform keeps trackk of all con nnections an nd restricts the numberr of ses-
sions that can remmain active on the platfform to the minimum nnecessary nu umber.
 b) The platform sets
s time lim mits for sesssions and en nsures that ssessions aree not left
open for longer than necessaary.
9.2.3 Exteended security assuraance requirrements
516 The AVA_POII requiremen

nts of the EA
AL POI pacckage consiists of:
 AVA_P
POI.1.
517 AVA A_POI.1 is iterated fiv
ve times annd applied to MSR, PE
EDMiddleTSSF, MiddleeTSF, IC
Cardd Reader, CoreTSF
C andd CoreTSFK Keys.
9.2.3.1 AVA_PO OI applied tot MSR

518 This
s requiremeent holds in PED-ONLY
Y and POI-COMPREH
HENSIVE cconfiguratio
ons only.
AVA_P
POI.1/MSR
R ”POI vuln
nerability aanalysis”
Dependdencies:
ADV_A
ARC.1 Secuurity architecture descriiption
ADV_F
ADV_T
TDS.1 Basicc modular design
d
AGD_O
OPE.1 Operaational userr guidance
AGD_P
PRE.1 Prepaarative proccedures Objeectives
Developper action elements:

e
th
4 Page 137
POI P
Protection Profile
AVA_P POI.1.1D/MMSR The deeveloper shaall provide the Magnetic Stripe R
Reader com
mponent
of the P
POI for testing.
AVA_PPOI.1.2D/M MSR The deeveloper shhall providee the implem mentation reepresentatio
on and a
mappingg of SFRs to
t the impleementation rrepresentatiion of the Magnetic
M SStripe Readder com-
ponent of the POII.
Contentt and presenntation elem

ments:
AVA_P POI.1.1C/M MSR The Magnetic

M Sttripe Readeer component of the POI shall be
b suita-
ble for ttesting.
Evaluattor action ellements:
AVA_P POI.1.1E/MMSR The ev valuator shaall confirm

m that the in
nformation provided meets
m all
requirem
ments for coontent and presentation
p n of evidencce.
AVA_P POI.1.2E/M MSR The evaluator sh hall perform

m a search of public domain so ources to
identifyy potential vulnerabiliti
v es in the M
Magnetic Strripe Readerr componennt of the PO
OI.
AVA_P POI.1.3E/M MSR The ev valuator shaall perform

m an indepen ndent vulneerability anaalysis of
the Maagnetic Strripe Readerr componeent of the POI using the guidannce documeentation,
functionnal specificaation, desig
gn, the secur
urity architeccture descriiption as weell as the available
a
implemmentation representatiion and th e mapping g of SFRs to t the impllementation n repre-
sentatioon to identiffy potential vulnerabiliities.
AVA_P POI.1.4E/M MSR The ev valuator shaall conductt penetration testing, bbased on the identi-
fied pottential vulnnerabilities, to determinne that the Magnetic Stripe Reaader compo onent of
the POII is resistannt to attacks performedd by an attaccker possesssing attackk potential equal
e or
higher than POI-B Basic attacck potentiaal with a minimum attack potenntial for thee exploi-
tation p
phase of a value
v defined in [POI AttackPott].
Applicaation note:
 IInputs for MSR

M vulnerrability anaalysis do no ot need to be separatee documentts – they
mmay be inclluded in oth her TOE deeliverables. Important aspects to bbe shown in n the in-
pputs is the design
d and layout
l of anny relevant tamper-resiistance aspeects of the MSR,
M the
iinterfaces between
b theese and the processor responsiblee for detectiion and ressponding
tto tamperinng with the MSR,
M and thhe nature off the respon
nses.
 The vulneraabilities exaamined shalll include penetration
p of the TOEE to make any addi-
ttions, substtitutions, or modificatioons to the Magnetic
M Sttripe read hhead and asssociated
hhardware oro software, in order to determine or modify Magnetic
M Str
tripe data.
9.2.3.2 AVA_PO OI applied tot MiddleT TSF

519 This s requiremeent holds in the POI-COOMPREHENSIVE and
d in the POII-CHIP-ON
NLY con-
figuurations onlyy.
th
4 6 March,
M 2015
POI P
Protection Profile
AVA_P
POI.1/Midd
dleTSF “PO
OI vulnerab
bility analy
ysis”
Dependdencies:
ADV_A
ADV_F
ADV_T
d
AGD_O
AGD_P

e
AVA_P POI.1.1D/M
MiddleTSF The develooper shall prrovide the MiddleTSF
M F’s compon
nents for
testing.
AVA_P POI.1.2D/MMiddleTSF The develooper shall provide

p the implementaation repressentation
and a m
mapping of SFRs
S to the implementaation repressentation off ‘none’.

ments:
AVA_P
POI.1.1C/M mponents shall be suitaable for testting.
MiddleTSF The MiddlleTSF’s com
AVA_P POI.1.1E/M MiddleTSF The evaluaator shall confirm th hat the infformation provided
p
meets alll requiremeents for con
ntent and preesentation of
o evidence.
AVA_P POI.1.2E/M MiddleTSF The evaluaator shall peerform a search of pubblic domain
n sources
to identify potentiaal vulnerabillities in the MiddleTSF
F’s compon
nents.
AVA_P POI.1.3E/M MiddleTSF The evaluat ator shall perform an in

ndependent vvulnerabilitty analy-
sis of thhe MiddleT TSF’s comp ponents usinng the guid dance docummentation, thhe functional speci-
ficationn, the designn, the securiity architectture descrip
ption as welll as none tto identify potential
p
vulnerabbilities.
AVA_P POI.1.4E/M MiddleTSF The evaluaator shall conductc pen

netration tessting, based
d on the
identifieed potentiall vulnerabillities, to deetermine thaat the Midd
dleTSF’s ccomponentss are re-
sistant tto attacks performed
p by
b an attaccker possesssing POI-B Basic attackk potentiall with a
minimu um attack potential
p fo
or the explloitation ph hase of a value defineed in [POI Attack-
Pot].
Refinemment:
P
PCIG2: In particular
p th
he evaluatorr shall explo oit public-knnowledge vvulnerabilitiies on all
SFR-suppporting TSFIs of the ffollowing ty ypes: Link Layer Protoocols, IP Prrotocols,
Security Protocols, IP Servicess. Exploitattion method ds shall incclude at leasst replay
of messaages and exp
ploitation o f insecure exception
e haandling.
th
4 Page 139
POI P
Protection Profile
9.2.3.3 AVA_PO OI applied tot PEDMid ddleTSF
520 This
s requiremeent holds in all configurrations.
AVA_P
POI.1/PEDM
MiddleTSF
F “POI vul nerability analysis”
a
Dependdencies:
ADV_A
ADV_F
ADV_T
d
AGD_O
AGD_P

e
AVA_PPOI.1.1D/P PEDMiddleTSF The ddeveloper sh

hall providee the PEDM
MiddleTSF
F’s com-
ponentss for testingg.
AVA_P POI.1.2D/PPEDMiddleTSF The ddeveloper sh hall providee the implemmentation represen-

r
tation annd a mapping of SFRss to the impplementation
n representaation of the hardware and
a soft-
ware PE EDMiddleT TSF’s comp ponents.

ments:
AVA_P POI.1.1C/P
PEDMiddleTSF The P
PEDMiddleeTSF’s com
mponents shhall be suittable for
testing.
AVA_P POI.1.1E/PE EDMiddleT TSF The evvaluator shaall confirm that the innformation provided
p
o evidence.
AVA_P POI.1.2E/PE EDMiddleT TSF The eevaluator sh m a searchh of public domain

hall perform
sources to identify potential vu
ulnerabilitiees in the PE
EDMiddleT TSF’s compponents.
AVA_P POI.1.3E/PE EDMiddleT TSF The evvaluator sh hall perform

m an indepeendent vulnnerability
analysiss of the PED DMiddleTS SF’s compoonents usin ng the guidaance docum
mentation, fu
unctional
specificcation, desiggn, security architecturre descriptio
on as well as
a the avaiilable implementa-
tion rep presentatioon and the mapping of SFRs to o the impleementationn representtation to
v es.
AVA_P POI.1.4E/PE EDMiddleT TSF The eevaluator sh hall conductt penetratioon testing, based
b on
the idenntified potenntial vulnerrabilities, too determine that the PE
EDMiddleT TSF’s commponents
are resisstant to attaacks perform
med by an atttacker posssessing POII-Low attacck potentia al with a
p fo
or the explloitation phhase of a value defineed in [POI Attack-
Pot].
Refinemment:
th
4 6 March,
M 2015
POI P
Protection Profile
P
p th
he evaluatorr shall explo
oit public-knnowledge vvulnerabilitiies on all
of messaages and expploitation o f insecure exception
e haandling.
9.2.3.4 AVA_PO OI applied tot IC Card Reader TS

SF
521 This
s requiremeent holds in PED-ONLYY and POI-COMPREH
ons only.
AVA_P
POI.1/IC Card Reader “POI vullnerability analysis”
Dependdencies:
ADV_A
ADV_F
ADV_T
d
AGD_O
AGD_P

e
AVA_P POI.1.1D/IC C Card Reader The ddeveloper sh

hall providee the IC Caard Reader compo-
nents foor testing.
AVA_P POI.1.2D/IC
C Card Reeader The ddeveloper shhall providee the implemmentation represen-
r
tation aand a mappiing of SFR
Rs to implem
mentation reepresentatio
on of the hhardware and
a soft-
ware IC C Card Reaader compo onents.

ments:
AVA_P POI.1.1C/IC
C Card Reeader The IIC Card Reader
R com
mponents shhall be suittable for
testing.
AVA_P POI.1.1E/IC C Card Reader The eevaluator sh hall confirm

m that the innformation provided
p
o evidence.
AVA_P POI.1.2E/IC C Card Reeader The evaluator shall s perforrm a searchh of public domain
ulnerabilitiees in the IC Card Readder componnents.
AVA_P POI.1.3E/IC C Card Reeader The eevaluator sh hall perform

m an indepeendent vuln
nerability
analysiss of the IC Card Reader compoonents using g the guidaance docum
mentation, fuunctional
on as well as
tion reppresentatioon and the mapping
m off SFRs to implementa ation repreesentation to
t identi-
fy potenntial vulneraabilities.
AVA_P POI.1.4E/IC C Card Reeader The eevaluator sh hall conduct penetratioon testing, based
b on
the idenntified potential vulnerrabilities, too determinee that the IC Card Re
Reader com mponents
th
4 Page 141
POI P
Protection Profile
are resistant to attaacks perform
med by an attacker poossessing POOI-EnhanccedLow atttack po-
tential w
with a min nimum atta ack potentiial for the exploitation
e n phase of a value deefined in
[POI AAttackPot].
Refinemment:
P
p th
e haandling.
9.2.3.5 AVA_PO OI applied to

t CoreTSF F
522 This s requiremeent holds for all configgurations. In
n addition, for
f the POII-CHIP-ONLY con-
figuuration the following
f holds:
h For thhe POI-CH HIP-ONLY configuratioon CoreTSFF covers
in adddition secrret Paymentt Transactioon Keys.
523 If thhe SRED PP-Module
P is selected AVA_POI.1/CoreTSF F is appliedd also to thee part of
MidddleTSF whhich stores and
a processees cryptograaphic data to protect acccount data.
AVA_P
POI.1/CoreeTSF “POI Vulnerabiility Analyssis”
Dependdencies:
ADV_A
ADV_F
ADV_T
d
AGD_O
AGD_P

e
AVA_PPOI.1.1D/C
CoreTSF Th
he developeer shall prov
vide the CoreTSF’s coomponents for test-
ing.
AVA_P POI.1.2D/CCoreTSF Th he developper shall prrovide the implementa

i ation repressentation
and a m
mapping of SFRs
S to thee implementtation repreesentation of the hardw
ware and software
s
CoreTSSF’s compoonents.

ments:
AVA_P
POI.1.1C/C
CoreTSF Th
he CoreTSF
F’s compon
nents shall be
b suitable ffor testing.
AVA_P POI.1.1E/C CoreTSF Th he evaluatorr shall conffirm that th

he informatiion provideed meets
all requirements for content an
nd presentattion of evid
dence.
AVA_P POI.1.2E/C CoreTSF Th he evaluatorr shall perfo

orm a searcch of publicc domain so
ources to
v es in the CooreTSF’s componentss.
th
4 6 March,
M 2015
POI P
Protection Profile
AVA_P POI.1.3E/C CoreTSF Th he evaluatorr shall perfoorm an indeependent vuulnerability analysis
of the C CoreTSF’s componen nts using thhe guidancee documentaation, functtional speciification,
design, security arcchitecture description
d aas well as the
t availab ble implemeentation reepresen-
tation aand the maapping of SFRs
S to thee implemen ntation rep
presentationn to identiffy poten-
tial vulnnerabilities.
AVA_P POI.1.4E/C CoreTSF Th he evaluatorr shall condduct penetration testingg, based on the
t iden-
tified pootential vullnerabilities, to determiine that thee CoreTSF’’s componeents are ressistant to
attacks performed by an attaccker possesssing POI-M Moderate attack
a poteential with a mini-
mum atttack poten ntial for thee exploitatiion phase ofo a value defined in [P POI AttackkPot].
Refinemment:
P
p th
e haandling.
9.2.3.6 AVA_PO OI applied tot the Core TSFKeys

524 This
s requiremeent holds in PED-ONLY Y and POI-COMPREH
ons only.
525 AVA A_POI.1/CooreTSFKey ys is appliedd to the parrt of CoreTS
SF which sttores and processes
p
secrret PIN Enccryption Key
ys in PED--ONLY and d POI-COM MPREHENSSIVE config gurations
onlyy.
526 Notee that AVA A_POI.1/Co
oreTSFKeyss supersedees AVA_PO
OI.1/CoreTSSF regardin
ng secret
PINN Encryptionn Keys (CoreTSFKeyss) in PED-O
ONLY and POI-COMP
P PREHENSIV VE con-
figuuration only.
AVA_P
POI.1/CoreeTSFKeys “POI
“ vulneerability an
nalysis”
Dependdencies:
ADV_A
ADV_F
ADV_T
d
AGD_O
AGD_P

e
AVA_P POI.1.1D/C
CoreTSFKeeys The devveloper shall provide th
he CoreTSF
FKeys com
mponents
for testiing.
AVA_P POI.1.2D/CCoreTSFKeeys The devveloper shalll provide the implemeentation reppresenta-

tion andd a mappingg of SFRs to
o implemenntation repreesentation of
o the hardw
ware and software
s
CoreTS SFKeys commponents.
th
4 Page 143
POI P
Protection Profile
ments:
AVA_P
POI.1.1C/C
CoreTSFKeeys The CorreTSFKeyss componen
nts shall be suitable forr testing.
AVA_P POI.1.1E/C CoreTSFKeeys The evaaluator shalll confirm that the infformation provided
p
o evidence.
AVA_P POI.1.2E/C CoreTSFKeeys The evvaluator shaall perform m a search of public domain
ulnerabilitiees in the Co
oreTSFKey
ys componeents.
AVA_P POI.1.3E/C CoreTSFKeeys The evaaluator shaall perform an indepeendent vuln nerability
analysiss of the CooreTSFKey ys compon nents using the guidan nce documeentation, fuunctional
on as well as
tion reppresentatioon and the mapping
m off SFRs to implementa ation repreesentation to
t identi-
fy potenntial vulneraabilities.
AVA_P POI.1.4E/C CoreTSFKeeys The evalluator shalll conduct peenetration teesting, baseed on the
identifieed potentiall vulnerabillities, to dettermine thaat the CoreT
TSFKeys ccomponents are re-
sistant tto attacks performed
p by
b an attaccker possessing POI-H High attackk potentiall with a
p foor the explloitation ph hase of a value defineed in [POI Attack-
Pot].
Refinemment:
P
p th
e haandling.
9.2.4 Secu
uirements Dependenci
D ies
Requireements Deependenciess Satisfied D

Dependenciees
ADV_AR
RC.1 (A
ADV_FSP.1 ) and ADV_FSP.2,, ADV_TDS.11
(A
ADV_TDS.11)
ADV_FS
SP.2 (A
ADV_TDS.11) ADV_TDS.11
ADV_TD
DS.1 (A
ADV_FSP.2 ) ADV_FSP.2
AGD_OP
PE.1 (A
ADV_FSP.1 ) ADV_FSP.2
AGD_PR
RE.1 No
o dependenccies
ALC_CM
MC.2 (A
ALC_CMS.11) ALC_CMS.22
ALC_CM
MS.2 No
o dependenccies
ALC_DE
EL.1 No
o dependenccies
ATE_CO
OV.1 (A E_FUN.1) ADV_FSP.2,, ATE_FUN.11
ADV_FSP.2 ) and (ATE
th
4 6 March,
M 2015
POI P
Protection Profile
ATE_FU
UN.1 (A
ATE_COV.11) ATE_COV.11
ATE_IND
D.2 (A
ADV_FSP.2 ) and ADV_FSP.2,, AGD
D_OPE.1,
(A
AGD_OPE.11) and AGD_PRE.1 , ATE
E_COV.1,
ATE_FUN.1
(A
AGD_PRE.11) and
(A
ATE_COV.11) and
(A
ATE_FUN.11)
ALC_D
DVS.2 No
o dependenccies
AVA_P
POI.1/MSR (A
ADV_ARC.11) and ADV_ARC.11, ADV
V_FSP.2,
ADV_FSP.2 )
(A and ADV_TDS.11, AGD
D_OPE.1,
AGD_PRE.1
(A
ADV_TDS.11) and
(A
AGD_OPE.11) and
(A
AGD_PRE.11)
AVA_P
POI.1/PEDM
Middle (A
V_FSP.2,
TSF ADV_FSP.2 )
(A and ADV_TDS.11, AGD
D_OPE.1,
AGD_PRE.1
(A
ADV_TDS.11) and
(A
AGD_OPE.11) and
(A
AGD_PRE.11)
AVA_P
POI.1/MiddlleTSF (A
V_FSP.2,
(A
ADV_FSP.2 ) and ADV_TDS.11, AGD
D_OPE.1,
AGD_PRE.1
(A
ADV_TDS.11) and
(A
AGD_OPE.11) and
(A
AGD_PRE.11)
AVA_P POI.1/IC Card (A
V_FSP.2,
Reader (A
D_OPE.1,
AGD_PRE.1
(A
ADV_TDS.11) and
(A
AGD_OPE.11) and
(A
AGD_PRE.11)
AVA_P
POI.1/CoreT
TSF (A
V_FSP.2,
(A
D_OPE.1,
AGD_PRE.1
(A
ADV_TDS.11) and
(A
AGD_OPE.11) and
(A
AGD_PRE.11)
AVA_P
POI.1/CoreT
TSFKe (A
V_FSP.2,
ys (A
D_OPE.1,
AGD_PRE.1
(A
ADV_TDS.11) and
(A
AGD_OPE.11) and
(A
AGD_PRE.11)
Table 155: SAR depeendencies
th
4 Page 145
POI P
Protection Profile
10 Ratiionale Objeectives/SFR
R

t provid
des an overvview of the coverage of security oobjectives byy securi-
ty fuunctional reequirements and constittutes eviden
nce for suffiiciency andd necessity of
o the se-
lecteed SFRs.
XE
O.POIApplicationSeparatio
O.PaymentTransaction
O.PaymentApplication
O.PEDMiddleSWHW
O.PromptControl
O ICCardReader
O.ICCardReader
O.CoreSWHW
O.CipherPPIN
O.ClearPPIN
O.POI_SW{
O.PINEntry
Download
O.EncPIN
EncPIN
O.MSR
O
PIN Enttry Packagee

FDP_IF
FC.1/PIN_E
ENTRY X
FDP_IT
TC.1/PIN_E
ENTRY X
FPT_EM
MSEC.1/PIN
N_ENTRY X
FIA_UA
AU.2/PIN_E
ENTRY X X X X X X X
FIA_UIID.1/PIN_E
ENTRY X X X X X X X
FTA_SS
SL.3/PIN_E
ENTRY X
ENC_PIN Packagee
FDP_IF
FC.1/ENC_P
PIN X
FDP_IF
FF.1/ENC_P
PIN X
FMT_M
MSA.1/ENC
C_PIN X
FMT_S
SMR.1/ENC
C_PIN X X X
FIA_UIID.1/ENC_P
PIN X
FDP_RIIP.1/ENC_P
PIN X
FDP_IT
TT.1/ENC_P
PIN X
FTP_TR
RP.1/ENC__PIN X
PLAIN__PIN Packaage
FDP_IF
FC.1/PLAIN
N_PIN X X
FDP_IF
FF.1/PLAIN
N_PIN X X
FDP_RIIP.1/PLAIN
N_PIN X X
th
4 6 March,
M 2015
POI P
Protection Profile
XE
O.PEDMiddleSWHW
O.PromptControl
O ICCardReader
O.ICCardReader
O.CoreSWHW
O.CipherPPIN
O.ClearPPIN
O.POI_SW{
O.PINEntry
Download
O.EncPIN
EncPIN
O.MSR
O
FDP_IT
TT.1/PLAIN
N_PIN X X
FMT_M
MSA.1/PLA
AIN_PIN X X
FIA_UIID.1/PLAIN
N_PIN X X
IC Cardd Reader Paackage
FDP_IF
FC.1/ICCarddReader X
FDP_IF
FF.1/ICCarddReader X
FDP_RIIP.1/ICCarddReader X
FDP_IT
TT.1/ICCarddReader X
FDP_ACC.1/ICCR
RLoader X
FDP_IT
TC.1/ICCRL
Loader X
POI_DA
ATA Packaage
FDP_ACC.1/POI__DATA X X
FDP_ACF.1/POI_D
DATA X X
FDP_IT
TT.1/POI_D
DATA X
FDP_UIT.1/POI_D
DAT X
FDP_UCT.1/POI_D
DATA X
FDP_RIIP.1/POI_D
DATA X X
FTP_IT
TC.1/POI_D
DATA X
CoreTS
SF Package
FPT_TS
ST.1/CoreT
TSF X
FPT_FL
LS.1/CoreTSF X
FDP_ACC.1/CoreT
TSFLoader X
FDP_IT
TC.1/CoreTSFLoader X
PEDMiddleTSF Paackage
FPT_TS
ST.1/PEDM
MiddleTSF X
FPT_FL
LS.1/PEDM
MiddleTSF X
th
4 Page 147
POI P
Protection Profile
XE
O.PEDMiddleSWHW
O.PromptControl
O ICCardReader
O.ICCardReader
O.CoreSWHW
O.CipherPPIN
O.ClearPPIN
O.POI_SW{
O.PINEntry
Download
O.EncPIN
EncPIN
O.MSR
O
FDP_ACC.1/PEDM
MiddleTSFL
Lo X
ader
FDP_IT
TC.1/PEDM
MiddleTSFL
Loa X
der
MiddleT
TSF Packagge
FDP_ACC.1/MidddleTSFLoad
der X
FDP_IT
TC.1/MiddleeTSFLoadeer X
FPT_FL
LS.1/MiddleeTSF X
FDP_ACC.1/AppliicationLoad
der X
FDP_IT
TC.1/AppliccationLoadeer X
PED Prompt Contrrol Package
FDP_ACC.1/PEDP
PromptConttro X
l
FDP_ACF.1/PEDP
PromptConttro X
l
Cryptoggraphy Packkage
FCS_RN
ND.1 X X
FCS_CO
OP.1 X X X
FDP_IT
TC.2 X X X
FTP_IT
TC.1/Cryptoo X X X
FPT_TD
DC.1 X X X
Physicaal Protectionn Package
FPT_PH
HP.3/CoreT
TSF X X X X X X
FPT_EM
MSEC.1/CooreTSF X X X
FPT_PH
HP.3/ICCarrdReader X
FPT_PH
HP.3/MSR X
FPT_PH
HP.3/CHIP--ONLY X X
th
4 6 March,
M 2015
POI P
Protection Profile
XE
O.PEDMiddleSWHW
O.PromptControl
O ICCardReader
O.ICCardReader
O.CoreSWHW
O.CipherPPIN
O.ClearPPIN
O.POI_SW{
O.PINEntry
Download
O.EncPIN
EncPIN
O.MSR
O
FPT_EM
MSEC.1/CH
HIP-ONLY X
Tab
ble 16: Obj ectives cov
verage by SFRs
528 A ddetailed justtification required for ssuitability of
o the securrity functionnal requirem
ments to
achiieve the security objecttives is giveen below.
529 O.P
PINEntry
530 Ratiionale:
- WWith FPT__EMSEC.1//PIN_ENTR RY the PE ED only em mits indistiinguishable audible
ttones, if anny (PCIA11 1); the PEDD does not emit sound d, electro-mmagnetic em missions,
ppower consumption or o any otheer externall characteristic availabble for mo onitoring
((PCIA5); not
n emit thee entered PIIN digits att the display y (PCIB5). Because of the re-
dduced risks in a the POOI-CHIP-ON NLY config guration PC
CIA5 is not aapplicable anda does
nnot contribuute to the ob
bjective in tthat configu
uration. This is caused in the diffeerent risk
aanalysis beetween POII-CHIP-ON NLY and otther configu urations whhere in PO OI-CHIP-
OONLY onlyy IC Card based transacctions are accepted.
- WWith FPT_P PHP.3/CoreeTSF the PEED resists physical
p mannipulation aand manipu
ulation of
tthe CoreTSSF hardware to protecct the confid
dentiality of
o any PIN (PCIA1) in ncluding
cchanging environmenttal conditioons (PCIA3). Because of the redu duced risks in a the
PPOI-CHIP-ONLY con nfiguration there is noo need to protect thee PIN by hardware
h
mmeans andd PCIA1 is i not appplicabe. Thus FPT_PH HP.3/CHIP--ONLY in nsteat of
FFPT_PHP.33/CoreTSF contributess to that objective for the
t POI-CH HIP-ONLY configu-
rration (PCIA
A3).
- DDue to FIA A_UAU.2/P PIN_ENTRY Y and FIA A_UID.1/PINN_ENTRY Y Sensitive services
eentering or existing sen n reveal or otherwisee affect senssitive in-
nsitive servvices shall not
fformation liike PINs or cryptograpphic keys (PPCIB7).
- AAccording to FDP_IF FC.1/PIN_EN ENTRY and d FDP_ITC.1/PIN_EN NTRY PIN Entry is
oonly alloweed to be enteered at the P
PED keypad
d assigned to
t CoreTSFF (PCI B15).
- AAccording to FTA_SS SL.3/PIN_E ENTRY lim mits on the number
n of actions thaat can be
pperformed and
a a time limit
l shall bbe imposed, after which
h the PED iss forced to return to
iits normal mode
m (PCIB
B8).
531 O.E
EncPIN
532 Ratiionale:
th
4 Page 149
POI P
Protection Profile
- WWith FPT_P PHP.3/CoreeTSF the PE ED resists physical
p mannipulation aand manipu ulation of
tthe CoreTTSF hardwaare to prootect the confidentiaality of anny ENC_P PIN and
EENC_PIN__SK (PCIA A1, PCIA66) includin ng changin ng environnmental co onditions
((PCIA3). Because
B of the
t reducedd risks in a the t POI-CH HIP-ONLY configuratiion there
iis no need to protect the
t PIN by hardware means. m Thus PCIA1 iss not applicable and
ddoes not coontribute to the securityy objective. Only peneetration of tthe PED to disclose
tthe PIN enccryption keyys is contribbuting to thaat objective (at a lowerr level) by hardware
h
mmeans (E EPC-CHIP-O ONLYA6). Thus for POI-C CHIP-ONL LY config gurations
FFPT_PHP.33/CHIP-ON NLY insteadd of FPT_PH HP.3/CoreT TSF applies..
- F
FPT_EMSE
EC.1/CoreT
TSF proteccts ENC_P
PIN_SK against
a em
manation (PCIA6).
(
F
FPT_EMSE
EC.1/CHIP--ONLY ccontribute for POI-CHIP-ONNLY insteead of
F
FPT_EMSE
EC.1/CoreT
TSF (EPC-C
CHIP-ONLYYA6).
- DDue to FDP_IFC.1/
F /ENC_PIN and FDP P_IFF.1/EN NC_PIN the he PED enciphers
EENC_PIN with
w the apppropriate deedicated onlline or offlin
ne encryptioon key imm
mediately
aafter ENC__PIN entry is completee and has been
b signifiied as suchh by the Cardholder
((PCIB6, ).
- TThe PED seends the EN
NC_PIN in encrypted form
f to the IC Card Reeader (offlin
ne) or to
tthe Acquirrer (online)). In case of offlinee encryptio
on FDP_IFC C.1/ENC_P PIN and
FFDP_IFF.1/ENC_PIN mandate enncryption off the PIN (P PCID4.1, PCCID4.3).
- AAccording to FDP_IFC C.1/ENC_P PIN and FDDP_IFF.1/EN
NC_PIN thee PED usess crypto-
ggraphic meeans to preevent the uuse of the PED for exhaustive
e PIN determ
mination
((PCIB10, EPCPlusB10
E 0.a, PCID4. 1, PCID4.3).
- AAccording to FDP_IF FC.1/ENC_P PIN and FD DP_IFF.1/E ENC_PIN itt is not posssible to
eencrypt or decrypt
d any
y arbitrary ddata using any
a PIN rellated key annd PIN relaated keys
hhave differeent values (PCIB13). A Additionallly, output of
o cleartext cryptographic keys
oor moving from one component
c oof higher seecurity to a componennt of less seecurity is
pprevented (PCIB14).
- FFDP_ITT.1/ENC_PIN prevents thhe disclosurre of ENC_ _PIN and E ENC_PIN_S SK when
tthey are traansmitted beetween phyysically-sepaarated partss of the PEDD or to the IC Card
RReader
- FFDP_RIP.1/ENC_PIN prevents uunwanted knowledge
k of secret data upon the de-
aallocation of
o the resou
urces from ssensitive obj
bjects. Especcially ENC__PIN is delleted im-
mmediately after
a being enciphered
e ((PCIB6).
- BBecause off FTP_TRP..1/ENC_PIN N the follow
wing holds: If the PED
D can hold multiple
PPIN encrypption keys and if the keey to be used to encryp
pt the PIN caan be extern
nally se-
llected, thenn the PED prrohibits unaauthorised key
k replacemment and keey misuse (PPCIC1).
- A
According tot FCS_RN ND.1 mechaanisms are provided
p to generate raandom numb
bers that
m
meet a definned quality metric for ccryptograph
hic means (P
PCIB9).
- AAccording to FCS_C
COP.1, PINN enciphermment is perrformed foollowing IS
SO 9564
E 0a, PCIB12,, PCID4.1, PCID4.2, PCID4.4).
P
th
4 6 March,
M 2015
POI P
Protection Profile
- AAccording to FDP_ITC.2 also thhe import off cryptograpphic keys iis according g to ISO
11568 and/or ANSI X9 9.24 and AN
NSI TR-31 (or equivallent). Thereefore state-o
of-the-art
ccryptographhy for cryptographic mmeans is provided (PC
CIB11). Thee cryptograp phic key
y FTP_ITC.11/Crypto an
iimport is suupported by nd FPT_TDC.1.
- W
With FMT T_MSA.1/EN NC_PIN, F FMT_SMR R.1/ENC_PIN N and FIA
A_UID.1/EN
NC_PIN
security attrributes are managed
m annd roles are assigned.
533 O.C
CipherPPIN
N
534 Ratiionale:
- WWith FPT_PPHP.3/CoreeTSF the PEED resists physical
p mannipulation aand manipu
ulation of
tthe CoreTS
SF hardware to protecct the confid
dentiality of
o Ciphertexxt PLAIN_P PIN and
PPLAIN_PINN_SK (PC CIA1, PCIA A6) includiing changing environnmental co onditions
((PCIA3).
- F
FPT_EMSE
EC.1/CoreT
TSF protectss PLAIN_PIIN_SK agaiinst emanattion (PCIA6
6).
- DDue to FDP P_IFC.1/PLLAIN_PIN and FDP_IFF.1/PLAINN_PIN the PED encip phers Ci-
pphertext PL
LAIN_PIN if PED andd IC Card Reader aree not integrrated into the same
ttamper-respponsive bou
undary (PCIID4.2).
- F
FDP_ITT.1/PLAIN_PIIN preventts the discclosure of Ciphertextt PLAIN_P PIN and
P
PLAIN_PIN N_SK whenn they are trransmitted between ph
hysically-sepparated parrts of the
P
PED or to the
t IC Card Reader.
- FFDP_RIP.1/PLAIN_PIIN preventss unwanted d knowledge of secrett data upon
n the de-
aallocation of
o the resouurces from sensitive objects. Especially PLA
AIN_PIN iss deleted
iimmediatelyy after bein
ng enciphereed (PCIB6)..
- A
According tot FCS_RN ND.1 mechaanisms are provided
p to generate raandom numb
bers that
m
meet a definned quality metric for ccryptograph
hic means (P
PCIB9).
COP.1, PINN enciphermment is perrformed foollowing IS
SO 9564
P
- AAccording to FDP_ITC.2 also thhe import off cryptograpphic keys iis according
g to ISO
11568 and//or ANSI X9.24
X and A
ANSI TR-31 (or equivvalent). Theerefore statee-of-the-
aarte cryptoggraphy for cryptographhic means is
i provided (PCIB11). The crypto ographic
kkey import is supported by FTP_IITC.1/Cryptto and FPT__TDC.1.
- W
With FMT_MSA.1/PLAIN N_PIN, FMT__SMR.1/EN NC_PIN and
F
FIA_UID.1/PLAIN_PIIN security attributes are
a managed
d and roles aare assigned
d.
535 O.C
ClearPPIN
536 Ratiionale:
th
4 Page 151
POI P
Protection Profile
- WWith FPT_PPHP.3/CoreeTSF the PE ED resists physical
p man nipulation aand manipu
ulation of
tthe CoreTS
SF hardwaree to protect tthe confiden
ntiality of Plaintext
P PL
LAIN_PIN anda (PCI
NNewA1) inccluding chaanging envirronmental conditions
c (PCIA3).
eentering or existing sen
n reveal or otherwisee affect senssitive in-
- DDue to FDP P_IFC.1/PL LAIN_PIN and FDP_IIFF.1/PLAIN N_PIN the PED transsmits the
PPIN block wholly
w thro
ough the tam
mper-respon
nsive bound
dary if PED and IC Carrd Read-
eer are integrrated into th
he same tam
mper-respon
nsive bound
dary (PCID44.4).
- FFDP_ITT.1/PLAIN_PIIN preventss the disclo osure of Cleeartext PLA AIN_PIN when it is
ttransmitted between ph
hysically-seeparated parrts of the PE
ED or to thee IC Card Reader.
R
- FFDP_RIP.1/PLAIN_PIIN preventss unwanted d knowledge of secrett data upon
n the de-
aallocation of
o the resouurces from sensitive objects. Especially PLAAIN_PIN iss deleted
ng sent to thhe IC Card Reader
R (PCIIB6).
537 O.C
CoreSWHW
W
538 Ratiionale:
- WWith FPT_P PHP.3/CoreeTSF the PEED resists physical
p mannipulation aand manipuulation of
tthe CoreTSSF hardwaree (PCIA1) oor software, including changing
c ennvironmentaal condi-
ttions (PCIA
A3). These requiremennts are not applicable
a for
f the POII-CHIP-ONL LY con-
ffiguration and
a thus do not contrribute to th he security objective ffor the PO OI-CHIP-
OONLY configuration. This is caussed in the different
d risk
k analysis bbetween POOI-CHIP-
OONLY and other confiigurations wwhere in PO
OI-CHIP-ON NLY only IC C Card baseed trans-
aactions are acceepted. Thhus FPTT_PHP.3.1/C CHIP-ONL LY insteaad of
FFPT_PHP.33/CoreTSF applies for POI-CHIP--ONLY (PC CIA3).
- FFPT_TST.11/CoreTSF implementss the period dically checkking of the authenticity y and in-
ttegrity of CoreTSF
C by running a suite of testts during in
nitial start-uup, periodicaally dur-
iing normal operation and
a at the reequest of an authorised user (PCIB B1).
- F
FPT_FLS.11/CoreTSF enforces
e thee CoreTSF authenticity y and integrrity by presserving a
secure statee in case of self-test faillure or logiccal anomaliies (PCIB1, PCIB2).
- TThe protecttion of the authenticity
a y and integrity of CORE_SW and cryptograp phic keys
uupon downnloading of new
n compoonents and updating
u off existing onnes is protected due
tto FDP_ACCC.1.1/CoreeTSFLoaderr and FDP_ _ITC.1/CoreeTSFLoaderr (PCIB2, PCIB4).
P
539 O.P
PEDMiddleeSWHW
540 Ratiionale:
th
4 6 March,
M 2015
POI P
Protection Profile
- FFPT_TST.11/PEDMidd dleTSF impllements thee periodicallly checkingg of the auth henticity
aand integritty of PEDM
MiddleTSF bby running a suite of teests during iinitial start-up, peri-
oodically durring normall operation aand at the request of an
n authorisedd user (PCIB
B1).
- FFPT_FLS.11/PEDMidd dleTSF enfoorces the PEDMiddleT TSF authennticity and integrity
bby preserviing a securee state in caase of self--test failure or logical anomalies (PCIB1,
PPCIB2).
- TThe protecttion of the authenticitty and integ
grity of PE
ED_MIDDL LE_SW and d crypto-
ggraphic keyys upon dowwnloading oof new com mponents annd updatingg of existing
g ones is
pprotected due to FDP_A ACC.1/PED DMiddleTSFFLoader and
FFDP_ITC.11/PEDMidd dleTSFLoadder (PCIB2, PCIB4).
541 O.IC
CCardReader
542 Ratiionale:
- FFPT_PHP.33/CoreTSF and FPT_E EMSEC.1/C CoreTSF pro otect secret cryptographic keys
pprocessed in the IC Caard Reader against dissclosure by physical atttacks or by
y emana-
ttion (PCIA66).
- F D1) protect the IC Carrd Reader aagainst the physical
FPT_PHP.33/ICCardReeader (PCID
ttampering.
- FFDP_IFC.1/ICCardReader and F FDP_IFF.1//ICCardReaader enforcee that the IC I Card
RReader receeives the Ciiphertext PL
LAIN_PIN, deciphers iti and sendss it to the IC
C Card if
PPED and ICC Card Reaader are nott integrated into the on
ne tamper-reesponsive boundary
b
((PCID4.2). FDP_IFC.1/IC Card Reader an nd FDP_IFFF.1/ICCardR Reader enfo orce that
tthe IC Cardd Reader reeceives the CCleartext PLAIN_PIN and sends it to the IC C Card if
PPED and IC Card Reader R are integrated
d into one tamper-ressponsive boundary
b
((PCID4.4). The IC Carrd Reader ddoes not sen nd PLAIN_PPIN to any oother entity than the
IIC Card. The
T IC Card d Reader dooes not sen nd PLAIN_PPIN_SK (iff any) to an ny entity
((PCI NewBB14).
- FFDP_RIP.1/ICCardReader prevennts unwanteed knowledge of secreet data upon n the de-
aallocation of
o the resouurces from sensitive objects. Especially PLAAIN_PIN iss deleted
ng sent to thhe IC Card Reader
R and temporary cryptograp
phic keys
((PCIB6).
- F
FDP_ITT.1/ICCardReader prevvents thee disclosu
ure of PPLAIN_PIN
N and
P
PLAIN_PIN
N_SK in thee IC Card R
Reader.
- W
With FMT_MSA.1/PLAIN N_PIN, FMT__SMR.1/EN NC_PIN and
F
FIA_UID.1/PLAIN_PIIN security attributes are
a managed
d and roles aare assigned
d.
COP.1, PINN deciphermment is perrformed foollowing IS
SO 9564
P
- A
According to FDP_ITC.2 also thhe import off cryptograp
phic keys iis accordingg to ISO
9.24 and AN
11568 and/or ANSI X9 NSI TR-31 (or equivallent). Thereefore state-o
of-the-art
th
4 Page 153
POI P
Protection Profile
ccryptographhy for cryptographic m
means is provided (PC
CIB11). Thee cryptograp
phic key
iimport is suupported by
y FTP_ITC.11/Crypto an
nd FPT_TDC.1.
- TThe protecttion of the authenticityy and integrrity of ICCR R_SW and cryptographic keys
tto FDP_ACCC.1.1/ICCR RLoader annd FDP_ITC C.1/ICCRLo oader (PCIB B2, PCIB4).
543 O.P
PaymentTraansaction
544 Ratiionale:
- FFDP_ITT.1/POI_DAT TA protects Payment Transaction n Data andd POI Man nagement
DData when it is transfe
ferred betweeen physicaally separateed parts of the POI (E
EPCN1.2
aand EPCN11.3).
- FFDP_ITT.1/POI_DAT TA protects the disclosure of POI_ _SK when it is transfeerred be-
ttween physically separrated parts oof the POI (EPCN4).
- F
FDP_UIT.11/POI_DAT TA protectss POI Man nagement Data
D and Paayment Traansaction
D
Data at the external lin
nes of the PO
OI against modification
m n (EPCN1.33 and EPCN
N1.1).
- FFDP_UCT.1/POI_DAT TA providees means to o protect Payment Trannsaction Daata at the
eexternal linnes of the PO
OI against ddisclosure (E
EPCN1.1).
545 FDP P_ACC.1/PO OI_DATA and FDP_A ACF.1/POI_ _DATA preevents otherer applicatio
on to de-
ceivve the Cardhholder durin
ng executionn of the pay
yment appliccation (EPC
CN2.3).
- FTP_ITC.1/PO
OI_DATA provides thhe communiication chan nnel to prootect data att the ex-
tternal lines against dissclosure. Thhis includess means to prove the identity of the POI
((EPCN1.1).
- FD
DP_RIP.1/PO
OI_DATA ensures that SF secret daata is no lonnger accessible once
at MiddleTS
uused.
- Bec
cause of thee specific properties – no hardwarre protection – of a thee POI-CHIP P-ONLY
cconfiguratioon the Acqu uirer needs to know which
w POI iss communiccating with h the Ac-
qquirer durinng an onlinee payment ttransaction.. Therefore FPT_PHP.33/CHIP-ON NLY and
FFPT_EMSE EC.1/CHIP--ONLY enssure that seccret keys prrotecting thee authenticy y and in-
ttegrity of Payment
P Trransaction DData are protected agaainst disclossure and th
hus these
SFRs are coontributing to that objeective.
546 O.PPOI_SW{ XEX "O.POI__SW_HW (Authenticc and integeer usage off POI softw
ware and
relaated hardware)" }
547 Ratiionale:
- FFPT_FLS.11/MiddleTSF enforces the MiddleT TSF authen
nticity and inntegrity by preserv-
iing a securee state in caase of logicaal anomaliess (EPCN7).
- TThe protecttion of the authenticityy and integ
grity of POI_SW and cryptograph hic keys
tto SFRs FDP_AC CC.1/MiddleeTSFLoadeer and FDP_ITC.1 F 1/MiddleTSFLoader
((EPCN3.1 and
a EPCN3 3.2).
th
4 6 March,
M 2015
POI P
Protection Profile
548 O.PaymentAppplicationDow
wnload
549 Ratiionale:
- TThe protecttion of the integrity aand authentticity of thee payment application code is
gguaranteed by SFRRs FDDP_ACC.1//ApplicationnLoader and
FFDP_ITC.11/Applicatio onLoader (EEPCN3.1 an nd EPCN3.2 2).
550 O.P
POIApplicaationSepara
ation
551 Ratiionale:
- FFDP_ACC..1/POI_DATA and FD DP_ACF.1/P POI_DATA A ensures tha
hat no other applica-
ttion has unauthorized access to appplication data
d of a paayment appllication (EP PCN2.1);
tthat it is noot possible for anotheer applicatio on to interffere with thhe execution of the
ppayment appplication by accessingg internal daata (EPCN2 2.2) and thaat it is not be
b possi-
bble for anotther applicaation to deceeive the Caardholder duuring executtion of the payment
p
aapplication (EPCN2.3)).
- FFDP_RIP.1/POI_DAT TA ensures tthat no resiidual inform
mation remaains in resou
urces re-
lleased by thhe paymentt applicatioon and paym
ment application tempoorary cryptoographic
kkeys (EPCNN2.1 to EPC
CN2.3).
552 O.P
PromptCon
ntrol
553 Ratiionale:
- FFDP_ACC..1/PEDProm mptControl and FDP_ _ACF.1/PED DPromptCoontrol enforces the
pprotection of
o PIN prom
mpts and thee control off PED displaay specifyinng different kinds of
iimplementaation (PCIA
A7, PCIB16,, EPC-CHIP P-ONLYB16 for POI-C CHIP-ONLY Y).
554 O.M
MSR
555 Ratiionale:
- FFPT_PHP.33/MSR lead ds to resistaance againstt additions, substitutionns, or modifications
tthat would allow deterrmination oor modificattion of Mag gnetic Strippe data to th
he to the
MMagnetic Stripe
S read head
h and asssociated harrdware and software.
th
4 Page 155
POI P
Protection Profile
11 Glossary
556 For the Comm mon Criteria oriented seections it iss assumed the t reader iis familiar with the
langguage used. If not, pleaase refer to [[CC1]. Those definition
ns are not reepeated herre.
Term Defi
finition
Accquirer A bo ody acquirinng card relaated transactions from M Merchants or oth-
er parties, and ttransmitting
g these transsactions to aan Issuer. Usually,
U
an Acquirer
A is rrepresented
d by a bank or
o a financiial institutio
on. It
can also be anyy body entitlled to acquiire card relaated transacttions.
It is responsiblee for the Meerchant's co
ompliance too the securitty
rules.
Accquirer Pro- An entity
e actingg for or on behalf
b of an
n Acquirer iin acquiring
g card
cesssor relatted transacttions.
Appplication The objective oof a POI is to
t execute applications
a issued by differ-
d
ent application
a providers (e.g.
( bank, health,
h loyallty, governm
ment,
etc.)). A POI maay support a multi appllication envvironment where
w
seveeral applicattions are ex
xecuted simu ultaneouslyy. The appliccations
use functions pprovided by the core software of thhe POI. App plica-
tion
ns may consiist of data and
a softwaree. The appliications are ex-
clud
ded from thee TOE.
Atttended In an attended PPOI, the Meerchant typiically providdes a memb
ber of
stafff who proceesses purchaased items and
a providees assistancee to the
Carddholder in uusing differeent paymen
nt applicatioons.
(Baank) card A caard issued bby a bank (o
or by a simillar institutioon) to perfo
orm
paymment transaactions.
Caardholder A peerson usingg a (bank) caard linked to
o an accounnt to perform
m
paym
ment transaactions.
Caard paymentt Any
y payment trransaction originating
o from a (bannk) card.
CH
HV Carddholder Verrification Devices
D (CHV): devicess for Cardhoolder
auth
hentication, e.g. a PIN Entry
E Devicce (PED). A PED contaains a
keyppad, a displlay, a Securiity Module (SM) for PIIN encryptiion and
mayy also includde an IC Caard Reader. POI as per tthis Protecttion
Proffile includess at least on
ne PED thuss allowing C
Cardholder PIN
P
auth
hentication.
Disstributed ar-- POII architecturres where (aat least) twoo security reelevant partss of the
chiitecture POII (usually thhe PED and the Card Reader) are sseparated deevices
(i.e. not integraated into onee single tam
mper-responnsive boundaary).
Ennciphered Enciphered info
formation.
Ennciphered PIN
N that is onlyy allowed to
o leave the POI
P in encipphered form
m when
th
4 6 March,
M 2015
POI P
Protection Profile
Term Defifinition
PIN
N it haas to be veriified by the IC Card or by the Issuuer.
Enncrypted Synonym for ennciphered.
Firrmware All the softwarre present in
n the POI at the deliveryy point.
Haardware Se- Hard dware Secuurity Module. A physically and loggically proteected
currity Modulee harddware devicce that proviides a securre set of cryp
yptographic ser-
(HSM) vicees.
IC Integrated Circuuit
ICC
C Integrated Circuuit Card
ICC
CR Integrated Circuuit Card Reeader
Inttegrated Ar-- POII architecturres where alll security reelevant partts of the PO
OI are
chiitecture integ
grated into one single tamper-resp
t ponsive bouundary.
Issuer A bo ody issuingg cards to Caardholders and a authenttic transactio ons ini-
tiateed by this caards. Usuallly, an Issuerr is represennted by a baank or
a finnancial instiitution. It caan also be any body ent
ntitled to issu
ue
cardds.
JIL
L Join
nt Interpretaation Library
y
JTE
EMS JIL Terminal E
Evaluation Methodolog
M y Subgroupp
Maagnetic Strip
pe containinng magneticcally encodeed informattion.
Strripe
Meerchant A reetailer, or anny other perrson, compaany, or corpporation thatt
agreees to acceppt (bank) carrds in the frramework oof a contractt with
an Acquirer.
A Inn this Protecction Profilee the Mercha
hant is also respon-
r
siblee for the TOOE in order to protect th he TOE agaainst manipula-
tion
ns of the encclosure.
MS
SR Mag
gnetic Stripee Reader
Muulti applica-- A POI that mayy be used fo
or more than
n one (card)) application
n.
tionn
Off
ffline Defe
ferred proce ssing witho
out direct co
ommunicatioon.
Onnline Direect communnication betw
ween devices with elecctronic capaability
(e.g. POI to hossts).
Oppen Protocoll A seet of requireements that ensures PIN
N entry devvices using open
o
(OPP) secuurity protocools and opeen communiication protoocols to acccess
publlic networkks and servicces do not have
h public domain vullnera-
bilitties.
OS
S In th
he scope off this PP, any
y underlying software pproviding services
s
for code
c runninng in the devvice is considered part of the operating
systtem. Exampples of such services incclude: systeem initializaation
and boot, hardw ware abstracction layers, memory mmanagementt, mul-
th
4 Page 157
POI P
Protection Profile
Term Defifinition
titassking, synchhronization primitives, file systemms, device drrivers
and networkingg stacks. Serrvices that provide
p secuurity or mayy im-
pactt security arre, in additio
on, considerred firmwarre. Operatinng sys-
tems may rangee from hard dware abstraaction layer libraries an
nd em-
bedd ded micro-kkernels, to complex
c mu
ulti-user opeerating systeems.
OS
SeC Opeen Standardss for Securiity and certiification
PA
AN Prim
mary Accouunt Number
Payyment Ap- A paayment appplication is a particular type of Appplication, which
w
pliccation usess functions pprovided byy the core so
oftware of tthe POI to carry
c
out payment
p traansactions (and
( possiblly card mannagement fu unc-
tion
ns). The Payyment Appliication is exxcluded from m the TOE.
Payyment sys- Any
y system proocessing pay
yment transsaction dataa.
tem
m
Payyment The act betweeen a Cardhollder and a Merchant
M orr Acquirer th hat re-
trannsaction sultss in the exchhange of go
oods or serv
vices againstt payment. For the
purppose of this PP also thee process peerforming alll steps of a card
paymment relatedd to the POII.
Payyment Dataa that are innvolved in a payment trransaction.
trannsaction daa- Examples for ppayment tran nsaction datta are the am
mount, the curren-
c
ta cy, the
t date of tthe paymen nt transaction, cryptograam data, thee data
usedd to performm Dynamic Data Autheentication annd stored in n the
POII, any data w which is tran
nsferred bettween Issueer and IC caard as
card
d script proccessing and card manag gement, thee Transaction
Couunter and anny other pay yment transaaction data pprocessed by
b the
POII.
The Acquirer, tthe Cardhollder and the attended peerforms opeera-
tion
ns on the payyment transsaction data.
PC
CI Paym
ment Card IIndustry. Issuer of secu
urity requireements. Join
ntly
form
med by MassterCard, Viisa and otheer card paymment schemes.
PINN Entry De-- A deevice for seecure PIN en ntry and proocessing. Thhe PED typically
vicce (PED) conssists of a keeypad for PIIN entry, laiid out in a pprescribed format,
f
a dissplay for usser interactio
on, a Securiity Module consisting of a
proccessor and m memory perrforming cry yptographicc operationss with
cryp
ptographic kkeys on PIN Ns and firmw ware. A PED D has a cleaarly
defined physicaal and logiccal boundary y, and a tam
mper resistannt or
tamp per evident shell. The PED
P is a CH
HV.
Plaaintext PIN PIN
N which is alllowed to bee sent to thee IC card ass plaintext in
n order
to be verified bby the IC carrd.
PO
OI A POI is an eleectronic trannsaction accceptance prooduct. A POOI con-
sistss of hardwarre and softw
ware and is hosted in ann acceptancce
equiipment to ennable a Carrdholder to perform
p a caard transacttion.
th
4 6 March,
M 2015
POI P
Protection Profile
Term Defifinition
Thereby the PO OI may be attended
a or unattended.
u POI transaactions
are IC
I card bas ed paymentt transaction ns as well as any other pay-
men nt transactioons e.g. baseed on Magnnetic Stripe oor any non--
paym ment transaactions like health,
h loyaalty or gover
ernment. The TOE
is att minimum a POI exclu uding appliccations.
PO
OI compo- Any
y physical oor logical deevice involvved in a cardd payment at
a a
nennt POII (e.g. beepeer, Card Reaader, display, printer, PPED).
PO
OI manage- All PIN relatedd or security
y related datta used to m
manage and admin-
meent data isterr the POI. E
Examples foor POI Manaagement dat ata are the riisk
man nagement daata, POI Un nique Identiffier or the M
Merchant Id dentifi-
er. The
T Terminnal Administtrator performs operatiions on POII man-
agemment data.
PINN related daa- All items relateed to the pro
ocessing of a PIN, i.e. tthe PIN itseelf, the
ta PIN
N encryptionn keys, etc.
PP-Module See [PP Mod] ffor the defin
nition.
Priivate key That key of an entity’s asyymmetric keey pair that should only y be
used
d by that ent
ntity. In the case
c of a dig
gital signatuure scheme, the
priv
vate key defi
fines the signature function.
Pubblic key That key of an entity’s asyymmetric keey pair that can be mad de pub-
lic. In
I the case of a digital signature sccheme, the ppublic key defines
the verification
v n function.
Pubblic key cerr- The public key and identitty of an entity together with some other
tifiicate info
ormation, renndered unfo orgeable by signing witth the privaate key
of th
he certificattion authoritty that issueed that certiificate.
Proocessor Any
y organisatioon or systemm processinng card paym ment transacctions.
An entity
e operaating a data or host processing cenntre as agentt of an
Acq
quirer, Issueer or Merchaant to proceess card payyment transaactions.
Proompts Prom
mpts are thee text shown
n on the PED display.
Receipt A haard copy doocument reccording a paayment transsaction thatt took
placce at the PO
OI, with a deescription th
hat usually iincludes: daate,
Merrchant namee/location, primary
p account numbeer, amount, and
reference numbber.
Reconciliationn An exchange
e o f messages between twwo institutioons (Acquireer, Is-
suerr or their aggents) to reach agreemeent on financcial totals.
Retailer proto-- Prottocol used bbetween thee sale systemm (electronicc cash regisster,
coll vendding unit, seervice statio
on infrastruccture,..) andd the POI.
Reversal Can
ncellation off a previous transaction
n. There migght be manu
ual as
welll as automattic reversalss.
Seccret (cryp- A crryptographiic key used with symm metric cryptoographic tecch-
toggraphic) keyy niqu
ues and usabble only by a set of speecified entitiies.
th
4 Page 159
POI P
Protection Profile
Term Defi
finition
Sennsitive dataa Dataa that must be protected against un nauthorizedd disclosure, al-
terattion or destrruction, esp
pecially PIN
Ns and secreet and privatte
cryp
ptographic kkeys. Depen nding on thee context off the functio
onal re-
quirrement sens itive data may
m be restriicted to Plaiintext PIN or
o to
Ciphhertext PINN and to a su ubset of cryp
ptographic kkeys.
Sennsitive funcc- Sensitive functiions are tho
ose function
ns that proceess sensitivee data
tionns such
h as cryptoggraphic keyss or PINs.
Sennsitive ser- Sensitive servicces provide access to th
he underlyinng sensitivee func-
vicces tion
ns.
Sesssion key A keey establishhed by a keyy managemeent protocoll, which pro ovides
secu
urity servicees to data traansferred beetween the pparties. A single
s
prottocol executtion may establish multiple sessionn keys, e.g., an
encrryption key and a MAC C key.
Setttlement A trransfer of fuunds to com
mplete one or more prior
or transactions
madde, subject tto final acco
ounting and correspondding to reconcilia-
tion
n advices.
Scrript A co
ommand orr string of co ommands trransmitted bby the Issueer to the
term
minal for thee purpose off being sentt serially to the IC card
d.
Seccure Appli- See Security M
Module.
cattion Modulee
(SAAM)
Seccure soft- All software th at are involved in the secure
s handl
dling of IC card
c
waare paymment transaaction, i.e. PIN
P encryptiion, parameeter and soft
ftware
auth
hentication, card and transaction data protectioon, etc.
Seccurity Mod-- Anyy (physical oor logical) device
d that manages
m seecret cryptog
graphic
ulee (SM) keyss and cryptoographic fun nctions and performs ccryptograph hic op-
eratiions using kkeys that haave a justifieed level of pprotection (e.g. a
Harddware Secuurity Modules (HSM) or o an externaal Security Appli-
catio
on Module (SAM) for a purse app plication (PSSAM)).
Seccurity relat-- All items, otherr than PIN related
r data, related to security pro
otec-
ed data tion
n of the paym
ment transacction. E.g. critical
c paraameters, cry
ypto-
grap
phic keys, ettc.
SR
RED Secu
ure Read annd Exchange – A set off requiremennts protectio
on ac-
coun
nt data and account datta related crryptographicc data.
surrrogate PAN
N A vaalue derivedd from the PAN,
P that can be exporrted outsidee the
deviice, e.g. to uupdate a loy
yalty applicaation. Such surrogate PAN
P
can be obtainedd by differen nt methods:: encryptionn, cryptograaphic
hash
h (with salt)), mask, or truncation.
t
Tam mper- A ch
haracteristicc that provid
des passive physical prrotection ag
gainst
ressistant an attack.
a
th
4 6 March,
M 2015
POI P
Protection Profile
Term Defi
finition
Tam
mper- A ch
haracteristicc that provid
des an activ
ve response to the detecction of
Responsive an attack,
a thereeby preventiing a successs.
Terrminal A POI is a term
minal provid
ding a man-m
machine to a human viia dis-
play
y and keypaad.
Terrminal A sy
ystem used to administtrate (installlation, mainntenance) a set of
Maanagement POIIs. Used by a terminal manager.
m
Sysstem (TMS)
th
4 Page 161
POI P
Protection Profile
12 Defiinition of th
he SRED P
PP-Module
557 Thiss chapter coontains the definition
d off the SRED
D PP-Modulee.
558 As ddescribed inn section 2.1 the SRED D module can be added d to a base PP includin
ng either
the PED-ONLY Y configuraation or to the POI-CO OMPREHE ENSIVE connfiguration. During
the text in this chapter thiis configuraation is som
metimes callled the undderlying con
nfigura-
tion
n.
559 Notee: The secuurity properrties of thee SRED PPP-Module ov verlap withh those of the
t POI-
COM MPREHEN NSIVE co
onfigurationn. For example, the seecurity objective
o
O.PaymentTrannsaction is needed forr the SRED D PP-Modu ule and alsoo included in POI-
COM MPREHEN NSIVE, but not in PED D-ONLY. Thherefore thiis objectivee needs to be added,
if thhe underlyinng configurration is PE
ED-ONLY, but does no ot need to bbe added, iff the un-
derlying configguration is POI-COMP
P PREHENSIVE. We try y to expliciitly mention n similar
effects in the foollowing chapters.
12.1 Secu
urity Probllem Definittion
12.1.1 Asseets
560 The following assets
a are defined
d for tthe SRED PP-Module
P in
i addition to the assetts for the
undeerlying configuration.
561 PAY
Y_DAT { XE
X "PAY_D
DAT" }
562 Paym
ment transaaction data
563 Dataa related too the paymeent transactiion. It inclu
udes at leastt the amounnt, the Prim
mary Ac-
counnt Number (PAN), thee personal aaccount num mber, the cuurrency, thee date and time,
t the
encrrypted PIN (if transferrred online dduring the payment
p tran
nsaction), thhe transactiion iden-
tifieer of the paayment transaction, thee cryptogramm data, the Authorizattion Reply and any
dataa which is transferred
t between the Issuer and the IC Caard like carrd script processing
and card managgement dataa.
565 Appplication Noote:
566 The TOE ensurres protectio on of PAY__DAT insidee the devicee. Protectionn of PAY_DDAT that
are sent outsidde the device shall be iimplemented if requireed by the Accquirer, usiing TOE
secuurity servicees: The payyment appliication mayy use the TOE
T ty services to avoid
security
discclosure and modificatioon of PAY_D DAT when this data iss sent throug
ugh the onlinne inter-
facee.
567 Notee: This asseet is added, if the undeerlying conffiguration iss PED-only.. While thiss asset is
alreaady containned in the POI-COMPR
P REHENSIV VE configurration, its ddefinition iss slightly
exteended here and
a may theerefore replaace the asseet of the und derlying connfiguration.
568 PAN
N { XE "PA
AN" }
569 Prim
mary accounnt number
570 The primary acccount numbber is a partt of Paymen nt transactio
on data (PA
AY_DATA). PAN is
obtaained from IC
I Card or magnetic
m caard, and then has to be transmittedd to the acqu
uirer.
th
4 6 March,
M 2015
POI P
Protection Profile
571 PAN
N has three possible forrms in the T
TOE:
 TOE_C CLEAR_PAN N (cleartexxt PAN). cleeartext PAN N is either encrypted immedi-
ately uppon entry orr entered inn clear-text into the deevice and prrocessed within the
secure controller
c off the devicee.
 TOE_C CIPHER_PA AN (when ooperating in n encryptingg mode andd when the TOE in-
cludes several
s physsically separ
arate parts, PAN
P is ciph
hered by TS
SF for intern
nal trans-
fer)
 E2E_CIIPHER_PAN N (when ooperating in
n encrypting mode, thhe TSF cip
phers the
PAN for end-to-end
d protectionn)
572 It shhould be nooted that eveen in encryppting mode,, the PED still has the possibility to trans-
fer a cleartext version
v of the PAN to an authorizzed applicattion within tthe device (see
( PCI
K155.1)
573 Senssitivity: Auuthenticity and
a Integrityy (as any otther part of PAY_DAT
TA) and Con
nfidenti-
alityy.
574 TOE
E_CLEAR
R_PAN { XE
E "TOE_CL
LEAR_PAN
N" }
575 PAN
N in clear teext.
y, Authenticcity, and Inttegrity.
577 TOE
E_CIPHER
R_PAN { XE
X "TOE_C
CIPHER_PA
AN" }
578 In ddistributed POI
P architecctures, PAN
N ciphered for
fo internal TOE
T transm
mission
579 In ddistributed architecture
a s and whenn operating encrypting mode, the PAN has to be en-
o the PED, which thenn deciphers it before
cryppted by the Card Readeer prior to ssending it to
ciphhering it for the Acquirer.
582 "Disstributed arrchitecture"" has to be uunderstood as POI arcchitectures w
where the PED
P and
the Card Readder are sep parated deevices (i.e. not integraated into oone single tamper-
respponsive boundary).
583 In thhat case,
 the cardd reader trransforms T
TOE_CLEA
AR_PAN in
nto TOE_C
CIPHER_PA
AN, and
transmitts it to the PED
P
 the PED
D transformss TOE_CIP
PHER_PAN
N into TOE_
_CLEAR_PA
AN
 the PED
D transformss TOE_CLE
EAR_PAN into E2E_C
CIPHER_PA
AN
584 TOE
E_PAN_SK
K { XE "TO
OE_PAN_SK
K" }
585 Secrret/private PAN
P crypto
ographic keyys for intern
nal TOE tran
nsmission
th
4 Page 163
POI P
Protection Profile
586 All secret crypttographic keeys used to protect the confidentiaality of PAN
N, while tran
nsmitted
betw
ween physically-separaate parts oof the TOE E. Applicatiion of TOE E_PAN_SK K "trans-
form
ms" TOE_C CLEAR_PAN N into TOE E_CIPHER_ _PAN
589 Notee that privaate keys onlyy needed forr decryption
n, not for en
ncryption off PAN. Thiss asset is
releevant to disttributed PEDD architecttures, wheree the Card Reader
R is nnot in the sa
ame tam-
per--responsive enclosure asa the PED keypad.
590 E2E
E_CIPHER
R_PAN { XE
E "E2E_CIP
PHER_PAN
N" }
591 Encrypted PAN
N for end-to
o-end transm
mission
592 In eencrypting mode,
m the POI
P paymennt applicatio on requires sending thee encrypted
d PAN to
the AAcquirer viia the onlinee interface oof the POI.
594 E2E
E_PAN_PK
K { XE "E2E
E_PAN_PK
K" }
595 Public PAN cryyptographicc keys for ennd-to-end en
ncryption
596 All ppublic cryptographic keys
k used too protect thee confidentiaality of PAN
N.
598 E2E
E_PAN_SK
K { XE "E2E
E_PAN_SK
K" }
599 Privvate cryptoggraphic keyss for end-to--end encryp
ption
600 All private cryptograph
hic keys used to protect the confiddentiality of the
E2E
E_CIPHER__PAN.
603 Notee that prrivate keyss only nneeded forr decryptio
on, not fo
for encryp
ption of
E2E
E_CIPHER__PAN.
604 SUR
RROGATE
E_PAN { XE "SURRO
OGATE_PA
AN" }
605 Surrrogate PAN
N value
606 The TSF can generate
g a surrogate
s PA AN, that caan be exporrted outsidee the devicee, e.g. to
updaate a loyaltyy applicatio
on. Such surrrogate PANN can be obttained by diifferent metthods:
 encrryption
 crypptographic hash
h (with ssalt)
 mask
 trunncation
th
4 6 March,
M 2015
POI P
Protection Profile
608 SUR
RROGATE
E_PAN_SA
ALT { XE "S
SURROGA
ATE_PAN_SALT" }
609 Saltt used to gennerate a surrrogate PAN
N value
610 Wheen a cryptographic hassh is used too generate a surrogate PAN, TSFF must take a salt as
inpuut for the cryyptographicc hash.
611 Senssitivity: Authenticity, Integrity
I andd Confidenttiality.
12.1.2 Userrs / Subjectts
612 The SRED PP-Module doees not definne additionaal users or su

ubjects.
12.1.3 Thrreats
613 The SRED PP--Module deffines the thrreat T-Tran nsaction. If the
t underlyiing configu
uration is
PEDD-ONLY, thhis is an ad dditional thrreat, if it iss POI-COM MPREHENSSIVE, this is i an ex-
tendded version of an existiing threat.
614 T.T
Transaction
n { XE "T.Trransaction" }
615 Trannsaction witth usurped Cardholder
C identity
616 Edittion of T.Trransaction as
a defined inn PP POI - addition
a of the
t followinng examples:
dd) Fraudsterrs obtain kn nowledge off a legitimaate user's Priimary Accoount Numbeer during
transacttion, in ordeer to impers onate the usser in anoth
her transactiion.
ee) Fraudsterrs deduce a legitimate user's Prim mary Accou unt Numberr from the surrogate
s
PAN stoored by an application
a (such as loyyalty appliccation), in oorder to imp
personate
the userr in another transactionn.
12.1.4 Orgganisational Security P

Policies
617 The SRED PP-Module doees not definne additionaal Organisational Securrity Policies.
12.1.5 Assu
umptions
618 The SRED PP-Module doees not definne additionaal assumptio

ons.
12.2 Secu
urity Objecctives
12.2.1 Secuurity Objecctives for th
he TOE
619The SRED PP--Module inccludes the oobjectives O.PaymentT
O Transactionn, O.POI_S
SW, and
O.P POIApplicaationSepara
ation as deffined in secttion 6.1.
620 Notee: If the undderlying con
nfiguration is PED-ON NLY, these objectives aare added by
b claim-
ing the SRED PP-Modulee. In the casse of POI-C COMPREH HENSIVE, tthese objecttives are
alreaady includeed and do noot need to bbe added.
th
4 Page 165
POI P
Protection Profile
621 In addition, thee SRED PP--Module deffines the folllowing new
w objectivess.
622 O.PA
ANConfideentiality { XE
X "O.PANC
Confidentiaality" }
623 The TOE shall protect the confidentiaality of PAN
N when operrating in enncrypting mo
ode.
624 O.PA
ANDeductiion { XE "O
O.PANDeduuction" }
625 If thhe TOE enaables surrog
gate PAN vaalues to be outputted outside
o of thhe device, such
s val-
ues shall resist the deduction of the orriginal PAN
N knowing only
o the surrrogate value.
626 O.PA
ANOperatinngMode { XE
X "O.PAN
NOperatingM
Mode" }
627 The TSF shall allow
a the seelection andd update of the operatin
ng mode to authenticatted users
onlyy.
 operatinng mode deffines wheth er SRED fu unctionality is activatedd or not
 operatinng mode wiill be hereaf after describ bed by the two values "encrypting g mode"
and "noon-encryptin ng mode"
 if the opperating mode cannot bbe changed d at all (SRE ED functionnality is alw
ways ac-
tive), this objective is considerred triviallyy fulfilled.
12.2.2 Secu
he Operatio
onal Enviro
onment
629 The SRED PP--Module do

oes not definne addition
nal Security objectives for the Opeerational
Envvironment.
12.2.3 Secu
urity Objecctives Ratioonale
630
631 All objectives defined

d in this
t modulee are mappeed to T.Tran
nsaction andd the ration
nale is as
folloows:
632 T.T
Transaction
n Transaction with usurrped Cardho
older identitty
633 The SRED PP--Module add
ds the folloowing parag
graph to the rationale allready given
n in sec-
tionn 7.1:
O
O.PANConnfidentiality and O.PAN NDeduction n prevent atttacks usingg knowledgge of the
PAN, whether
w it iss obtained dduring the transaction
t or by deduuction from a surro-
gate vallue stored by y an externaal applicatio
on.
O
O.PANOpeeratingModee prevents attacks con nsisting in deactivating
d g the protection by
the TOEE.
12.3 Exteended Requ

uirements
634 The SRED PP-Module doees not definne additionaal extended requirement
r nts.
th
4 6 March,
M 2015
POI P
Protection Profile
12.4 Secu
urity Requirements
12.4.1 Secu
uirements
635 The SRED PP-Module deffines the folllowing pacckages of SF

FRs:
 Protectiion of the PAN
P ncryption is addressed bby the 'SRE
for endd-to-end en ED End-
to-end protection
p package'.
p
 The 'SR RED Distrib buted Archittecture Packkage' addresses the prootection of the
t PAN
when trransmitted within
w the T
TOE.
 Both paackages rely y on the 'SRRED Crypto ography package' to ennsure encip pherment
and deccipherment operations.
o
 Protectiion of the surrogate
s vvalues generrated from the PAN iis addressed d by the
'SRED Surrogate PANP Packagge'.
 The 'SR RED Basis Package'
P prrovides the common prrotection reequirementss such as
physicaal resistance
636 Appplication Nootes:
 Mappinng between SFRs and PCI requirrements: thee SFRs in tthese packa ages are
mappedd to the PC CI SRED reqquirements they impleement, eitheer in the texxt of the
SFR or in applicatiion notes, oor both: theyy are referenced with thhe "PCI" id dentifier.
 Mappinng between SARs and PCI requirrements: som me PCI seccurity requirements
have beeen identifieed not to bbe security functional ones. Thesse security require-
ments are
a introducced as refinnements off ADV_ARC C, AGD_OP PE, AGD_P PRE and
ALC_CMCMC.
 In the packages,
p Seecurity Funnction Policcies (SFP) are
a describeed. Each SF FP is as-
sociatedd to one package. Crypptography and a Physica al Protectioon Packagees do not
have ann associated
d policy.
 As in thhe PP POI, the definitiion of the diifferent entiities part off the SFPs has
h been
determiined in the following
f m anner:
 Subjjects are SP PD subjects (section 5.3 3) or SPD users
u (sectioon 5.2).
 Objects or information aree assets (secction 5.1).
 Secuurity attribuutes are prop
operties of assets
a or subbjects.
 Rolees are SPD users (sectiion 5.2).
637 The table hereaafter lists th

he SFR packkages in thee SRED PP-Module annd explains their re-
latioon to PP PO
OI and theirr usage in PPOI-COMP PREHENSIV VE or PEDD-ONLY co onfigura-
tionn.
th
4 Page 167
POI P
Protection Profile
Packagge SF
FR Usagge Comm
ments
FIIA_UID.1
FTTA_SSL.3
FIIA_UAU.2
FM
MT_MSA.1
FT
TP_ITC.1 Some ofo these SFRRs were built on the
FP
PT_FLS.1 This ppackage is al-
a
SRED BBasis model of their PIN_
N_ENTRY co ounter-
FP
PT_TST.1 wayss needed in thhe
Packagee part in PP POI, butt covering a different
d
FM
MT_SMR.1 SREDD PP-Modulle.
objectiive (PAN prootection).
FD
DP_ACF.1
FD
DP_ACC.1
FD
DP_ITC.1
FP
PT_EMSEC.1
FP
PT_PHP.3
These SFRs have oonly been deffined to
cover explicitly
e thee PCI SRED re-
This ppackage de-
quiremments, but usuually the PP POI
fines cryptograph hic
functioonality alreaddy covers thee security
primiitives needed d
FT
TP_ITC.1, needs. If the cryptoographic prim mitives
SRED C Cryp- for crryptographicc
FP
PT_TDC.1, used foor SRED aree the same as for the
tographhy functtions in the
FD
DP_ITC.2, POI fuunctions in thhe underlying g config-
Packagee otherr packages an nd
FC
CS_COP.1 urationn, these SFRss may be goo od can-
its fuunctionality is
didatess to remove tthem (only adding
a
there fore always
their reefinements anand applicatio
on notes
needeed.
to the correspondin
c ng SFRs in thhe under-
lying package,
p wheere applicablle).
FD
DP_IFC.1, This ppackage has to Definittion of INTE ER-
SRED D Dis-
FD
DP_IFF.1, be addded if the NAL_P PROTECTIO ON Informattion
tributedd Ar-
FD
DP_ITT.1, TOE E consists of Flow Control
C SFP : protection of the
chitectuure
FM
MT_MSA.1, severral physicallly- PAN when
w transmiitted betweenn sepa-
Packagee
FD
DP_RIP.1 separrated parts. rate paarts of the TOOE
FD
DP_IFC.1,
FD
DP_IFF.1,
FM
MT_MSA.1,
SRED E End-to- This ppackage has to Definittion of END__TO_END Infor-I
FM
MT_SMR.1,
end prootection be addded in any mationn Flow Contrrol SFP : protection
FIA
A_UID.1,
Packagee confiiguration of the PAN
P for endd-to-end transmission
FD
DP_RIP.1,
FD
DP_ITT.1,
FT
TP_TRP.1
This ppackage has to

SRED SSurro- CS_COP.1,
FC be addded if the Definittion of SURR ROGATE_P PAN In-
gate PA
AN FD
DP_IFC.1, TOE E enables thee formattion Flow Coontrol SFP : protec-
p
Packagee FD
DP_IFF.1 creattion of surro
o- tion off the surrogatte values of PAN
P
gate values for th
he
PANN
Table 17
7: SFR pack
kages in the SRED PP
P-Module
638 A geeneral note for all of th

he SRED SF
FRs:
th
4 6 March,
M 2015
POI P
Protection Profile
SSeveral of these
t SFRs are already contained in i a very sim
milar form iin the underrlying
cconfiguratioon from the POI PP, inn particular if
i the underlying configguration is POI-
P
CCOMPREH HENSIVE. This
T may leead to some redundanciies. Note thaat such redu undan-
moved" automatically during laterr evaluation
ccies are "rem n steps whenn mapping SFRs
S to
TTSFI duringg ADV_FSP P activities,, because id
dentical funcctionality w
will be mappped on
tthe same TS SFI. Therefo
fore these reedundanciess should hav ve no impacct on the TO OE de-
ssign and tessting docum
mentation, exxcept for soome mappin ng tables, whhich are lon
nger in
tthis case.
12.4.1.11 SRED Baasis Packag

ge
Note: T
The "dependdencies"-parrt of each SF FR is omittted in this chapter for bbrevity. All depend-
encies aare as definned in CC, Part 2, andd the rationaale for the dependenciies are conttained in
chapter 12.4.3.3.
FMT_S
SMR.1/SRE
ED Security
y roles
FMT_SSMR.1.1/SR RED The TSF

T shall mmaintain the roles [selecction: Term
minal Mana
agement
Systeem and/or Terminal Administra
A ator] and Risk
R Manag ger.
FMT_S
SMR.1.2/SR
RED The TSF
T shall bee able to associate userss with roles..
Applicaation Note:
 Terminaal Managem ment Systemm and/or Teerminal Adm ministrator is related tot status
of ENC__PIN_SK, TOE_PAN_
T _SK, E2E_P PAN_SK/E2E E_PAN_PK K
 Risk Maanager is reelated to staatus of ENC
C_PIN, E2E_ _CIPHER_P PAN.
 PCI K99: If the devvice may bee accessed remotely fo or the purpooses of adm ministra-
tion, alll access atteempts must be cryptogrraphically authenticate
a ed. If the au
uthentici-
ty of thee access req
quest canno t be confirm
med, the acccess requestt is denied.
FIA_UIID.1/SRED
D Timing off identificattion
FIA_UIID.1.1/SRE ED The TSF F shall alloow [assignm ment: list of o TSF-meediated actiions] on
behaalf of the useer to be perfformed befoore the userr is identified.
FIA_UIID.1.2/SRE ED The TSF F shall requuire each usser to be succcessfully iidentified before al-
lowinng any otheer TSF-mediated actionns on behalff of that userr.
Applicaation Note:
 The tim
ming of iden
ntification ffor actions is in partiicular relate
ted to the Terminal
T
Manageement System and/or T Terminal Ad dministrator and to the RRisk Managger.
th
4 Page 169
POI P
Protection Profile
 PCI K99: If the devvice may bee accessed remotely fo or the purpooses of adm ministra-
tion, alll access atteempts must be cryptogrraphically authenticate
a ed. If the au
uthentici-
ty of thee access req
quest canno t be confirm
med, the acccess requestt is denied.
{ XE "FD
DP_ITC.1/SRE
ED" }
FDP_IT
TC.1/SRED
D Import of user dataa without seecurity attrributes
FDP_IT TC.1.1/SRE ED The TSF F shall enfoorce the Ap

pplication Separation
S SFP when
n import-
ing uuser data, coontrolled un
nder the SFPP, from outsside of the TOE.
T
FDP_ITTC.1.2/SRE ED The TSF F shall ignoore any secu

urity attributtes associateed with the user da-
ta whhen importeed from outsside the TO
OE.
FDP_ITTC.1.3/SRE ED The TSF shall enfforce the fo ollowing ruules when im

importing user
u data
contrrolled underr the SFP frrom outside the TOE:
 PAN N encryptio on keys (TTOE_PAN_ _SK, E2E_P PAN_SK/E E2E_PAN_SK) are
storred in the CoreTSF
C (S
Security Mo odule of PE
ED) or encrrypted.
 the salt used to t generatee surrogatee PAN (SU URROGAT TE_PAN_SA ALT) is
storred by Midd dleTSF
 [asssignment: additional
a iimportation
n control ruules].
Applicaation Note:
 Note thaat the subjeects, objectss and opera

ations for th
he Applicatiion Separattion SFP
are defiined in FDP
P_ACC.1/SR RED.
 Contribbution to PC
CI K11.1, PC CI K12 as defined
d in [E
EPC B4].
{ XE "FP
PT_FLS.1/SRE
ED" }
FPT_FL
LS.1/SRED
D Failure with
w preservvation of seecure state
FPT_FL LS.1.1/SRE ED The TSF F shall presserve a secu

ure state wh
hen the folloowing typess of fail-
ures occur:
ffailure of TSF
T self-tesst
llogical anomalies of TSFT
[assignmen nt: list of ty
ypes of failu
ures in TSF F].
Applicaation Note:
 The "secure state" does not prrovide acceess to any PAN

PA value, P
PAN encryp
ption key
or any other
o TSF secret data.
CI K11.1, PCCI K13 as defined
d in [E
EPC B4].
{ XE "FIA
A_UAU.2/SR
RED" }
th
4 6 March,
M 2015
POI P
Protection Profile
FIA_UA
AU.2/SRED
D User authentication
n before an
ny action
FIA_UA AU.2.1/SRE ED The TSF shall requuire each usser to be succcessfully aauthenticateed before
allow
wing any othher TSF-meediated actioons on behaalf of that usser.
Refinnement:
The TSF shall require
r each
h user to be successfullly authenticated beforee allowing access
a to
sensiitive servicces on behalf of that useer.
Applicaation Note:
 Access to sensitivee services shhall be eitheer via dual control or resulting in n the de-
vice beiing unable to
t use previoously existing key data a.
 PCI K222: Access to sensitivee services requires autthenticationn. Sensitive services
providee access to the
t underlyying sensitivve functionss. Sensitive ffunctions are
a those
functionns that proccess sensitiive data su uch as cryptographic kkeys, accou unt data,
and passswords. En ntering or exxiting sensiitive servicees shall not reveal or otherwise
affect seensitive data
a.
 Loadingg of Firmwa are, Applicaation softw
ware and updates of theese two aree consid-
ered sennsitive. Theerefore this SFR impliees that theyy require auuthenticatio on. More
particullar updates need to prrovide autheenticity of th he updatedd code usingg crypto-
graphiccal means (ssee PCI K111.1, K12 as defined in [EPC [ B4]).
{ XE "FD
DP_ACC.1/SR
RED" }
FDP_A
ACC.1/SRE
ED Subset access
a contrrol
FDP_A
ACC.1.1/SRRED The TS SF shall enfforce the Appplication Separation
S SFP on
 subjects: POOI and its Payment
P A
Application Logic
 oobjects:
o Paymment Transaction Datta, POI Ma anagement Data, POII_SK, Carrdholder
comm municationn interface
o TOE__CLEAR_P PAN
o TOE__CIPHER_ _PAN and TOE_PAN N_SK
o E2E__CIPHER_ _PAN and E E2E_PAN_ _SK/E2E_P PAN_PK
o SURR ROGATE_ _PAN and S SURROGA ATE_PAN_ _SALT
o [assiggnment: listt of paymen nt applicattion interna
al data]
 ooperations: send, receive, access..
{ XE "FD
DP_ACF.1/SR
RED" }
FDP_A
ACF.1/SRED
D Security attribute b
based accesss control
FDP_AACF.1.1/SR RED The TS SF shall ennforce the Application

A n Separatiion SFP to
o objects
basedd on the following:
 subjects: PO OI and its Payment
P A
Application Logic
 oobjects:
th
4 Page 171
POI P
Protection Profile
 Payment Transaction
P n Data, PO OI Management Dataa, POI_SK K, Card-
h
holder comm munication n interface
 TOE_CLEA
T AR_PAN
 TOE_CIPH
T HER_PAN aand TOE_P PAN_SK
 E2E_CIPHE
E ER_PAN aand E2E_PAN_SK/E2 2E_PAN_P PK
 SURROGA
S ATE_PAN aand SURRO OGATE_P PAN_SALT T
 [aassignmentt: list of paayment app plication intternal dataa]
 security attribute of POI_SK: pu urpose and validity
 security atttribute of Payment
P TTransaction n Data, PO OI Managem ment Data
a: access
rright of Payyment Application and d authenticcity status
 security atttribute of TOE_PAN_
T _SK, E2E_ _PAN_SK, E2E_PAN__PK: purp pose and
vvalidity
 security attributee of TOE_CL LEAR_PAN N, TO
OE_CIPHER R_PAN,
EE2E_CIPHER_PAN, SURROG GATE_PAN N, SURRO OGATE_PA AN_SALT:: access
rright of Payyment Application
 [assignmentt: list of seccurity attriibutes].
ACF.1.2/SR
FDP_A RED The TS SF shall enfforce the folllowing rulees to determ
mine if an operation
o
amonng controlleed subjects and
a controllled objects is allowed:
 PCII K20: If th he device su upports mu ultiple app
plications, it must enfo
force the
sepaaration bettween appliications. Itt must not be possiblee that one applica-
tion
n interferess with or taampers witth another applicationn or the firmware
of thhe device including, b but not limmited to, mo odifying daata objects belong-
ing to another application n or the firrmware.
FDP_AACF.1.3/SR RED The TS SF shall expplicitly auth

horise accesss of subjeccts to objeccts based
on thhe followingg additional rules:
 POII Managem ment Data and Payment Transa action Dataa shall only y be ac-
ceptted if the data are autthentic.
 POII Managem ment Data and Payment Transa action Dataa are only allowed
to be
b accessed if Paymentt Applicatiion has acceess right too the data.
 [asssignment: rules,
r basedd on securrity attribu
utes, that eexplicitly au uthorise
acceess of subjeects to objeects].
FDP_AACF.1.4/SR RED The TS SF shall expplicitly den

ny access of subjects tto objects based
b on
the fo
following addditional rulles:
 POII Managem ment Data and Paym ment Transaction Datta shall nott be ac-
ceptted if the data are nott authentic..
 Thee POI does not send P OI_SK in cleartext
c to
o any externnal IT entitty.
 [asssignment: rules,
r baseed on securrity attribu utes, that eexplicitly deny
d in-
form
mation flow ws].
Applicaation Note:
th
4 6 March,
M 2015
POI P
Protection Profile
 PCI K220 requirem ment can aalso be covvered by exxtending thee original PP POI
FDP_ACC.1 and FDP_ACF.1
F 1 requiremeent to the new
n sensitivve assets defefined by
SRED PP-Module
P
 If the author
a of th
he ST has nno additiona al information flow coontrol SFP rules or
rules baased on secuurity attribuutes these pa
arts shall bee filled withh none.
{ XE "FT
TA_SSL.3/SRE
ED" }
FTA_SSL.3/SRED
D TSF-initiiated termiination
FTA_SSL.3.1/SRE ED The TSF shall term

minate an in
nteractive seession afterr a limited number
of acctions that can be performed andd after an imposed
i tim
me limit aftfter which the
t PED
is forrced to retu
urn to its normal
n mod 15
de .
Applicaation Note:
 PCI K223: To minim mize the rissks from unaauthorized use

u of sensiitive servicees, limits
on the number
n of actions
a that can be perf
rformed and d a time limiit shall be imposed,
i
after whhich the PEDD is forced to return to
o its normall mode.
{ XE "FP
PT_PHP.3/SRE
ED" }
FPT_PH
HP.3/SRED
D Resistancce to physiccal attack
FPT_PH
HP.3.1/SREED The TSF shall resisst the physical tamperring scenarrios
 PCI K11.1: Penetrration of th he IC Card d Reader too make anyy additions, substi-
tutions or modificcations to eiither the IC C Card Rea ader's harddware or so oftware,
in order to determ mine or mod dify any sensitive dataa.
 PCI K11.1: Insertiion of both h an IC carrd and any y other forreign object within
the card d insertion
n slot.
 PCI K11.1: Replaccement of tthe front an nd rear cassing, that sshall be con
nsidered
as part of any attaack scenariio.
 PCI A33: Operatiional or en nvironmenttal conditions that aare not witthin the
specifieed PED opeerating ran nge (e.g temmperature or operatiing voltage outside
the statte operatingg range).
 PCI K33: Penetration of the P PED to discclose the PAAN encrypttion keys.
 PCI K33.1: Unauth horized moodification or substitu ution of pubublic keys stored in
the devvice
 PCI K11.1: Additions, substiitutions, orr modificattions on M MSR that would
w al-
low dettermination n or modifiication of Magnetic
M Sttripe data
 PCI K11.1: If the MSR
M is parrt of an un
nattended devices,
d TSSF shall conntain an
anti-remmoval mechanism to protect against unauthorized reemoval and d/or un-
authoriized re-insttallation.
 [assignm ment: addiitional physsical tampeering scena arios]
15 "Normmal mode" meaans a mode, where

w use of seensitive functiions or servicees is not possiible without new au-
thenticatiion of the userr.
th
4 Page 173
POI P
Protection Profile
to thhe physicall boundary y of the CooreTSF by y respondin ng automatiically such that the
SFRss are alwayss enforced.
Refinnement:
The aautomatic response shaall ensure att least the fo
ollowing beehaviour:
 The PED uses tamper deetection and d response mechanism ms which cause the
PEDD to become immediattely inoperaable and ressults in thee automatic and im-
meddiate erasure of any seecret inform mation whicch may be stored in thet PED
(PA
AN, secret crryptographiic keys, saltt used to geenerate the surrogate PAN,
P ad-
ministration passwords, etcc.).
 The PED makees inaccessiible any PA AN value, secret
s or prrivate keys or other
PEDD secret infformation w when operattional or environmentaal condition ns occurs
that are not witthin the speecified PED D operating range (e.g. temperaturre or op-
eratiing voltage outside thee state operaating range).
Applicaation Note:
 If the auuthor of thee ST has noo additionall physical ta

ampering sccenarios filll the as-
signmennt with nonee
 Contribbution to PCCI K19
{ XE "FP
PT_EMSEC.1//SRED" }
FPT_EMSEC.1/SRED TOE Emanation

n
FPT_EMSEC.1.1//SRED Thee TOE shalll not emit

 PCII K3: soun nd, electro--magnetic emissions, power connsumption or any
otheer external characteriistic availab
ble for mon
nitoring,
in exxcess of non
ne enabling access to too PAN encrryption keyys and nonee.
FPT_EMSEC.1.2//SRED Thee TSF shall ensure all users are unable u to usse the follow
wing in-
terfacce
 PCII K3: soun nd, electro--magnetic emissions, power connsumption or any
otheer external characteriistic availab
ble for mon
nitoring,
to gaain access too PAN encrryption keyys and nonee.
Applicaation Note:
 Suppports PCI K3.

K Recall that the scoope of this SFR shall ccontain at least
l the
MSRR, IC Card Reader
R andd PAN encryyption moduule (PED Seecurity Moddule).
{ XE "FM
MT_MSA.1/SR
RED" }
th
4 6 March,
M 2015
POI P
Protection Profile
FMT_M
MSA.1/SRE
ED Manageement of seecurity attrributes
FMT_M MSA.1.1/SRRED The TSF T shall eenforce thee ENCRYP PTING_MO ODE Information
Floww Control SFP
S to restrrict the abiliity to modiify the securrity attributtes operatio
on mode
to Riisk Manageer.
Applicaation Note:
 operration modee (encryptinng / non-en ncrypting mode)

m may be modified d by the
Riskk Manager.
 PCII K15: Statuus of operatiion mode ha aving the vaalue "Encryypting modee" means
thatt the device’s encryptioon of accou unt data fun nctionality is enabled and op-
erattional.
 PCII K15: For devices
d thatt allow the modificatioon of Status of operatio on mode,
the change to "encrypting
" g mode" must result in the firmwaare revision number
channging and the
t device pproviding viisual indication of SRE ED enablem ment. The
channge to "nonn encryptingg mode" mu ust result in the firmwaare revision n number
reveerting and the
t device nno longer providing
p viisual indicaation of SREED ena-
blemment.
 PCII K15: If wh hitelist(s) arre utilized to
t exclude card
c data fr
from manda atory en-
crypption, the whitelist
w shaall be cryptoographicallyy authenticaated either prior to
beinng instantiatted in the deevice or beffore being utilized.
u
 Notee: enablemeent/disablem ment of "enncrypting mode" couldd have been n formal-
izedd via a FMT T_SMF reqquirement in nstead of FMT_MSA;
F current FMMT_MSA
wording has beeen retainedd because itt enables to define more re clearly the role of
the "encryptingg mode" seccurity attribu ute in the co
orrespondinng flow con ntrol pol-
iciess.
{ XE "FP
PT_TST.1/SRE
ED" }
FPT_TST.1/SRED
D TSF testiing
FPT_TST.1.1/SRE ED The TSFF shall run a suite of seelf tests at the

t conditioons
 starrt-up
 at leeast once per day
to deemonstrate the
t correct operation
o off
 the CoreTSF PED P (COR RE_SW and d CORE_H HW).
 the PEDMiddlleTSF.
FPT_TST.1.2/SRE ED The TSF F shall provvide authoriised users with

w the cappability to verify
v the
integgrity of [seleection: [asssignment: p parts of TSF data], TS SF data].
FPT_TST.1.3/SRE ED The TSF F shall provvide authoriised users with

w the cappability to verify
v the
integgrity of storred TSF exeecutable coode.
Applicaation Note:
th
4 Page 175
POI P
Protection Profile
Conntribution too PCI K11.1
1, PCI K12.
{ XE "FT
TP_ITC.1/SRE
ED" }
FTP_IT
TC.1/SRED
D Inter-TSF
F trusted ch
hannel
FTP_ITTC.1.1/SRE ED The TSF F shall provvide a comm munication channel bettween itselff and an-
otherr trusted IT hat is logicaally distinct from otherr communiccation chan
T product th nnels and
proviides assured identificaation of its end points and protecction of thee channel daata from
modiification or disclosure.
FTP_ITTC.1.2/SRE ED The TSF

F shall permmit [selectiion: the TS
SF, anotherr trusted IT prod-
uct] to initiate communicat
c tion via the trusted channnel.
FTP_ITTC.1.3/SRE ED The TSF unication viia the trusteed channel for [as-
F shall inittiate commu
signm
ment: list of
o functionss for which
h a trusted channel
c is required].
r
Applicaation Note:
PCII K6: The deevice supports data oriigin authenttication of encrypted

e m
messages.
12.4.1.22 SRED Crryptograph

hy Package
This paackage definnes cryptog

graphy requuirements reelated to PC CI K4, PCII K5, PCI K17
K and
PCI K18requiremeents. They are built on ttheir counteerparts in PP
P POI:
FTP
P_ITC.1 Inteer-TSF trusted channell
FPT
T_TDC.1 Innter-TSF bassic TSF dataa consistenccy
FDP
P_ITC.2 Im
mport of userr data with ssecurity attrributes
FCS
S_COP.1 Crryptographiic operationn
{ XE "FT
TP_ITC.1/SRE
ED_CRYPTO
O" }
th
4 6 March,
M 2015
POI P
Protection Profile
FTP_IT
TC.1/SRED
D_CRYPTO
O Inter-TS
SF trusted channel
c
FTP_IT TC.1.1/SRE ED_CRYPT TO The TS SF shall pro ovide a com

mmunicatioon channel between
itselff and anothher trusted IT
I product that is logiically distinnct from oth ther commu unication
channnels and provides assu ured identifiication of its end pointss and protecction of the channel
data from modiffication or disclosure.
d
FTP_ITTC.1.2/SREED_CRYPT TO The TSSF shall perm mit [selection: the TSSF, anotherr trusted
IT product] to initiate
i com
mmunicationn via the tru
usted channeel.
FTP_ITTC.1.3/SRE ED_CRYPT TO The TS SF shall inittiate commuunication viia the trusteed chan-
nel fo
for importin
ng cryptogrraphic keyss includingg E2E_CIPH HER_PK/E E2E_CIPH HER_SK
and TOE_CIPH HER_SK, [assignmen nt: list of fu
unctions fo
or which a trusted ch hannel is
requuired].
Applicaation Note:
 If the author of thee ST has noo list of fun

nctions the assignment
a shall be fillled with
none.
 this SF FR is rellated to the imporrt of keyss for the encipherm ment of
E2E_CIIPHER_PAN N (in orderr to be trannsmitted to the acquireer) as well as enci-
phermennt of TOE_ _CIPHER_P PAN (in ord der to be traansmitted bbetween parrts of the
TOE) annd decipherrment of TO OE_CIPHER R_PAN by thet PED SM M.
 PCI K55: If remote key distribuution is useed, the devicce supports mutual autthentica-
tion bettween the seending key ddistribution host and reeceiving devvice.
 Contribbution to PCCI K4 and KK17.
{ XE "FP
PT_TDC.1/SR
RED_CRYPTO
O" }
FPT_TDC.1/SRED
D_CRYPT
TO Inter-TS
SF basic TS
SF data con
nsistency
FPT_TDC.1.1/SR RED_CRYP PTO The TS SF shall prrovide the capability

c too consistenttly inter-
pret cryptograaphic key ys includiing E2E_ _CIPHER_PK/E2E_C CIPHER_SK and
TOE E_CIPHER R_SK key derivation
d methodolo ogy or an equivalentt methodollogy for
mainntaining th
he TDEA KeyK Bundlee, and [asssignment: list l of TSF F data typees] when
shareed between the TSF and another trrusted IT prroduct.
FPT_TDC.1.2/SR RED_CRYP PTO The T TSF shall usse ISO 115 568 and/orr ANSI X9 9.24 and
ANSSI TR-31 orr an equiva
alent methoodology [asssignment: list of interrpretation rules to
be ap
pplied by the TSF] wh
hen interpreeting the TS
SF data from
m another tru
rusted IT pro
oduct.
Applicaation Note:
 If the author of thee ST has noo list of intterpretation rules the aassignment shall be
filled wiith none.
 In a disstributed ennvironment,, a TOE maym need to exchange TSF data (e.g. the
SFP-atttributes associated witth cryptogra aphic keys) with anothher trusted IT
I prod-
uct, Thiis family deffines the reequirementss for sharing
g and consiistent interp
pretation
th
4 Page 177
POI P
Protection Profile
of thesee attributes between thee TSF of the TOE and a different trusted IT product.
p
If no suuch data typpes and rulles exist thee ST authorr shall fill th
the assignm
ment with
none.
 this SF FR is rellated to the imporrt of keyss for the encipherm ment of
TOE_CLCLEAR_PAN N into TOE__CIPHER_P _PAN as well as E2E_C CIPHER_P PAN, and
decipheerment of TO OE_CIPHE ER_PAN by the PED SM M.
 Contribbution to PCCI K4 and KK17.
{ XE "FD
DP_ITC.2/SRE
ED_CRYPTO
O" }
FDP_IT
TC.2/SRED
D_CRYPTO
O Import oof user data
a with security attribuutes
FDP_ITTC.2.1/SRE ED_CRYPT TO The TS SF shall en

nforce the [assignmennt: access control
SFP((s) and/or informatio on flow con mporting usser data, co
ntrol SFP((s)] when im ontrolled
undeer the SFP, from
f outside of the TO
OE.
FDP_ITTC.2.2/SRE ED_CRYPT
TO The TS
SF shall use the security
impoorted user daata.
FDP_IT
TC.2.3/SRE ED_CRYPT TO The TS SF shall ensu ure that the protocol ussed providees for the
unam
mbiguous asssociation between the security atttributes and the user daata received.
FDP_IT TC.2.4/SRE ED_CRYPT TO The TS SF shall enssure that interpretationn of the seccurity at-
tribuutes of the im
mported useer data is as intended by
y the sourcee of the userr data.
FDP_IT TC.2.5/SRE ED_CRYPT TO The TS

SF shall enfforce the fo
ollowing rulles when im
mporting
user data controolled under the
t SFP from
m outside th
he TOE: ISSO 11568 annd/or ANSI X9.24,
suppporting the ANSI TR--31 key derrivation meethodology or an equiivalent metthodolo-
gy foor maintainning the TDDEA Key BBundle.
Applicaation Note:
 This SFR
S is reelated to the imporrt of keyss for the encipherm ment of
E2E_CIIPHER_PAN N (in orderr to be trannsmitted to the acquireer) as well as enci-
phermennt of TOE_ _CIPHER_P PAN (in ord der to be traansmitted bbetween parrts of the
TOE) and
a decipheerment of T TOE_CIPHE HER_PAN in nto TOE_CL CLEAR_PAN N by the
PED SM M.
 The autthor of the Security
S Taarget shall iterate
i this SFR for eacch TSF parrt, which
needs FCS_COP.1
F /SRED_CR RYPTO (see the applica ation notes ffor that SFR
R) in the
context of one of the SRED-P Packages. In FDP_IT TC.2.1/SRED D_CRYPTO O the ST
author shall
s assign
n the SFP reelated to tha
at SRED package.
CI K4 and KK17.
{ XE "FC
CS_COP.1/SR
RED_CRYPTO
O" }
th
4 6 March,
M 2015
POI P
Protection Profile
FCS_C
COP.1/SRED
D_CRYPT
TO Cryptoggraphic opeeration
FCS_CCOP.1.1/SR RED_CRYP PTO The T TSF shall perform

p encciphermentnt/deciphermment of
PANN in accordance with a specified cryptograp phic algorith
hm [selectiion: crypto
ographic
algorrithm] and cryptograp
phic key siz es [assignm
ment: crypttographic kkey sizes] th
hat meet
the fo
following: ANSI
A X9 orr ISO-apprroved encry yption algorrithms (e.gg., AES, TD
DES).
Applicaation Note:
 The author of thhe Security Target sha ll iterate this SFR for each
e TSF paart if necesssary.
 Thiss SFR is related to thee encipherm ment of TOE E_CLEAR_PAN into E E2E_CIPHE ER_PAN
(in oorder to be transmitted
d to the acquuirer) as weell as TOE__CIPHER_P PAN (in ordder to be
trannsmitted bettween partss of the TOE E) and deccipherment of TOE_CIP IPHER_PAN N by the
PED D SM.
 PCII K18: The following
f are
a examplees of techniiques that may m be usedd to preven nt an ex-
hausstive PAN determinati
d on attack, ssuch as onee producing g random trransactions through
the device untiil the cipherrtext produuced equals the ciphertext recorde ded when the device
was in operatioonal use:
o Use of a unique keyy per transaaction techn nique. (Prevvents the atttack.)
o Limitingg the rate at
a which thee device will encrypt PANs.
P (Deteers the atta
ack.) For
examplee, the funcction wouldd be a maxximum of the t throughhput that could
c be
achieveed through the physicall interface during
d intended usage.
 Conntribution too K4
12.4.1.33 SRED Distributed Architectur
A re Package
639 Thiss package addresses

a th
he need for pprotection of
o the PAN when the T
TOE is operrating as
distrributed archhitecture
640 "Disstributed architecture" has here too be understood as POI architectuures where the
t PED
and the Card Reader
R are separated devices (i.ee. not integ
grated into one single tamper-
respponsive boundary).
641 If thhe TOE is operating
o in
n encryptingg mode, the cleartext PAN
P (TOE__CLEAR_PAN) has
to bbe ciphered (TOE_CIPH HER_PAN)) by the Caard Reader prior
p to sennding it to the PED,
whicch then deciphers it before cipheriing it again (E2E_CIPH
HER_PAN)) for the Acquirer.
642 Thiss package iss not requireed if the TO
OE has an in
ntegrated architecture.
{ XE "FD
DP_IFC.1/SRE
ED_INT" }
FDP_IF
FC.1/SRED
D_INT Subset informaation flow control
c
FDP_IF
FC.1.1/SRE ED_INT Th he TSF shaall enforce the
t INTER
RNAL_PRO
OTECTION N Infor-
matiion Flow Control SFPP on
 subjjects: MSRR, IC Card Reader
 infoormation: TOE_CLEA
T AR_PAN, TOE_CIPH
T HER_PAN,, TOE_PAN
N_SK
 operrations: send (TOE_CL LEAR_PAN
N, TOE
E_CIPHERR_PAN),
send
d/receive (T
TOE_PAN__SK).
{ XE "FD
DP_IFF.1/SRE
ED_INT" }
th
4 Page 179
POI P
Protection Profile
FDP_IF
FF.1/SRED
D_INT Simp
ple securityy attributess
FDP_IF FF.1.1/SRE ED_INT Thhe TSF shalll enforce the

t INTER RNAL_PRO OTECTION N Infor-
matiion Flow Control SFP P based on tthe followin
ng types of subject
s and information
n securi-
ty atttributes:
 subjjects: MSR
R, IC Card Reader
 infoormation: TOE_CLEA
T AR_PAN, TOE_CIPH
T HER_PAN,, TOE_PAN N_SK
 status of TOE_ _PAN_SK:: validity, purpose
p
 operration modde of the PEED: encryp pting, non encryptingg [assignmeent: oth-
er TOE_PAN_
T _SK securitty attributees].
FDP_IFFF.1.2/SRE ED_INT Th he TSF shalll permit an n information flow beetween a co ontrolled

owing rules hold:
subjeect and conttrolled inforrmation via a controlled operation if the follow
 PCII K1: TOE E_CLEAR__PAN is eitther encryp pted immeddiately upo on entry
or entered
e in clear-text into the device
d and processed within thee secure
conttroller of th
he device.
 Thee IC Card Reader aand MSR may m send TOE_CIPH HER_PAN N to the
PEDD.
FDP_IFFF.1.3/SREED_INT Th he TSF shalll enforce th

he [assignm
ment: addittional information
flow control SF
FP rules].
FDP_IF FF.1.4/SRE ED_INT Th he TSF shalll explicitly

y authorise an informaation flow based
b on
the ffollowing ruules: [assign
nment: rulees, based ono security attributes,, that expliccitly au-
thoriise informaation flows]].
FDP_IF FF.1.5/SREED_INT Th he TSF shalll explicitlyy deny an informationn flow based d on the
following rules:
 Thee IC Card Reader an nd MSR do d not send or receivve TOE_P PAN_SK
to/frrom any suubject.
 Thee IC Card Reader an nd MSR do o not send
d TOE_CLE EAR_PAN N to any
subjject.
 Thee IC Card Reader an nd MSR do o not send TOE_CIP PHER_PAN N to any
otheer subject than
t the PEED.
 PCII K18: The device hass characterristics that prevent
p or significanttly deter
the use of the device
d for eexhaustive PAN deterrmination.
 PCII K8: Encrryption or decryption n of any arbitrary
a ddata using any ac-
coun nt data-enccrypting keey or key-encrypting keyk containned in the device
d is
not permitted d. The devvice must enforce th hat accounnt data key ys, key-
enciipherment keys, and P PIN-encryp ption keys have
h differrent values..
 PCII K15: When operatin ng in encryypting modde, there iss no mecha anism in
the IC Card Reader,
R MS SR or PED D that wou uld allow thhe outputting of a
privvate or secrret cleartexxt key or cleartext PA
AN, the encrryption of a key or
PAN N under a key that might itself be discclosed, or the transffer of a
cleaartext key from
f a com
mponent of high
h securiity into a coomponent ofo lesser
secuurity.
th
4 6 March,
M 2015
Protection Profile
POI P
Applicaation Note:
 Conntribution too PCI K15: When operrating in en ncrypting mode, there iis no mecha anism in
the IIC Card Reeader, MSR R or PED thhat would allow
a the ou
utputting off a private or
o secret
cleaartext key orr cleartext PAN,
P the enncryption off a key or PAN
P under a key that might
m it-
selff be discloseed, or the transfer of a cleartext keey from a component oof high secu urity into
a coomponent off lesser secu urity.
 If thhe author ofo the ST hash no addiitional inforrmation flo ow control SSFP rules or rules
baseed on security attributees these parrts shall be filled
f with none.
n
 Valiidity and puurpose are security
s attrributes whicch are only implicitly us
used in the rules.
r
 PCII K8: this PC CI requiremment is proccessed the saame mannerr as PCI B113 in the PP P POI.
 PCII K18: this PCI
P requireement is proocessed the same s manner as PCI B B10 in the PP
P POI.
 PAN N encryptionn keys (TOE E_PAN_SK) K) are stored d in the Secuurity Modulle of the commponent
or eencrypted.
{ XE "FD
DP_ITT.1/SRE
ED_INT" }
FDP_IT
TT.1/SRED
D_INT Basiic internal transfer prrotection
FDP_IT TT.1.1/SRE ED_INT Th he TSF shaall enforce the

t INTER RNAL_PRO OTECTION N Infor-
matiion Flow Control
C SFPP to preventt the disclossure and modification
m n of user daata when
it is ttransmitted between ph
hysically-seeparated parrts of the TO
OE.
Applicaation Note:
The phyysical separration of com

mponents haas to be undderstood in terms of
 physsically-sepa arated partss of the PED
D or
 betw ween the Ca ard Reader ((either IC Card
C Readerr or MSR) aand PED.
{ XE "FM
MT_MSA.3/SR
RED_INT" }{ XE
X "FMT_MS
SA.1/SRED_IINT" }
FMT_M
MSA.1/SRE
ED_INT Management
M t of securitty attributees
FMT_M MSA.1.1/SR RED_INT The

T TSF shhall enforce the INTE ERNAL_P PROTECTIION In-
form
mation Flow w Control SFP
S to restrrict the abiliity to modiffy the securrity attributees status
of TOE_PAN__SK to [seleection: Terrminal Man nagement System
S andd/or Termiinal Ad-
miniistrator].
{ XE "FD
DP_RIP.1/SRE
ED_INT" }
FDP_R
RIP.1/SRED
D_INT Subset residuaal information protecttion
FDP_RRIP.1.1/SRE ED_INT Th he TSF shalll ensure th

hat any prev
vious inform
mation conttent of a
resouurce is madde unavailab
ble upon thhe deallocattion of the resource ffrom the foollowing
objeccts:
o TOE_C CLEAR_PA AN imm mediately after being ciphered into
TOE_CCIPHER_P PAN by IC Card Read der or MSR R
th
4 Page 181
POI P
Protection Profile
o TOE_C CIPHER_P PAN immed diately afteer being seent to the PED by IC Card
Readerr or MSR
o TOE_P PAN_SK im mmediatelyy after bein ng used to
o cipher TO OE_CLEA AR_PAN
into TO
OE_CIPHE ER_PAN byy IC Card Reader orr MSR [asssignment: sensitives
objects with residual inform
mation].
Refinnement:
o These deallocatio ons are peerformed by b the Carrd Readerr (either IC C Card
Readerr or encryppting MSR)). Dealloca ation by thee PED upoon receptio on is ad-
dressed
d in the Endd-to-end prrotection Package.
o Dealloccation may occur upoon completiion of the transaction
t n or if the MSR
M or
IC Card Reader has
h timed-oout waiting from the Cardholder
C r or Merch hant.
Applicaation Note:
 Conntribution too PCI K15.2 2: Account ddata (in eith

her clear-text or encryppted form) shall
s not
be rretained anyy longer, or used more often, than strictly neccessary.
 The IC Card Reader
R or MSR
M must aautomaticallly clear itss internal bbuffers when n either:
The transactionn is compleeted, or the IC Card ReaderR or MSR
M has tim med-out waaiting for
the rresponse froom the Card dholder or MMerchant.
 If noo other senssitive objeccts with resiidual inform
mation existt the assignnment shall be filled
withh none.
12.4.1.44 SRED En nd-to-end protection

p P
Package
643 Thiss package addresses
a th
he supplemeentary need d for protecttion of the PPAN in thee context
of eend-to-end encryption between tthe POI an nd the Acquirer, also called "en ncrypting
modde" in PCI SRED
S requiirements. It introduces
 the aassets E2E__CIPHER_P PAN, E2E__PAN_SK an nd E2E_PAAN_PK, whiich are the PAN
P en-
cryppted for trannsmission to
o the acquirrer, and the correspondding keys
 the aassets Ciphhertext TOEE_CLEAR_P PAN, TOE_C CIPHER_P PAN, TOE_P PAN_SK, which
w are
the PPAN in cleaartext or cip
phertext recceived by thee PED, and
d the correspponding keyy.
644 Notee: The cleaartext TOE_ _CLEAR_PA AN can alsso be transm
mitted by thhe PED, butt only to
authhenticated appplications within the ddevice.
{ XE "FD
DP_IFC.1/SRE
ED_E2E" }
FDP_IF
FC.1/SRED
D_E2E Sub
bset inform ation flow control
FDP_IF
FC.1.1/SRE ED_E2E Th he TSF shaall enforce the END_ _TO_END Informatio on Flow
Conttrol SFP onn
o subjectts: PED (in n the sensee of the tam
mper respo
onsive TOE
E part resp
ponsible
for protection of the
t PAN)
o informaation: E2E_PAN_SK,, E2E_PAN N_PK
o operatiions: receiv ve
o informaation: E2E_CIPHER__PAN
o operatiions: send.
o informaation: TOE E_CIPHER R_PAN, TO OE_CLEAR R_PAN, TOOE_PAN_S SK
o operatiions: receiv ve.
th
4 6 March,
M 2015
POI P
Protection Profile
{ XE "FD
DP_IFF.1/SRE
ED_E2E" }
FDP_IF
FF.1/SRED
D_E2E Simple securityy attributes
FDP_IF
FF.1.1/SRE ED_E2E Th he TSF shaall enforce the END_TO_END Informatio on Flow
Conttrol SFP baased on the following tyypes of subj
bject and infformation seecurity attributes:
o subjectts: PED (in n the sensee of the tammper respo onsive TOE E part resp ponsible
for protection of the
t PAN)
o informaation: E2E_CIPHER__PAN, E2E E_PAN_SK K/E2E_PAN N_PK
o status of
o E2E_PAN_SK/E2E E_PAN_PK K: validity, purpose
p
o operatiion mode off the PED: encrypting g, non encrrypting
o informaation: TOE E_CIPHER R_PAN, TO OE_CLEAR R_PAN, TO OE_PAN_S SK
o status of
o TOE_PA AN_SK: vallidity, purp pose
o operatiion mode off the PED: encrypting g, non encrrypting
o [assignm ment: other E2E_PAN N_SK/E2E E_PAN_PK K security atttributes].
FDP_IFFF.1.2/SRE ED_E2E Th he TSF shaall permit an n informatiion flow beetween a co ontrolled

owing rules hold:
subjeect and conttrolled inforrmation via a controlled operation if the follow
o PCI K11: TOE_CL LEAR_PAN AN is eitherr encrypted d immediattely upon entrye or
entered d in clear-text into thee device an
nd processeed within tthe secure control-
ler of th
he device.
o PCI K115.1: The PED P can trransfer a cleartext
c TOE_CLEA AR_PAN to o an au-
thenticaated appliccation withiin the devicce.
o The PE ED can receive TOE__CIPHER_ _PAN from m the Card Reader. The T PED
decipheers TOE_C CIPHER_P PAN into TOE_CLEA
T AR_PAN w with the ap ppropri-
ate deddicated key immediateely after it is is received from Caard Readerr (either
IC Card Reader or o MSR).
o The PE ED can receeive TOE_C CLEAR_PA AN from th he Card Reeader.
o If the operating
o mode
m is "encrypting" the
t PED en nciphers TO OE_CLEA AR_PAN
with the appropriiate dedicatted keybefo ore it is sen
nt to externnal entities.
o FDP_IF FF.1.3/SRE ED_E2E Th he TSF sha all enforce the [assiggnment: ad dditional
informaation flow control
c SFPP rules].
FDP_IF FF.1.4/SRE ED_E2E Th he TSF shalll explicitly

y authorise an informaation flow based
b on
the ffollowing ruules: [assign
nment: rulees, based on
o security attributes,, that expliccitly au-
thoriise informaation flows]].
FDP_IF FF.1.5/SREED_E2E Th y deny an informationn flow based

he TSF shalll explicitly d on the
following rules:
o PCI K55: The PED D do not reeceive E2E E_PAN_SK K or E2E_P PAN_PK frrom any
other suubject than
n an authen
nticated key y distributiion host.
o PCI K115.1: If the operating mode is "encrypting g" the PED D does not send
s the
TOE_C CLEAR_PA AN to any other subject than an a authentticated app plication
within the
t device
o The PE ED does nott send E2E__PAN_SK to any subject beforee being encrrypted.
o The PE ED does nott accept a T
TOE_CLEA AR_PAN or o TOE_CIIPHER_PA AN from
any othher subject than the C
Card Readeer (either ICC Card Reaader or MS SR).
th
4 Page 183
POI P
Protection Profile
o PCI K118: The deevice has ccharacteristtics that prevent or significantly deter
the use of the deviice for exhaaustive PAN N determinnation.
o PCI K88: Encrypttion or deccryption off any arbitrrary data uusing any account
data-enncrypting key
k or keyy-encryptin ng key con ntained in the devicee is not
permittted. The deevice must enforce tha at account data keys, key-enciph herment
keys, an
nd PIN-enccryption keeys have diffferent valu ues.
o PCI K115: there is no mechan nism in thee device tha
at would allllow the outtputting
of clearr-text acco
ount data, which has been enteered in opeerating mo ode "en-
cryptin
ng". Chang ging betweeen an encry ypting and non-encryypting mod de of op-
eration
n requires explicit
e authhentication
n.
Applicaation Note:
 If thhe author of
o the ST has h no addiitional inforrmation flo ow control SSFP rules or rules
f with none.
n
s attrributes whicch are only implicitly us
used in the rules.
r
 Thiss SFR forcees the enciph herment of TOE_CLEA AR_PAN. The
Th encipherring must bee unique
to thhe transactiion, e.g. it iss not alloweed to producce the samee encipheredd form for a PAN in
diffeerent trannsactions to avoidd recognittion of PAN valuues. Addiitionally,
TOE E_CLEAR_P PAN is only ly allowed tto be encip phered with cryptograpphic keys only used
for PPAN enciphherment an nd not usedd for any otther purposse. The SFR R enforces that any
ENC C_PAN_PK K is different from any other crypttographic keey. Howeveer accidenta al choice
of thhe same vallue is alloweed.
 PCII K8: this PC CI requirem ment is proccessed the sa ame mannerr as PCI B113 in the PP P POI.
 PCII K18: this PCI
P requireement is proocessed the same s manner as PCI B B10 in the PP
P POI.
 PCII K15: Withhin the fram me of END__TO_END Information
I n Flow Con trol SFP (i.e. when
operrating in enncrypting mode),
m theree is no mech hanism in thhe device thhat would allow
a the
outpputting of cllear-text acccount data.
 secrret parts off the PAN encryption
e kkeys (E2E_P PAN_SK) are
a only stoored in the Security
Moddule of PED D or encryptted.
{ XE "FM
MT_MSA.3/SR
RED_E2E" }{{ XE "FMT_M
MSA.1/SRED_E2E" }
FMT_M
MSA.1/SRE
ED_E2E Managemen
M nt of securitty attributees
FMT_MMSA.1.1/SR RED_E2E The

T TSF shhall enforcee the END_
_TO_END Informatioon Flow
Conttrol SFP to restrict the aability to modify the securrity attribu utes of
E2E__CIPHER__PAN - and d of E2E_P PAN_SK/E22E_PAN_P PK
to R
Risk Managger - and [selection:
[ Terminal Managemeent System
m and/or Terminal
T
Admministrator]].
Applicaation Note:
 Stattus of E2E_C
CIPHER_P PAN may bee modified by the Risk Manager.
M
 Stattus of E2E_P
PAN_SK/E2 2E_PAN_P
PK may be modified
m by Terminal M
Managemen
nt System
and//or Terminaal Administrrator.
{ XE "FIA
A_UID.1/SRE
ED_E2E" }
th
4 6 March,
M 2015
POI P
Protection Profile
FIA_UIID.1/SRED
D_E2E Tim
ming of iden
ntification
FIA_UIID.1.1/SRE ED_E2E Th he TSF shalll allow [asssignment: list

l of TSF--mediated actions]
on beehalf of the user to be performed
p bbefore the user
u is identiified.
FIA_UIID.1.2/SRE ED_E2E Th he TSF shalll require each user to be successsfully identiified be-
fore allowing anny other TSF
F-mediatedd actions on behalf of th
hat user.
Applicaation Note:
 The timing of iddentification for actionns is related

d to Terminal Managem
ment System
m and/or
Term
minal Administrator an nd to the Rissk Managerr.
{ XE "FD
DP_RIP.1/SRE
ED_E2E" }
FDP_R
RIP.1/SRED
D_E2E Sub
bset residuaal informattion protecttion
FDP_RRIP.1.1/SRE ED_E2E Th he TSF shaall ensure thhat any prev

vious inform mation conttent of a
resouurce is made unavailabble upon thee [selection: allocation
n of the res ource to, dealloca-
d
tion of the resource from] the followiing objects:: [assignmeent: list of oobjects].
Refinnement:
The TSF shall ensure
e that any
a previouus informatiion content of a resourrce is made unavail-
able upon the deeallocation of the resoource from the followiing objects:
o TOE_C CIPHER_P PAN immmediately after being ddeciphered
d into
TOE_C CLEAR_PA AN,
o TOE_C CLEAR_PA AN immmediately after being eenciphered into
E2E_CIPHER_PA AN,
o temporrary crypto ographic keeys
o [assignm ment: sensiitive objectts with resiidual inform
mation].
Dealllocation may
m occur uponu complletion of thhe transactiion or if thhe IC Card Reader
or M
MSR has tim med-out wa aiting from the Cardh holder or merchant.
m
Applicaation Note:
 PCII K15.2: Acccount data (in either cllear-text or encrypted form)

f shall not be retained any
n, than stricttly necessarry.
longger, or usedd more often
 If thhe PED an nd Card Rea ader (either
er MSR or IC I Card Reeader) are integrated into the
samme tamperr-responsivve boundaary, TOE E_CLEAR_P PAN is enciphereed into
E2EE_CIPHER__PAN by thee SM of the PED immeediately afteer their recep eption.
 If th
he PED andd Card Rea ader (eitherr encrypting g MSR or IC
I Card Reeader) are notn inte-
gratted into thee same tamp per-responssive bound dary, then th
he TOE_CLLEAR_PAN N is enci-
pherred within the SM of the Card R Reader (eithher IC Carrd Reader oor encryptiing MSR
headd) immediaately after reception.
r T
TOE_CIPHE ER_PAN is sent to thee PED, whiich shall
deciipher it prioor to enciphher it as E22E_CIPHER R_PAN. Beetween decippherment and
a enci-
pherrment, TOE E_CLEAR_P PAN shall nnot be retaiined any lonnger, or useed more oft
ften, than
stricctly necessaary.
th
4 Page 185
POI P
Protection Profile
 In aany case, Thhe TSF mustt automaticcally clear itts internal buffers
b whenen either: Th
he trans-
actioon is comppleted, or th he TSF has timed-out waiting forr the responnse from th he Card-
holdder or merchhant.
 If noo other senssitive objeccts with resiidual inform
mation existt the assignnment shall be filled
withh none.
{ XE "FD
DP_ITT.1/SRE
ED_E2E" }
FDP_IT
TT.1/SRED
D_E2E Basic internal transfer prrotection
FDP_IT TT.1.1/SRE ED_E2E Th he TSF shaall enforce the [assign nment: acceess controll SFP(s)
and//or informaation flow control
c SFPP(s)] to prevvent the [seelection: dissclosure, modifica-
m
tion,, loss of usee] of user data when itt is transmittted between n physicallyy-separated
d parts of
the T
TOE.
Refinnement:
The T TSF shall enforce
e the END_TO_E
E END Inforrmation Flo ow Controll SFP to preevent the
discllosure of E2E_CIPH
E HER_PAN and E2E_ _PAN_SK//E2E_PAN__PK [assig gnment:
other secret infformation, like admin nistration passwords]
p when theyy are transmmitted be-
tweeen physicallly-separated d parts of thhe CoreTSF and wheen they aree processed d by the
CoreeTSF.
Applicaation Note:
 The refinementt replaces th he SFR abovve, thus the SFR abovee shall not bbe considereed by the
authhor of the ST. This SSFR requires that E2E_CIP IPHER_PAN N and
E2EE_PAN_SK//E2E_PAN_ _PK shall bee protected
d when they are transmmitted between phys-
icallly-separatedd parts of th
he PED.
{ XE "FT
TP_TRP.1/SRE
ED_E2E" }
FTP_TRP.1/SRED
D_E2E Tru
usted path
FTP_TRP.1.1/SRE ED_E2E The TSF shaall provide a communiication pathh between ittself and
remoote users thhat is logicaally distinctt from otheer communiication pathhs and prov
vides as-
suredd identificattion of its end
e points aand protection of the co
ommunicateed data fromm unau-
thoriized E2E_P PAN_SK/E22E_PAN_P PK replacemment and
E2E__PAN_SK//E2E_PAN N_PK misusse.
FTP_TRP.1.2/SRE ED_E2E The TSF shaall permit reemote userss to initiate communicaation via
the trrusted path..
FTP_TRP.1.3/SRE
ED_E2E The TSF sshall requiire the usse of the trusted path
p for
E2E__PAN_SK//E2E_PAN
N_PK replaccement and
d E2E_PAN N_SK/E2E__PAN_PK usage.
Applicaation Note:
 If thhe TSF can hold multipple PAN enccryption keyys and if the key to be used to enccrypt the
PAN N can be exxternally seelected, theen the PED
D prohibits unauthoriseed key repllacement
and key misusee.
th
4 6 March,
M 2015
POI P
Protection Profile
 If thhe TSF doess not hold multiple
m PAN N encryptioon keys or if the key too be used too encrypt
the P PAN cannoot be externaally selectedd, this requiirement is not
n applicabble, and is therefore
t
conssidered to be
b satisfied.
 The term "externally seleccted" meanss: selected by an interf rface functioon to the TSF
TS com-
poneent that perf
rforms the PAN
P encrypption. Both human
h interrfaces and ccommand in nterfaces
are considered,d, and both direct
d and iindirect. External selecction also inncludes inteerference
withh or manipuulation of the data by w which the TS SF selects thhe key to bee used. Keyss may be
seleected througgh the PED keypad, or commands sent from another a devvice such as an elec-
tronnic cash reggister. Any commands sent from another
a devvice must bee cryptogra aphically
authhenticated too protect ag
gainst man--in-the-midd dle and replay attacks, this requirrement is
not applicable to devices that
t do not include com mmand for external key ey selection,, or can-
not hold multipple key hierrarchies relaated to PAN N encryptio on. If an appplication caan select
keyss from multtiple key hiierarchies, the TSF must m enforcee authenticaation of co ommands
usedd for external key selecction. If the TSF only allows
a an appplication too select keyys from a
singgle hierarchy
hy, then commmand autheentication iss not requirred.
12.4.1.55 SRED Su
urrogate PA
AN Packagee
645 f devices using hash functions to generate surrogate PAN

Thiss package iss intended for P val-
ues, e.g. in ordeer to exploiit a client daatabase outsside the dev
vice without
ut having to disclose
the P
PAN value..
646 SFR Rs in this paackage are applicable
a too MiddleTS
SF in POI-C
COMPREHE
ENSIVE co
onfigura-
tionn.
{ XE "FC
CS_COP.1/SR
RED_SURROG
GATE_PAN"" }
FCS_C
COP.1/SRED
D_SURRO
OGATE_PA
AN Cryptog
graphic operation
FCS_CCOP.1.1/SR RED_SURR ROGATE_P PAN The TSFT shall perform

p Geeneration ofo SUR-
ROG GATE_PAN N in accord dance with a specified cryptograph
c hic algorithm
m [selection: hash,
other method] and crypto ographic keyy sizes [asssignment: cryptograp
c phic key sizzes] that
meett the followiing: [assign nment: list of standard ds].
Refinnement:
PCI KK16: If the device is capable
c of ggenerating surrogate
s PA
AN values tto be outputted out-
side of the devicce, it is not possible to determine the originall PAN know wing only th
he surro-
gate value.
PCI K16.1: If using
u a hashh function tto generate surrogate PAN
P valuess, hash shalll use an
inputt salt of a minimum
m len
ngth of 64 bbits.
Applicaation Note:
 The author of thhe Security Target sha ll iterate this SFR for each
e TSF paart if necesssary.
 Conntribution too PCI K16: If the devicce is capablle of genera
ating SURRO OGATE_PA AN to be
outpputted outsside of th he device, it is not possible to determ mine the original
TOE E_CLEAR_P PAN knowin ng only the surrogate value.
v
th
4 Page 187
POI P
Protection Profile
 Conntribution too PCI K16.1
1: If using a hash funcction to gen
nerate SURRROGATE_P PAN, in-
put to the hash function
f mu
ust use a SU
URROGATE E_PAN_SAL LT with minnimum leng
gth of 64-
bits..
{ XE "FD
DP_IFC.1/SRE
ED_SURROG
GATE_PAN" }
FDP_IF
FC.1/SRED
D_SURROG
GATE_PA
AN Subset in
nformation
n flow contrrol
FDP_IFFC.1.1/SREED_SURRO OGATE_P PAN The TS

SF shall enfforce the SU
URROGAT
TE_PAN
Inforrmation Fllow Contro
ol SFP on
o subjectts: PED
o informaation: SURRROGATE E_PAN, SUR
RROGATE E_PAN_SA ALT
o operatiions: send.
{ XE "FD
DP_IFF.1/SRE
ED_SURROG
GATE_PAN" }
FDP_IF
FF.1/SRED
D_SURROG
GATE_PAN
N Simple security attrributes
FDP_IFFF.1.1/SRE ED_SURRO OGATE_PA AN The TS SF shall enfo

force the SU
URROGAT TE_PAN
Inforrmation Fllow Contro ol SFP baseed on the fo
ollowing typpes of subjeect and info
ormation
securrity attributes:
o subjectts: PED
o informaation: SUR RROGATE E_PAN, SUR RROGATE E_PAN_SA ALT
o no secu urity attribu
ute.
FDP_IFFF.1.2/SRE ED_SURRO OGATE_PA AN The TS SF shall peermit an infformation flow

f be-
tweeen a controllled subject and controllled information via a controlled ooperation iff the fol-
lowinng rules holld:
T
The PED can
c transferr a SURRO OGATE_PA AN outsidee the devicee.
FDP_IFFF.1.3/SRE ED_SURRO OGATE_PA AN The TSSF shall en

nforce the [[assignmen
nt: addi-
tionaal informattion flow co
ontrol SFP rules].
FDP_IFFF.1.4/SRE ED_SURRO OGATE_PA AN The TSF shall explicitly

e aauthorise an
n infor-
matioon flow bassed on the following
f ru
rules: [assig
gnment: rules, based oon security
y attrib-
mation flows].
utes,, that expliccitly authorrise inform
FDP_IFFF.1.5/SREED_SURRO OGATE_PA AN The TS SF shall exxplicitly deeny an info

ormation
flow based on thhe following
g rules:
o PCI K118: The deevice has ccharacteristtics that prevent or significantly deter
the use of the deviice for exhaaustive PAN
N determin nation.
o PCI K88: Encrypttion or deccryption off any arbitrrary data uusing any account
data-enncrypting key
k or keyy-encryptin ng key conntained in the devicee is not
permittted. The deevice must enforce tha at account data keys, key-enciph herment
keys, annd PIN-enccryption keeys have diffferent valu
ues.
o PCI K116.2: The PED P cannott send the SURROGA
S ATE_PAN__SALT to any a oth-
er subjeect.
th
4 6 March,
M 2015
POI P
Protection Profile
Applicaation Note:
 PCII K15: PAN N data that is i encryptedd, hashed (w with salt), masked
m or trruncated PAANs may
be ooutputted from the deviice. Truncaated PANs are a typicallyy defined ass a maximu um of the
firstt six and thee last four digits.
d Howeever, due to o differing PAN
P lengthss, the determ
mination
musst be made if the trunca ated digits ooffer sufficient protectiion against attacks dessigned to
preddict valid, full
fu PANs (w with longer BIN rangess). This wou uld partiallyy depend on n the po-
tentiial universee of PANs thatt could bbe included d and if the vendor wisshes to outp put more
thann first six annd last fourr digits of P
PAN data (ffor greater than 16 diggit PANs) th hey must
demmonstrate that the prob bability of P
PAN recoveery for the larger
l PAN N values aree equiva-
lent to the firstt six, last four determinnation for 16 1 digit PAN Ns. If usingg truncation,, any re-
movved segmentt cannot be replaced w with a hasheed version of o any compponent of th he origi-
nal P PAN. Trunccated and hashed
h versiions of the same
s PAN must
m not be transmitted d togeth-
er uunless encrypypted.
 If thhe author ofo the ST has h no addiitional inforrmation flo ow control SSFP rules or rules
f with none.
n
s attrributes whicch are only implicitly usused in the rules.
r
 PCII K8: this PC CI requirem ment is proccessed the sa ame mannerr as PCI B113 in the PP P POI.
 PCII K18: this PCIP requireement is proocessed the same s manner as PCI B B10 in the PP
P POI.
 the salt used too generate surrogate P PAN (SURR ROGATE_P PAN_SALT) T) is stored by Mid-
dleTTSF
12.4.2 Secu
uirements
647 The SRED PP--Module usees the assuraance packag ge of the un

nderlying PO
OI configurration, to
whicch is addedd. It adds reefinements tto some of the assuran
nce componnents. These refine-
mennts are definned in this section.
648 Withh regard to AVA_POI the SRED P
PP-Module has the folllowing requuirements:
 A very speccific part off the SRED functionalitty, namely "14. " Confiddentiality, au uthentic-
iity and integrity protecction of key s (including
g authenticitty and integgrity of public keys)
uused to prottect account data in payyment transsactions.", asa listed in ssection 3.2.22 is con-
ssidered partt of the CorreTSF and ttherefore reequires AVA A_POI.1/CooreTSF (wh hich uses
PPOI-Moderrate attack potential).
p
NNote:AVA__POI.1/CorreTSF is alrready defineed in the un nderlying coonfiguration n. Evalu-
aation underr this compoonent suppoorts PCI K3..
 AAll other SR RED functiionality is ppart of featu
ure 8. as listted in sectioon 3.2.2. Thherefore,
aaccording tot Table 1 in section 33.2.2.1, it belongs
b to the
t "MiddleeTSF" and requires
AAVA_POI.1/MiddleTS SF, which uuses POI-B Basic attackk potential. For an un nderlying
PPED-ONLY Y configuraation AVA__POI.1/Mid ddleTSF hass to be adde ded to the assurance
ppackage.
NNotes: AVA A_POI.1/M MiddleTSF iss already co ontained in the underlyying packag ge in the
ccase of PO OI-COMPR REHENSIVE E. Evaluatiion under this t compoonent suppo orts PCI
KK1.1.
th
4 Page 189
POI P
Protection Profile
649 Som
me PCI secuurity requireements havve been idenntified not to
t be securi
rity function
nal ones.
These security requiremen nts are intrroduced as refinementts of ADV__ARC, AG GD_OPE,
AGDD_PRE andd ALC_CMC.
650 The other SAR
Rs are left un
nchanged frrom EAL2.
12.4.2.11 Refinemeents for SARs defined

d for the SR
RED PP-Mo
odule
{ XE "AD
DV_ARC.1/SR
RED" }
ADV_A
ARC.1 Secu
urity archittecture des cription
Refinem
ment for AD
DV_ARC.1..3C:
Refinnement:
 PPCI K2: Iniitialization includes

i thee logical and
d physical integration
i oof an approved card
rreader into a PIN enttry POI term minal. Such h integratio
on does nott create new w attack
ppaths to thee account daata. The acccount data is protected (consistent with PCI A2)
A from
tthe input coomponent too the securee controller of
o the devicce.
Refinem
ment for AD
DV_ARC.1..5C
Refinnement:
 PPCI K1.2: Failure

F of a single secuurity mechaanism does not
n comproomise device securi-
tty. Protection against a threat is bbased on a combinatio on of at leaast two indeependent
ssecurity meechanisms.
 PPCI K21: The
T security y architectuure shall deemonstrate how followwing featurees of the
ddevice's opeerating system are conffigured:
o Thee operating system of the device must contaain only thee software (compo-
nentts and services) necess ary for the intended
i op
peration.
o Thee operating system
s musst be configuured securelly and run w
with least prrivilege.
o Thee security poolicy enforcced by the device
d mustt not allow uunauthorizeed or un-
neceessary functtions.
o APII functionaliity and com
mmands thatt are not reqquired to sup
upport specific func-
tionnality must be
b disabled (and wheree possible, reemoved).
Applicaation note foor ADV_AR

RC.1.1E
Applicaation Note:
 RRegarding ADV_ARC..1.3C refineement on in ntegration: The objecttive of this require-

mment is to assess
a thosee terminals w
where the card
c readerr is integrate
ted into the final
f so-
llution and to
t ensure th hat as an inttegrated device it does not create any new weeakness-
ees or permit new atta ack methodss to be used d against th he data. Thhe ICC reader may
cconsist of areas
a fferent proteection levelss: the areass of the IC card itself, and the
of diff
aarea holdinng retractedd cards.
th
4 6 March,
M 2015
POI P
Protection Profile
 RRegarding ADV_ARC.
A 1.5C refineement: In general,
g tech
hniques mayay include any
a com-
bbination off tamper-dettection methhods. Securrity mechanisms must nnot rely on insecure
a (but not llimited to) its power
sservices or characterisstics provideed by the deevice such as
ssupply andd unprotecteed wires. Taamper-evideent labels anda similarr methods in nvolving
ttamper eviddence are not
n considerred a securiity mechaniism. This reequirement does not
iimply the neeed for redu
undant secuurity mecha anisms, but rather
r sepaarate mecha anisms of
a different nature.
n
AGD_O
OPE.1 Opeerational usser guidancce
Refinem
ment for AG
GD_OPE.1..2C
Refinnement:
 KK11.2: Thee vendor mu ust provide cclear securitty guidancee to ensure tthat the PED
D's func-
ttionality wiill not be influenced byy logical anomalies succh as (but nnot limited to)
t unex-
ppected com mmand sequeences, unknnown comm mands, comm mands in a w wrong device mode
aand supplyiing wrong parameters
p or data whiich could reesult in the PED outpu utting the
cclear text PAAN or other sensitive iinformation n.
Refinem
ment for AG
GD_OPE.1..6C
Refinnement:
 KK11.2: Thee vendor mu ust provide clear securiity guidancee to ensure that accoun
nt data is
nnot retainedd any longerr, or used m
more often, than
t strictly
y necessary
Applicaation note foor AGD_OP

PE.1.1E
Applicaation Note:
 PPCI K15: For F devicess that allow w the modiffication of Status of op

operation mode,
m the
cchange to "encrypting g mode" muust result in
n the firmwa are revisionn number changing
c
aand the devvice providiing visual iindication of SRED enablement. TThe changee to "non
eencrypting mode" musst result in the firmware revision number rev everting andd the de-
vvice no longger providing visual inndication off SRED ena ablement. Th
The visual in
ndication
mmust not bee transient. This must bbe documented in information provvided by thee vendor
tto the entitiies deployin
ng these devvices.
{ XE "AG
GD_PRE.1/SR
RED" }
AGD_P
PRE.1 Prep
parative procedures
Refinem
ment for AG
GD_PRE.1.2C
Refinnement:
 TThe preparaative proced

dures must ddefine clearrly, that durring initialissation and key
k man-
aagement prrocedures foor the devicce, the following must be met: PPCI K7: Seecret and
th
4 Page 191
POI P
Protection Profile
pprivate keyys that reside within tthe device to supportt account ddata encryp ption are
uunique per device.
 PPCI K21: If I TOE userr participatiion is requiired, the prreparative pprocedures shall
s de-
sscribe clearrly how thee TOE user can config gure the devvice's operaating system
m as fol-
llows:
o Thee operating system of the device must contaain only thee software (compo-
nentts and services) necess ary for the intended
i op
peration.
o Thee operating system
s musst be configuured securelly and run w
with least prrivilege.
o Thee security po olicy enforcced by the device
d mustt not allow uunauthorizeed or un-
neceessary functtions.
o APII functionaliity and com mmands thatt are not reqquired to sup
upport specific func-
tionnality must be
b disabled (and wheree possible, reemoved).
{ XE "AL
LC_CMS.2/SR
RED" }
ALC_C
CMS.2 Partts of the TO
OE CM covverage
Refinem
ment for AL
LC_CMS.2..2C
Refinnement:
 PPCI K10: The Firmw ware, and aany changess thereafterr, has beenn inspected and re-
vviewed usinng a docum
mented and auditable process,
p and certified as being frree from
hhidden and unauthorizeed or undoccumented fu
unctions.
12.4.3 Secuurity Requirements R Rationale

12.4.3.11 Objectivees
651 Thiss section jusstifies, how
w the securitty objectivees for the TOOE, which w
were newly
y defined
for tthe SRED PP-Module,
P are supportted by the SFRs
S in the SRED PP-MModule.
O.Paym mentTransaaction
652 If th
he underlyinng configurration is PO OI-COMPRE EHENSIVE E, this objecctive is alreeady up-
heldd by the SFR Rs in that configuratio
c on as shown n in the corrresponding rationale inn section
10. IIn this case the followiing rational e can be considered as additional support. In the case
of P
PED-ONLY Y, the follow
wing rationalle covers thhe objective completelyy.
 TThe SRED Distributed Architectture Packag ge protects payment ddata during internal
ttransfer if thhe TOE is based
b on a ddistributed architecture
a .
 TThe SRED basis packaage definess access con ntrol rules, which
w makee sure that only au-
tthentic mannagement data can be used for TO OE manageement and tthat only au uthorised
aapplicationss can proceess paymentt data accorrding to cleaarly definedd rules ensu
uring au-
tthenticity annd (where applicable)
a cconfidentiality.
O.POI__SW
 T The SRED basis
b packagge, in particcular FPT_F FLS.1/SRED D enforces the TSF au uthentici-
tyy and integrrity by preseerving a seccure state in
n case of log
gical anomaalies).
 T The protectiion of the auuthenticity aand integritty of POI_S SW and crypptographic keys
k up-
oon downloadding of new w componennts and upd dating of exxisting ones is protecteed by the
SSRED bassis packaage, in pparticular due to SFRs FFDP_ACC.1 1/SRED,
FFDP_ACF.11/SRED and d FDP_ITC .1/SRED.
th
4 6 March,
M 2015
POI P
Protection Profile
O.POIAApplication nSeparationn
 T The SRED basis pack kage, in parrticular FDP P_ACC.1/S SRED and FFDP_ACF.1/SRED
eensure that no
n other application caan interfere with security functionns of a paym
ment ap-
pplication.
 F FDP_RIP.1//SRED ensu ures that noo residual in
nformation remains inn resources released
bby the paymment applicattion and payyment appliication temp
porary crypptographic keys.
k
O.PAN
NConfidentiiality
 CConfidentiallity of the PAN
P for ennd-to-end enncryption iss addressedd by SFRs from
f the
SSRED End-tto-end proteection Packkage.
 CConfidentiallity of the PAN whenn transmitted within th he TOE is aaddressed byb SFRs
fr
from the SR
RED Distribu uted Architeecture Pack
kage
 BBoth packagges rely on the SRED Cryptograp phy packagge to ensuree encipherm
ment and
ddeciphermennt operationns.
 SSRED Basiss Package provides
p thee common protection requiremennts such as physical
resistance
O.PAN
NDeduction
 P
Protection of gate values generated from
o the surrog f the PA
AN is addreessed by SR
RED Sur-
roogate PAN Package.
O. PAN
NOperatinggMode
 T
This is enforrced by the SRED endd-to-end pro
otection pacckage, in paarticular by the SFR
F
FMT_MSA..1/SRED.
12.4.3.22 Rationalee table of Seecurity Ob

bjectives an
nd SFRs
Securityy Objectivess Seccurity Functtional Requ
uirements
O.PaymeentTransaction Alll SFRs from the SRED basis
b packagee. In case of a distributed
d archi-
tecture
t also aall SFRs of th
he SRED disstributed archhitecture pacckage.
O.POI_S
SW Alll SFRs from the SRED basis
b packagee, in particulaar
FDP_ACC.1
F /SRED, FDP
P_ACF.1/SR RED and FDPP_ITC.1/SRE
ED
O.POIAppplicationSeeparation Alll SFRs from the SRED basis
b packagee, in particulaar
FDP_ACC.1
F /SRED, FDP
P_ACF.1/SR RED and FDPP_RIP.1/SRE
ED
O.PANC
Confidentialiity Alll SFRs from the packages SRED basiis, SRED Ennd-to-End pro otection
a SRED crryptography.. In case of a distributed aarchitecture also all
and
SFRs
S from thhe SRED Disstributed architecture pacckages.
O.PAND
Deduction Alll SFRs from the SRED Surrogate
S PA
AN Package
O.PANO
OperatingMoode Alll SFRs from the SRED base
b package, in particulaar
FMT_MSA.1
F 1/SRED
Table 18: Security Objeectives and SF

FRs in SRED-- Coverage
th
4 Page 193
POI P
Protection Profile
12.4.3.33 Dependen
ncies
S
SFRs Depeendencies
Requireements CC Depen dencies Satisfied Dependencie
D es
FMT_SM
MR.1/SRED
D (FIA_UID. 1) FIA_UID.1
1/SRED
FIA_UID
D.1/SRED No Dependdencies
FDP_ITC
C.1/SRED (FDP_ACCC.1 or FDP_ACF.1/SRED andd (see below
w)
FDP_IFC
C.1) and
(FMT_M
MSA.3)
FPT_FL
LS.1/SRED No Dependdencies
FIA_UA
AU.2/SRED (FIA_UID. 1) FIA_UID.1
1/SRED
FDP_AC
CF.1/SRED (FDP_ACC
C.1) and FDP_ACC
C.1/SRED andd (see below
w).
(FMT_M
MSA.3)
FDP_AC
CC.1/SRED (FDP_ACF
F.1) FDP_ACF.1/SRED
FTA_SS
SL.3/SRED No Dependdencies
FPT_PH
HP.3/SRED No Dependdencies
FPT_EM
MSEC.1/SRE
ED No Dependdencies
FMT_M
MSA.1/SRED
D (FDP_ACCC.1 or FDP_IFC.11/SRED_E2E E,
FDP_IFC
C.1) and FMT_SM MR.1/SRED
(FMT_SM
MF.1) and see below
w for omittinng FMT_SM
MF.1
(FMT_SM
MR.1)
FPT_TS
ST.1/SRED No Dependdencies
FTP_ITC
C.1/SRED No Dependdencies
FTP_ITC
C.1/SRED_C
CRYPTO No Dependdencies
FPT_TD
DC.1/SRED__CRYPTO No Dependdencies
FDP_ITC
C.2/SRED_C
CRYPTO (FDP_ACCC.1 or FTP_ITC.1
1/SRED_CRRYPTO,
FDP_IFCC.1) and FPT_TD
DC.1/SRED__CRYPTO,
(FPT_TDDC.1) and FDP_IFC
C.1/SRED_IN
INT,
(FTP_IT C.1 or FDP_IFC
C.1/SRED_E
E2E
FTP_TRP
RP.1)
FCS_CO
OP.1/SRED__CRYPTO (FCS_CKMM.1 or FDP_ITC.2
2/SRED_CR
RYPTO and (see
( be-
FDP_ITC
C.1 or low)
FDP_ITC
C.2) and
(FCS_CK
KM.4)
FDP_IFC
C.1/SRED_IINT (FDP_IFF. 1) FDP_IFF.1
1/SRED_INT
T
FDP_IFF
F.1/SRED_IN
NT (FDP_IFC..1) and FDP_IFC.1
1/SRED_INT
T, and (see below)
b
(FMT_M
MSA.3)
FDP_ITT
T.1/SRED_IINT (FDP_ACCC.1 or FDP_IFC.1
1/SRED_INT
T
FDP_IFC
C.1)
th
4 6 March,
M 2015
POI P
Protection Profile
Requireements CC Depen dencies Satisfied Dependencie

D es
FMT_M
MSA.1/SRED
D_INT (FDP_ACCC.1 or FMT_SMR R.1/SRED,
FDP_IFC
C.1) and FDP_IFC C.1/SRED_IN
INT
(FMT_SM
MF.1) and see below for
f FMT_SM MF.1
(FMT_SM
MR.1)
FDP_RIP.1/SRED_IINT No Dependdencies
FDP_IFC
C.1/SRED_E
E2E (FDP_IFF. 1) FDP_IFF.1
1/SRED_E2E
E
FDP_IFF
F.1/SRED_E
E2E (FDP_IFC..1) and FDP_IFC.1
1/SRED_E2E
E, and (see below)
b
(FMT_M
MSA.3)
FMT_M
MSA.1/SRED
D_E2E (FDP_ACCC.1 or FDP_IFC.1
1/SRED_E2EE,
FDP_IFC.11) and FMT_SMRR.1/SRED, seee below forr
(FMT_SMF F.1) and FMT_SMFF.1
(FMT_SMR R.1)
FIA_UID
D.1/SRED_E
E2E No Dependdencies
FDP_RIP.1/SRED_E
FDP_ITT
T.1/SRED_E
E2E (FDP_ACCC.1 or FDP_IFC.1
1/SRED_E2E
E
FDP_IFC.11)
FTP_TR
RP.1/SRED_E
FCS_CO
OP.1/ (FCS_CKM
M.1 or see below
SRED_S
SURROGAT
TE_PAN FDP_ITC.11 or
FDP_ITC.22) and
(FCS_CKM
M.4)
FDP_IFC
C.1/ (FDP_IFF. 1) FDP_IFF.1
1/SRED_E2E
E
SRED_SSURROGAT
TE_PAN
FDP_IFF
F.1/ (FDP_IFC..1) and FDP_IFC.1 1/SRED_SU
URROGATE_
_PAN
SRED_SSURROGAT
TE_PAN (FMT_MSA A.3) and (see beelow)
Table 19:
1 SFRs Depeendencies in the
t SRED PP--Module
th
4 Page 195
POI P
Protection Profile
Rationaale for the exxclusion of Dependenccies
 TThe depend dency FMT T_MSA.3 oof FDP_ITC C.1/SRED is discardeed. There arre no se-
ccurity attribuutes to be managed
m foor download ding objects. Terminall Managem ment Sys-
teem decides to update/d download thhem or not.
 TThe depend dency FMT T_MSA.3 off FDP_ACF.1/SRED is discardeed. No management
fu
functions aree required for
f the consiidered assetts.
 TThe depend dency FMT T_SMF.1 of FMT_M MSA.1/SRE ED is discaarded. Therre is no
nneed to speccify additional manageement functtions because modificaation of seccurity at-
trributes is suufficient.
 TThe depend dency FCS S_CKM.4 oof FCS_CO OP.1/SRED D_CRYPTO O is discarrded. No
specific crypptographic key k destrucction method d is enforceed. Keys aree destroyed by eras-
inng them.
 TThe depend dency FMT T_MSA.3 oof FDP_IF FC.1/SRED_ _INT is diiscarded. The
T roles
responsible for managing
m the seccurity attributes aare defin
ned in
FFMT_MSA..1/SRED_IN NT. These rroles are alsso responsib ble for makking sure thhat initial
vvalues of thee attributes are set propperly.
 TThe depend dency FMT T_SMF.1 oof FMT_M MSA.1/SRED D_INT is ddiscarded. There is
nno need to specify
s add
ditional mannagement fu unctions because modiification of security
aattributes is sufficient.
 TThe depend dency FMT T_MSA.3 oof FDP_IF FC.1/SRED_ _E2E is diiscarded. TheT roles
responsible for managing
m the seccurity attributes aare defin
ned in
FFMT_MSA..1/SRED_E E2E. These rroles are also responsib ble for makking sure thhat initial
vvalues of thee attributes are set propperly.
 TThe depend dency FMT T_SMF.1 oof FMT_M MSA.1/SRED D_E2E is ddiscarded. There is
nno need to specify
s add
ditional mannagement fu unctions because modiification of security
aattributes is sufficient.
 TThe depend dency FCS_CKM.4 oof FCS_CO OP.1/SRED_SURROG GATE_PAN N is dis-
ccarded. If a hash functtion is usedd, the follow wing holds: A hash funnction doess not use
aany cryptogrraphic key; hence, a reespective keey destruction cannot bbe expected d here. If
a cryptograpphic algoritthm with seecret keys is i used, thee following holds: No specific
ccryptographic key destrruction methhod is enforrced. Keys are a destroyeed by erasin ng them.
 TThe depeendency FCS_CKM M.1 or FDP_ITC C.1 or FDP_ITC C.2 of
FFCS_COP.11/SRED_SU URROGAT TE_PAN is i discarded. If a hashh function is used,
thhe followinng holds: A hash functtion does no ot use any cryptograph
c hic key; hennce, nei-
thher a respeective key import nor key generaation can bee expected here. If a different
ccryptographic function is used by a specific TOE, T the ST author mmay need to add one
oof the SFRs required by y the depenndency or giive a specifiic rationale for not neeeding the
ddependency otherwise.
 TThe depend dency FMT T_MSA.3 oof FDP_IF FF.1/SRED_ _SURROG GATE_PAN N is dis-
ccarded. Theere are no seecurity attribbute to consider for thiis function
S
SARs Depeendencies
653 Sincce all SARss are taken from the P
POI PP, the same rationale alreadyy given theere holds
(seee section 9.22.1).
th
4 6 March,
M 2015
POI P
Protection Profile
12.4.3.44 Rationalee for the Seecurity Assu urance Reqquirementss
654 The assurance requiremen
r ts are takenn from the POI
P configuration, to w which the SRRED PP-
Moddule is addeed, and suittable refineements weree added forr some of th them. A genneral ra-
tionnale for the fact that th
he SRED PP P-Module isi consisten
nt to the unnderlying co
onfigura-
tionns from the POI
P PP is given in chappter 12.5.
12.5 Rationale of consisten

c ncy of the SRED PP--Module w
with the ba
ase
PPs
s
655 As explained in
i chapter 1 and 2, thhe POI-COM MPREHEN NSIVE basee PP and th he PED-
ONL LY base PPP, possibly enhanced
e bby the Open n protocols package,
p arre the four base
b PPs
whicch can be extended
e by
y the SRED PP-Modulee given in 12. 1 In orderr that the SR
RED PP-
Moddule can bee used witho out checkinng whether the t SRED PP-Module
P is consistent to the
chossen base PP
P, this chaptter gives a raationale forr the consisttency.
656 As ccan be seenn from the asset
a chapteer in the SR
RED PP-Module, the aassets addreessed by
the SRED PP-M Module are consistent with the asssets addresssed by the base PP: The
T PAN
in thhe SRED PPP-Module is an elemennt of PAY_D DAT in thee base PP annd in the SR
RED PP-
Moddule speccific form ms of thhe PAN are addrressed (T TOE_CLEAR_PAN,
TOE E_CIPHER__PAN and E2E_CIPHE
E ER_PAN).
657 In aaddition TO
OE_PAN_SK K is definedd which is a key used to protect tthe PAN du uring in-
ternnal transmisssion. E2E_
_PAN_PK aand E2E_P PAN_SK arre keys to uused to pro otect the
PAN N when trannsferred ennd-to-end. T
These keys can be seen n as instanttiations of POI_SK
and POI_PK. This
T is not a contradictiion in the assset definition because all assets are
a clear-
ly defined.
658 Finaally SURRO OGATE_PA AN and SU URROGAT TE_PAN_SA ALT are asssets introd duced by
the S
SRED PP-M Module and
d clearly deffined and th
herefore therre is no conntradiction to the as-
sets of the basee PP.
659 User and subjeccts are the same
s in the base PP and
d in the SRE
ED PP-Moddule.
660 SREED PP-Moodule doess not defiine additio onal threats, but reffines the existing
T.Trransaction defined
d in PP
P POI. Th e refinemen nt is consisttent becausee it is relateed to the
PANN and this does
d not conntradict otheer threats.
661 There are no addditional asssumptions oor OSPs.
662 The threee objecctives O.Paymen ntTransactioon, O.PPOI_SW, and
O.POIApplicattionSeparatiion are addded to the base
b PP in the
t case off PED-ONL LY. That
theyy are compaatible with the base PP
P can be seeen from thee fact that tthey are alrready in-
cludded in POI__COMPREH HENSIVE, w which is alsso an extenssion of POI__PED.
663 All other objecctives of thee SRED-Moodule add additional
a protection
p reequirements for the
PAN N and relateed data: Thee objective oof PAN con nfidentiality
y protectionn is added ass a sepa-
rate objective (O.PANCon
( nfidentialityy), the objective of a surrogate
s PAAN resistin
ng to de-
ducttion is addeed as a sepaarate objecttive (O.PAN NDeduction n) and the oobjective off protec-
tionn of SR RED activ vation funnctions is added as a sseparate objective o
(O.PPANOperattingMode). O.PANConnfidentiality y is a refinem
ment of thee base PP ob bjectives
addrressing PAY Y_DAT and d therefore does not co ontradict thoose. Surroga
gate PANs are
a intro-
duceed by the SRED PP-M Module and tthus O.PAN NDeduction does not coontradict to o any ob-
th
4 Page 197
POI P
Protection Profile
jectiives of the base PP. O.PANOper
O ratingMode introduces a new opeerating mod
de which
doess not contraadict the basse PP objecttives.
664 There are no seecurity objecctives for thhe environm
ment.
665 For the SFR paart the follow
wing holds:
666 The PAN relateed SFRs off the SRED PP-Modulee do not con ntradict the PAY_DAT T related
SFRRs because the
t base PP P requires thhe POI to bee able to pro
otect all PA
AY_DAT seent or re-
ceivved by the POI again nst modificaation and PAY_DAT
P sent or recceived by the POI
agaiinst disclosuure. This is not a contrradiction beecause the SFRs
S of thee SRED PP-Module
refinne the SFRss of the basee PP. The ssame holds for
f the keyss of the SRE ED PP-Mod dule. If a
key of the SRE ED PP-Modu ule is seen as an instanntiation of POI_SK
P or PPOI_PK there is no
conttradiction foor the samee reason, i.ee. a refinem
ment of the usage
u of theese keys wh
hen used
to prrotect PAYY_DAT.
667 In aaddition the table Tablee 17 in the bbeginning of
o chapter 12.4.1 “Secuurity Functional Re-
quirrements” off 12 explain t relation of the SFR
ns and thus gives a rattionale for the Rs to the
basee PP.
668 The SRED PP P-Module do oes not asssign attack potentials. This is doone in the base b PP.
How wever, it hass to be provven that the “linking pin n” between n the SRED PP-Modulee and the
basee PP is conssistent. Firstt the asset ddefinition off the base PP and the SSRED PP-M Module is
conssistent becaause of the reference
r too the SRED D PP-Modulle in the rela lated chapteer. In ad-
ditioon, the base PP introd duces Accoount Data as a the non--key assets of the SR RED PP-
Moddule and Account Data related keeys as the key k assets of o the SREED PP-Mod dule. The
basee PP requirees the Acco ount Data too be protected at a Basiic level andd the keys reelated to
the aaccount datta to be prottected at a M Moderate leevel. Thus thet asset linnk is consisttent. The
basee PP assignns the assets and operaations on th hem to TSF Fs, i.e. Acccount Data to Mid-
dleTTSF and Acccount Dataa related keyys to CoreT TSF. Assign ning the prootection lev
vel to the
asseets this clearrly defines at
a which levvel the TSFs are to be protected.
p C
Considering the pro-
tectiion level off Account Data
D and PPAY_DAT this is consistent becaause both are a Low.
Connsidering thee protection n level of P OI_SK, PO OI_PK and the t Account nt Data relatted keys,
therre is a differrence becauuse Accountt Data relateed keys are to be proteccted at a hig gher lev-
el. T
This is not an inconsisstency becauuse increasiing the prottection leveel is an allo owed ap-
proaach when thhe asset defiinition is cleear.
669 The same argum
ment holds for the assuurance comp
ponents.
th
4 6 March,
M 2015
POI P
Protection Profile
13 Ann
nex – EPC Book 4 to C
Common Criteria
C
13.1 EPC
C Book 4 Seecurity Req
quirementss
Note: EEPCN requirrements are not all expllicitly inclu uded in [EPCC B4] but dderived from
m chap.
2.7 espeecially conssidering the applicabilitty of requireements. SRE
ED is not coovered in th
his
chapter,, cf. sectionn 12. SFR-su
upporting feeatures due to Open Pro otocols are also not cov
vered in
this chaapter.
Class EP
PC Book 4 Security R
Requiremen
nts Numberr
Core Ph
hysical Seccurity Requ
uirements
PCI Thhe device usses tamper-ddetection an nd responsee mecha- PCIA1
(N/A foor nissms that cau use it to beccome immediately inop perable and
the POII- ressult in the automatic
a annd immediaate erasure ofo any sensi--
CHIP- tivve data that may be storred in the device, such that it be-
ONLY coomes infeasiible to recovver the senssitive data. These
T
configuura- meechanisms protect
p agaiinst physicaal penetratio
on of the
tion ac- deevice by means of (but not limited to) drills, laasers,
cording to chhemical solv vents, openiing covers, splitting
s thee casing
[EPC B4], (seeams), and using
u ventillation openiings; and thhere is not
chap. anny demonstrrable way too disable or defeat the mechanism
m
2.6.2) annd insert a PIN-disclosi
P ing bug or gain
g access to t secret in--
forrmation witthout requirring an attacck potential of at least
266 per devicee for identifiication and initial explo oitation,
wiith a minimu um of 13 foor exploitatiion, exclusiv ve of the ICC
caard reader; and
a Note: Thhe replacem ment of both h the front
annd rear casinngs shall be considered d as part of any
a attack
scenario. All attacks shalll include a minimum of o ten
hoours’ attack time for exp xploitation.
PCI Faailure of a siingle securiity mechanism does not compro- PCIA2

(N/A foor miise device security. Prootection agaainst a threat is based
the POII- onn a combinaation of at leeast two ind
dependent seecurity
CHIP- meechanisms.
ONLY
configuura-
tion ac-
cording to
[EPC B4],
chap.
2.6.2)
PCI Thhe security of
o the devicce is not com
mpromised by
b altering:: PCIA3
- Environmen
E ntal conditioons.
- Operational
O conditions
(A
An example includes suubjecting thee device to tempera-
t
th
4 Page 199
POI P
Protection Profile
Class EP
Requiremen
nts Numberr
Core Ph
hysical Seccurity Requ uirements
turres or operaating voltages outside the
t stated op
perating
rannges).
PCI Seensitive funcctions or daata are only used in the protected PCIA4
(N/A foor areea(s) of the device. Sennsitive data and functioons dealing
the POII- wiith sensitivee data are prrotected from modificaation with-
CHIP- ouut requiring an attack pootential of at
a least 26 for
f identifi-
ONLY caation and iniitial exploitaation
configuura-
tion ac-
cording to
[EPC B4],
chap.
2.6.2)
PCI Thhere is no feeasible way to determin ne any enterred and in- PCIA5
(N/A foor terrnally transmmitted PIN digit by mo onitoring sound, elec-
the POII- troo-magnetic emissions, ppower conssumption or any other
CHIP- exxternal charaacteristic avvailable for monitoring— —even
ONLY wiith the coopperation of tthe device operator
o or sales
s
configuura- cleerk—withou ut requiringg an attack potential
p of at least 26
tion ac- forr identificattion and inittial exploitaation with a minimum
cording to off 13 for explloitation.
[EPC B4],
chap.
2.6.2)
PCI Deetermination n of any PINN-security-rrelated cryp ptographic PCIA6
keey resident in
i the devicee, by penetrration of thee device
annd/or by monitoring em manations fro om the deviice (includ-
ingg power fluuctuations), requires an attack poteential of at
leaast 35 for id
dentificationn and initiall exploitatio
on with a
miinimum of 15 for explooitation.
POI- Foor POI in the POI-CHIP P-ONLY co onfiguration n the attack EPC-CH
HIP-
CHIP- pootential is reeduced. "…,,requires an n attack poteential of at ONLYAA6
ONLY leaast 26 for iddentificationn and initiall exploitatio
on with a
configuura- miinimum of 13 for explooitation." In n addition thhe require-
tion ac- meent holds fo or secret keyys protectinng the authen nticity and
cording to inttegrity of paayment trannsaction data.
[EPC B4],
chap.
2.6.2)
PCI Noote: If the POI
P device hhas a keypad d that can be
b used to
ennter non-PINN data, the ddevice mustt meet at leaast one of
thee following: A7, B16.
th
4 6 March,
M 2015
POI P
Protection Profile
Class EP
Requiremen
nts Numberr
Core Ph
hysical Seccurity Requuirements
- A7 appliees to any commponents or o paths conttaining
plaintext display
d signnals between n the crypto
ographic
processor and displayy unit.
- B16 appliies to devicees that allow
w for updatees of
prompts or
o use cryptoography to communicaate with a
display, whether
w perfformed by the
t vendor or o the ac-
quirer.
PCI Thhe unauthorrized alteratiion of prom mpts for nonn-PIN data PCIA7
(N/A foor enntry into the PIN entry kkey pad succh that PINss are com-
the POII- promised, i.e.., by promptting for the PIN entry whenw the
CHIP- ouutput is not encrypted,
e ccannot occu
ur without reequiring ann
ONLY atttack potentiial of at leasst 18 per dev
vice for identification
configuura- annd initial exp
ploitation wwith a minim mum of 9 for exploita-
tion actioon.
cording to
[EPC B4],
chap.
2.6.2)
PCI Thhe device prrovides a mmeans to deteer the visuall observa- PCIA8
tioon of PIN vaalues as theey are being entered by the card-
hoolder.
EPC It is optional to
t have a prrivacy shield on a PED D. However EPC Plu
usA8.a
PLUS if a privacy shhield is in pplace then it shall be according to
EPPC Guidelin nes on Privaacy Shields..
PCI It is not feasib
ble to penettrate the devvice to makee any addi- PCIA9
(N/A foor tioons, substitu
utions, or m
modificationss to the mag gnetic-stripee
the POII- reaader and asssociated harrdware or software, in order to de--
CHIP- terrmine or mo odify magneetic-stripe trrack data, without
w re-
ONLY quuiring an attack potentiaal of at leasst 16 per dev
vice, for
configuura- ideentification and initial exploitationn, with a miinimum of 8
tion ac- forr exploitatio
on.
cording to
[EPC B4],
chap.
2.6.2)
PCI Seecure compo onents intennded for unaattended dev vices con- PCIA10
0
(N/A foor taiin an anti-reemoval mecchanism to protect
p against unau-
the POII- thoorized remo oval and/or unauthorizeed re-installlation. De-
CHIP- feaating or circcumventingg this mechaanism must require an
ONLY vice for identification
atttack potentiial of at leasst 18 per dev
configuura- annd initial expploitation, w
with a minim mum of 9 foor exploita-
th
4 Page 201
POI P
Protection Profile
Class EP
Requiremen
nts Numberr
Core Ph hysical Seccurity Requ uirements
tion actioon.
cording to
[EPC B4],
chap.
2.6.2)
PCI If PIN entry is accompannied by audiible tones, then t the PCIA11
tonne for each entered PIN N digit is in
ndistinguishaable from
thee tone for an ny other ent
ntered PIN digit.
d
Core Logical Secu urity Requiirements
PCI Thhe device peerforms a seelf-test, whiich includess integrity PCIB1
annd authenticity tests upoon start-up and at least once per
daay to check whether
w thee device is in a compromised statee.
In the event ofo a failure, the device anda its funcctionality
faiil in a securre manner. T The device must
m reinitiialize
meemory at leaast every 244 hours.
PCI Thhe device’s functionalitty shall not be influencced by logi- PCIB2
caal anomaliess such as (buut not limiteed to) unexp pected
coommand seq quences, unkknown com mmands, com mmands in a
wrrong devicee mode and supplying wrong w param
meters or
daata which co ould result iin the devicee outputtingg the clear-
texxt PIN or otther sensitivve data.
PCI Thhe firmwaree, and any chhanges therreafter, havee been in- PCIB3
sppected and reeviewed usiing a docum mented and auditable
process, and certified
c as being free from
f hidden
n and unau--
thoorized or un ndocumenteed functionss.
EPC Thhe initial revview of the PED firmw
ware must bee performedd EPC Plu
usB3.a
PLUS byy a testing laaboratory.
PCI If the device allows
a updaates of firmwware, the deevice cryp- PCIB4
toggraphically authenticattes the firmwware and if the authen--
ticcity is not co
onfirmed, thhe firmwaree update is rejected
r andd
deeleted.
PCI Thhe firmwaree must supp ort the authhentication ofo applica- PCIB4.1
1
tioons loaded onto
o the term
minal consistent with B4.
B If the
deevice allowss software aapplication and/or
a confiiguration
uppdates, the device
d crypttographicallly authenticcates up-
daates consisteent with B4..
PCI Thhe device neever displayys the entereed PIN digitts. Any ar- PCIB5
rayy related to PIN entry ddisplays onlly non-significant
syymbols, e.g.,, asterisks.
PCI Seensitive dataa shall not bbe retained any
a longer, or used PCIB6
moore often, th
han strictly necessary. Online PIN Ns are en-
cryypted withinn the devicee immediateely after PIN
N entry is
th
4 6 March,
M 2015
POI P
Protection Profile
Class EP
Requiremen
nts Numberr
Core Ph
coomplete and d has been siignified as such
s by the cardholderr,
e.gg., via presssing the enteer button.
Thhe device must
m automat atically clearr its internall buffers
whhen either:
Thhe transactio on is complleted, or
Thhe device haas timed outt waiting fo or the respon nse from thee
caardholder orr merchant.
PCI Acccess to sennsitive servi ces requiress authenticaation. Sensi-- PCIB7
tivve services provide
p acccess to the underlying
u sensitive
funnctions. Sen nsitive funcctions are th
hose functions that pro--
ceess sensitivee data such aas cryptograaphic keys, PINs, and
paasswords. En ntering or eexiting sensiitive servicees shall not
revveal or otheerwise affecct sensitive data.
d
PCI Too minimize the risks froom unautho orized use of sensitive PCIB8
serrvices, limits on the nuumber of acttions that caan be per-
forrmed and a time limit iimposed, affter which th he device iss
forrced to retu
urn to its norrmal mode.
PCI If random num mbers are ggenerated by y the devicee in connec-- PCIB9
tioon with secu
urity over seensitive data, the rando
om number
geenerator has been asses sed to ensurre it is geneerating
nuumbers suffiiciently unppredictable.
PCI Thhe device haas characterristics that prevent
p or siignificantlyy PCIB10
deeter the use of the devicce for exhauustive PIN determina-
d
tioon.
EPC Thhe POI has characterist
c tics that prev
vent the usee of the de- EPC Plu
usB10.a
PLUS vicce for exhau
ustive PIN ddetermination.
PCI Thhe key-management tecchniques im mplemented in the de- PCIB11
vicce conform to ISO 115568 and/or ANSI
A X9.24
4. Key
maanagement techniques must suppo ort the ANSI TR-31
keey derivation
n methodoloogy or an equivalent methodology
m y
forr maintainin
ng the TDE
EA key bund dle.
PCI Thhe PIN encrryption techhnique impleemented in the device PCIB12
is a techniquee included inn ISO 9564
4.
PCI It is not possible to encryypt or decry
ypt any arbittrary data PCIB13
using any PIN N encryptingg key or key y encrypting key con-
taiined in the device.
d Thee device must enforce thhat data
keeys, key-enccipherment kkeys, and PIN-encrypt
P ion keys,
haave differentt values.
PCI Thhere is no mechanism
m iin the devicee that wouldd allow the PCIB14
ouutputting of a private orr secret cleaar-text key or
o cleartext
PIIN, the encry
yption of a key or PIN under a key y that might
ht
th
4 Page 203
POI P
Protection Profile
Class EP
Requiremen
nts Numberr
Core Ph
itsself be disclosed, or thee transfer off a clear-text key from
a component
c of high secuurity into a componentt of lesser
security.
PCI Thhe entry of any
a other trransaction data
d must bee separate PCIB15
froom the PIN entry proceess, avoidinng the accideental dis-
plaay of a card
dholder PIN
N on the dev vice display. If other daa-
ta and the PINN are entereed on the samme keypad, the other
daata entry and
d the PIN enntry shall bee clearly sep
parate oper--
atiions.
PCI Noote: If the POI
P device hhas a keypad d that can be
b used to
ennter non-PINN data, the ddevice mustt meet at leaast one of
thee following: A7, B16.
- A7 appliees to any commponents or o paths conttaining
plaintext display
d signnals between n the crypto
ographic
processor and displayy unit.
- B16 appliies to devicees that allow
w for updatees of
prompts or
o use cryptoography to communicaate with a
display, whether
w perfformed by the
t vendor or o the ac-
quirer.
PCI Alll prompts for
f non-PIN N data entry are under thhe control PCIB16
off the cryptoggraphic unitt of the deviice and requuiring an at--
tacck potentiall of at least 18 per device for identtification
annd initial exp
ploitation wwith a minimmum of 9 for exploita-
tioon to circum
mvent. If thee prompts arre stored insside the
cryyptographicc unit, they cannot feassibly be altered withoutt
caausing the errasure of thee unit’s cryp
ptographic keys. If thee
prompts are stored outsidde the crypttographic un nit, crypto-
graphic mech hanisms musst exist to en nsure the auuthenticity
annd the propeer use of thee prompts an nd that moddification off
thee prompts oro improper use of the prompts
p aree prevented..
POI- Crryptographic mechanism ms must ex xist to ensure the au- HIP-
EPC-CH
CHIP- theenticity andd the properr use of the prompts
p andd that modi-- ONLYBB16
ONLY ficcation of thee prompts oor improper use of the prompts
p aree
configuura- prevented.
tion ac-
cording to
[EPC B B4],
chap.
2.6.2)
PCI If the device supports
s muultiple appliications, it must
m en- PCIB17
forrce the sepaaration betw
ween applicaations. It mu ust not be
poossible that one
o applicaation interferes with or tampers
th
4 6 March,
M 2015
POI P
Protection Profile
Class EP
Requiremen
nts Numberr
Core Ph
wiith another application
a or the OS of
o the device includingg,
buut not limiteed to, modify
fying data ob
bjects belon
nging to an--
othher applicattion or the O
OS.
PCI Thhe operating
g system of the device must contaiin only the PCIB18
sooftware (com
mponents annd services)) necessary for the in-
tennded operattion. The opperating system must be config-
ured securely and run wiith least priv
vilege.
PCI Thhe vendor must
m providee adequate documented
d d security PCIB19
guuidance for the
t integrati
tion of any secure
s comp
ponent into
a PIN
P entry POIP Terminaal.
PCI A user-availaable securityy policy from m the vendo or addressess PCIB20
thee proper usee of the POII in a securee fashion, in ncluding in--
forrmation on key-managgement respo onsibilities,, adminis-
traative respon
nsibilities, ddevice functionality, ideentification,,
annd environm mental requirrements. Th he security policy
p mustt
deefine the roles supporteed by the PO OI and indiccate the ser--
vicces availablle for each rrole in a detterministic tabular
t
forrmat. The POI
P is capabble of perforrming only its de-
siggned functioons - i.e., thhere is no hiidden functiionality.
Thhe only apprroved functtions perform med by the POI are
thoose allowedd by the poliicy.
Online PIN Securrity Requireements
PCI If the device can
c hold muultiple PIN--encryption keys and iff PCIC1
thee key to be used to enccrypt the PINN can be ex
xternally se--
leccted, then th
he device prrohibits unaauthorized key
k re-
plaacement and key misusse.
Offlline PIN Seecurity Req
quirementss
PCI It is neither feeasible to peenetrate thee ICC readerr to make PCID1
anny additions, substitutioons, or modifications to o either the
IC
CC reader’s hardware oor software, in order to determine
or modify any y sensitive ddata, withou ut requiring an attack
pootential of att least 20 foor identificaation and iniitial exploi-
tattion, with a minimum oof 10 for ex xploitation, nor
n is it
poossible for both
b an IC ccard and any y other foreiign object
to reside withhin the card insertion sllot. Note: All attacks
shhall include a minimum m of ten hourrs’ attack tim me for ex-
plooitation.
PCI Thhe opening for
f the inserrtion of the IC card is in
i full view PCID2
off the cardhollder during card insertiion so that any
a unto-
waard obstructtions or susppicious objeects at the opening
o are
deetectable.
th
4 Page 205
POI P
Protection Profile
Class EP
Requiremen
nts Numberr
Core Ph
uirements
PCI Thhe ICC read der is constru
ructed so thaat wires run nning out off PCID3
thee slot of thee IC reader tto a recordeer or a transm
mitter (an
exxternal bug) can be obseerved by the cardholdeer.
PCI PIIN protectio
on during traansmission within the PED
P (at PCID4
leaast must com
mply):
If the devicce encryptinng the PIN and the ICC
C reader aree
not integraated into thee same secure module, and the
cardholderr verificationn method iss determined
d to be:
- An en
nciphered PIIN, the PIN block shalll be enci- PCID4.1
1
phered between thee device enccrypting thee PIN and
the ICC
C reader usinng either an
n authenticatted enci-
pherment key of thhe IC card, or
o in accorddance with
ISO 95664.
- A plaiintext PIN, tthe PIN blo
ock shall be encipheredd PCID4.2
2
from the device enncrypting thee PIN to thee ICC read-
er (the ICC
I reader will then deecipher the PIN for
transmission in plaaintext to the IC card) in accord-
ance wiith ISO 95664.
If the devicce encryptinng the PIN and the ICCC reader aree
integrated into the samme secure module,
m and the card-
holder veriification meethod is deteermined to be:
b
- An en
nciphered PIIN, the PIN block shalll be enci- PCID4.3
3
phered using an auuthenticated encipherment key of
the IC card.
c
- - A plaaintext PIN
N, then encippherment is not re- 4
PCID4.4
quired if
i the PIN bblock is tran
nsmitted who olly
throughh a protectedd environmeent (as definned in ISO
9564). If
I the plainttext PIN is transmitted
t to the ICC
reader through
t an uunprotected
d environmeent, the PIN
N
block shhall be enciiphered in accordance with
w ISO
9564.
POS Teerminal Inttegration - Configuraation Manag
gement
EPC L requiremen nts must be cchecked by the testing lab. This EPCPlusL0
PLUS inccludes a perriodic site vvisit regardin
ng critical steps
s in the
maanufacturing process (ee.g. initial key
k loading)).
PCI Chhange-contrrol procedurres are in pllace so that any intend-- PCIL1
edd security-reelevant channge to the phhysical or functional
fu
caapabilities of the devicee causes a ree-certificatio
on of the
deevice under the Core PIIN Entry an nd/or POS Terminal
T In--
teggration Secu urity Requirrements of this
t documeent.
th
4 6 March,
M 2015
POI P
Protection Profile
Class EP
Requiremen
nts Numberr
Core Ph
uirements
PCI Thhe certified firmware iss protected and
a stored in i such a PCIL2
maanner as to preclude unnauthorized modificatio on during
itss entire man
nufacturing llife cycle–ee.g., by usin
ng dual con--
trool or standarrdized crypttographic auuthenticatio
on proce-
duures.
PCI Thhe device is assembled in a manneer that the co omponents PCIL3
used in the manufacturinng process are a those com mponents
thaat were certtified by thee Core PIN Entry and/oor POS
Teerminal Inteegration Seccurity Requiirements ev valuation,
annd that unau
uthorized sub ubstitutions have
h not been made.
PCI Prroduction so oftware (e.gg., firmware) that is loaded to de- PCIL4
vicces at the tim
me of manuufacture is transported,
t stored, andd
used under th he principle of dual conntrol, prevennting unau-
thoorized modiifications annd/or substiitutions.
PCI Suubsequent to o productionn but prior to
t shipmentt from the PCIL5
maanufacturer’s or reselleer’s facility,, the device and any off
itss componen nts are storedd in a proteccted, accesss-controlledd
areea or sealed
d within tammper-eviden nt packaging g to preventt
unndetected unnauthorizedd access to th he device orr its com-
poonents.
PCI If the device will
w be authhenticated att the key-loading facil-- PCIL6
ityy or the facility of initiaal deploymeent by mean ns of secret
infformation placed
p in thee device durring manufaacturing,
theen this secreet informatiion is uniquue to each deevice, un-
knnown and un npredictablee to any perrson, and insstalled in
thee device under dual conntrol to ensu ure that it iss not dis-
cloosed during g installationn.
PCI Seecurity meassures are takken during the develop pment and PCIL7
maaintenance of POI secuurity related d components. The
maanufacturer must mainttain develop pment securrity docu-
meentation desscribing all the physicaal, procedural, person-
neel, and otherr security mmeasures thaat are necesssary to pro-
tecct the integrrity of the ddesign and im
mplementattion of the
POOI security-related com mponents in their develo opment en-
virronment. Th he developm ment securitty documen ntation shalll
provide evideence that theese security y measures are
a followedd
duuring the dev velopment aand mainten nance of thee POI secu-
ritty-related co
omponents. The eviden nce shall jusstify that thee
security meassures providde the necesssary level of o protec-
tioon to maintaain the integgrity of the POI
P security-related
coomponents.
PCI Coontrols existt over the reepair processs and the in
nspec- PCIL8
th
4 Page 207
POI P
Protection Profile
Class EP
Requiremen
nts Numberr
Core Ph
tioon/testing prrocess subseequent to reepair to ensu
ure that the
deevice has noot been subjeect to unautthorized mo odification.
EPC M requiremen nts must be checked by y the testingg lab. This EPC Plu
usM0
PLUS inccludes a perriodic site vvisit regardin
ng critical steps
s in the
maanufacturing process (ee.g. initial key-loading)
k ).
PCI Thhe POI shou uld be proteected from unauthorized
u d modifica-- PCIM1
tioon with tamp per-evidentt security feeatures, and customers
shhall be proviided with doocumentatio on (both shiipped with
thee product an nd availablee securely online)
o that provides
p in--
strruction on validating
v thhe authenticcity and inteegrity of thee
POOI.
W
Where this is not possiblle, the POI isi shipped from
f the
maanufacturer’s facility too the initial key-loading facility orr
to the facility of initial deeployment anda stored en e route un--
deer auditable controls thaat can accou unt for the location
l of
evvery POI at every pointt in time.
W
Where multipple parties aare involved d in organiziing the
shhipping, it iss the responnsibility of each
e party to
o ensure
thaat the shippping and storrage they arre managing g is compli--
annt with this requirement
r t.
PCI Prrocedures arre in place tto transfer accountabili
a ty for the PCIM2
deevice from the manufaccturer to thee facility.
PCI While in transsit from thee manufactu
W urer’s facility to the ini-- PCIM3
tiaal key-loadinng facility, the device is:
i
- Shipped
S andd stored in ttamper-evid dent packagiing; and/or
- Shipped
S andd stored conntaining a seecret that is immediate--
ly and automaatically erassed if any ph hysical or functional
f
altteration to the device iss attempted, that can bee verified
byy the initial key-loading
k g facility, bu
ut that cann
not feasibly
bee determined d by unauthhorized perssonnel.
PCI Thhe device’s developmennt security documentat
d tion must PCIM4
provide mean ns to the inittial key-load
ding facility
y to assure
thee authenticiity of the TO
OE’s security relevant compo-
neents.
PCI If the manufaacturer is in charge of in
nitial key-lo
oading, thenn PCIM5
thee manufactuurer must veerify the au
uthenticity of the POI
security-relateed componeents.
PCI If the manufaacturer is noot in charge of initial keey-loading, PCIM6
thee manufactu urer must prrovide the means
m to thee initial
keey-loading facility
f to asssure the verification off the au-
theenticity of the
t POI secuurity-related d componen nts.
th
4 6 March,
M 2015
POI P
Protection Profile
Class EP
Requiremen
nts Numberr
Core Ph
uirements
PCI Eaach device shall
s have a unique visiible identifiier affixed PCIM7
to it.
PCI Thhe vendor must
m maintaiin a manuall that provid des instruc- PCIM8
tioons for the operational
o managemen nt of the POOI. This in-
cluudes instrucctions for reecording thee entire life cycle of thee
POOI security-related com mponents an nd of the maanner in
whhich those components
c s are integraated into a single POI,
e.gg.:
- Data
D on production andd personalizzation
- Physical/chr
P ronological whereabou uts
- Repair
R and maintenanc
m e
- Removal
R fro
om operatioon
- Loss
L or thefft
PLUS Auuthenticity and
a integritty of paymeent transactions. Ven- EPCN1
doors must com
mply with aall requirem
ments of G1.
PLUS Thhe POI must have the ccapacity to protect
p commmunica- EPCN1..1
tioons over extternal comm
munication channels,
c meaning
m thatt
POOI security components
c s must provvide cryptoggraphic
meeans:
- To
T protect all
a transactioons data sen
nt or receiveed by the
POOI against modification
m n
- To
T protect all
a transactioon data sentt or received
d by the
POOI against disclosure
d
- For
F the POI to be uniquuely authentticated by th he external
enntity it comm
municates wwith.
PLUS Thhe transactio
on/accountiing data shaall be handleed with au- EPCN1..2
theenticity and
d integrity inn the POI.
PLUS POOI managem ment data m
must be provvided to the POI in an EPCN1..3
auuthentic way
y and must bbe protected
d against un
nauthorized
chhange.
PLUS Appplication in
ntegrity viaa application
n separation
n. Vendors EPCN2
muust comply with all reqquirements ofo EPCN2.
PLUS Thhe security of
o payment application n in the POI must not EPCN2..1
bee impacted by
b any otherr application. Payment applicationn
isoolation shalll be ensuredd: no other application
a shall have
unnauthorized access to p ayment app plication datta (any dataa:
traansaction daata, manageement data, non-PIN keeys, en-
cryypted PIN)
PLUS Thhe security of
o payment application n in the POI must not EPCN2..2
bee impacted by
b any otherr application. Payment applicationn
th
4 Page 209
POI P
Protection Profile
Class EP
Requiremen
nts Numberr
Core Ph
isoolation shalll be ensuredd: it shall no
ot be possib
ble for an-
othher applicattion to interrfere with thhe execution n of the
paayment appllication, by accessing in nternal dataa (such as
staate machinee or internall variables).
PLUS Paayment appllication isollation shall be
b ensured: it shall nott EPCN2..3
bee possible fo
or another ap
application to
t deceive thhe Card-
hoolder duringg execution oof the paym
ment applicaation, by ac--
ceessing Cardh holder comm munication interface (ee.g. display,,
beeeper, printeer) used by tthe paymen
nt applicatio
on.
PLUS Auuthenticity and
a integritty of POI so
oftware. Ven
ndors must EPCN3
coomply with all
a requirem
ments of G3.
PLUS PO
OI software must be proovided to th he POI in an
n authentic EPCN.3.1
waay and mustt be protecteed against unauthorize
u d change.
PLUS If the POI imp plements sooftware upd dates, a POI security- EPCN3..2
rellated compo onent cryptoographically y authenticaates the
sooftware integgrity and it the authentiicity is not confirmed,
c
thee software update
u is rejjected or alll secret cryp
ptographic
keeys are eraseed.
PLUS Too determine any non-PIIN secret keey in a POI security- EPCN4
rellated compo onents, by aany means, including penetration
annd including g crypto-anaalysis, requiires an attacck potential
off at least 16 for identificcation and initial
i explo
oitation as
deefined in Ap ppendix B oof the PCI POS DTRs.
PLUS Too defeat a mechanism
m ((hardware or
o software) in a POI EPCN5
security-relateed componeent, by any means, inclluding mod--
ifiication of pu
ublic keys, rrequires an attack potential of at
leaast 16 for id
dentificationn and initiall exploitatio
on as de-
finned in Appeendix B of ththe PCI POS S DTRs.
PLUS Thhe key manaagement tecchniques immplemented in a POI EPCN6
security-relateed componeent conform
m to ISO 115
568 and/or
ANNSI X9.24
Noote: This req
quirement ddoes not sup
pplement PC
CIB11
whhose scope is the PED.
PLUS Thhe functionaality of a PO
OI security-related com
mponent EPCN7
shhall not be in
nfluenced bby logical an
nomalies such as (but
noot limited to
o) unexpecteed command d sequencess, unknownn
coommands, co ommands inn a wrong device
d modee and sup-
plyying wrong parameterss or data wh hich could result in a
breach of the security reqquirements.
th
4 6 March,
M 2015
POI P
Protection Profile
13.2 Map
pping from
m EPC Book
k 4 to SFRs and SARs
670 The following table show ws the mappping betweeen EPC requ uirements ffrom [EPC B4] and
secuurity requireements in this
t PP. EP PCN requirements are not all expplicitly included in
[EPC C B4] but derived
d fromm chap. 2.77 especiallyy considerin ng the appliicability of require-
mennts. All linkks except lin
nks to AVA A_POI can be b traced back to the sstatement of o the re-
quirrements in this
t PP. SRE ED is not coovered in th
his chapter, cf. section 12. SFR-supporting
featuures due to Open Proto ocols are alsso not coverred in this chapter.
c
CAS- SFR SAR

requirrement
PCIA11 FPT_PH
HP.3/CoreT
TSF
PCIA22 ADV_ARC
C.1
PCIA33 FPT_PH
HP.3/CoreT
TSF
PCIA44 ADV_ARC
C.1
PCIA55 FPT_EM
MSEC.1/PIN
N_ENTRY
Y
PCIA66 FPT_PH
HP.3/CoreT
TSF,
FPT_EM
MSEC.1/CooreTSF
EPC-C
CHIP- FPT_PH
HP.3/CHIP--ONLY
ONLYYA6 FPT_EM
MSEC.1/CHHIP-ONLY
PCIA77 FDP_ACC.1/PEDP
PromptConttrol,
FDP_ACF.1/PEDP
PromptConttrol
PCI NeewA8 Outsidee the CC evaaluation (ob
bjective for the environnment)
EPCA8.a
PCIA99 FPT_PH
HP.3/MSR
PCIA110 ADV_ARC
C.1
PCIA111 FPT_EM
MSEC.1/PIN
N_ENTRY
Y
PCIB11 FPT_TS
ST.1/ PEDM
MiddleTSF,
FPT_FL
LS.1/ PEDM
MiddleTSF,
FPT_TS
ST.1/CoreT
TSF,
FPT_FL
LS.1/CoreT SF
PCIB22 FDP_IT
TC.1/PEDMMiddleTSFLLoader,
FPT_FL
LS.1/ PEDM
MiddleTSF,
FPT_FL
LS.1/CoreT SF,
FDP_IT
TC.1/CoreT SFLoader
PCIB33 ALC_CMSS.2
EPC P
PlusB3.a Covered
d by the CC
C evaluation
n
th
4 Page 211
POI P
Protection Profile
CAS- SFR SAR

requirrement
PCIB44 FDP_IT
TC.1/CoreT SFLoader,
FDP_IT
TC.1/PEDMMiddleTSFLLoader
PCIB44.1 FDP_ACC.1/ AppllicationLoadder,
FDP_IT
TC.1/ AppliccationLoad
der
PCIB55 FPT_EM
MSEC.1/PIN
N_ENTRY
Y
PCIB66 FDP_IF
FF.1/ENC_P PIN,
FDP_RIIP.1/ENC_P PIN,
FDP_RIIP.1/PLAIN
N_PIN,
FDP_RIIP.1/ICCarddReader
PCIB77 FIA_UA
AU.2/PIN_E
ENTRY
PCIB88 FTA_SS
SL.3/PIN_E
ENTRY
PCIB99 FCS_RN
ND.1
PCIB110 FDP_IF
FF.1/ENC_P
PIN,
FCS_COOP.1
EPC P
PlusB10.a FDP_IF
FF.1/ENC_P
PIN,
FCS_COOP.1
PCIB111 FDP_IT
TC.2, FTP_IITC.1/Cryp
pto,
FPT_TD
DC.1
PCIB112 FCS_CO
OP.1
PCIB113 FDP_IF
FF.1/ENC_P
PIN
PCIB114 FDP_IF
FF.1/ENC_P PIN,
FDP_IF
FF.1/PLAIN
N_PIN,
FDP_IF
FF.1/ICCarddReader
PCIB115 FDP_IT
TC.1/PIN_E
ENTRY
PCIB116 FDP_ACC.1/PEDP
PromptConttrol, ADV_ARC
C.1
FDP_ACF.1/PEDP
PromptConttrol
EPC-C
CHIP- FDP_ACC.1/PEDP
PromptConttrol, ADV_ARC
C.1
ONLYYB16 FDP_ACF.1/PEDP
PromptConttrol
PCIB117 FDP_ACF.1/POI_D
DATA
PCIB118 ADV_ARC
C.1
PCIB119 AGD_OPE
E.1
PCIB220 ADV_ARC
C.1
AGD_OPE
E.1
PCIC11 FTP_TR
RP.1/ENC__PIN
PCID11 FPT_PH
HP.3/ICCarrdReader (no
ot cover- ADV_ARC
C.1
th
4 6 March,
M 2015
POI P
Protection Profile
CAS- SFR SAR

requirrement
ing inseertion slot reequirement))
PCID22 ADV, ARC

C.1
AGD_OPEE.1
PCID33 ADV_ARC
C.1
PCID44.1 FDP_IF
FF.1/ENC_P
PIN,
FCS_COOP.1
PCID44.2 FDP_IF
FF.1/PLAIN
N_PIN,
FDP_IF
FF.1/ICCarddReader,
FCS_COOP.1
PCID44.3 FDP_IF
FF.1/ENC_P
PIN
PCID44.4 FDP_IF
FF.1/PLAIN
N_PIN,
FDP_IF
FF.1/ICCarddReader,
FCS_COOP.1
In the ffollowing reequirements ‘device’ rreflects the PED
P and the POI securrity-related com-
po-nennts. In termss of Commoon Criteria ssecurity-relaated means SFR-enforccing.
EPC P
PlusL0 ALC_DVSS.2
PCIL1 Re-evaluattion issues are
a out
of scope. T
The PP stands by
EPC P
PLUS L1.a
CC mainteenance process.
PCIL22 ALC_DVSS.2
PCIL3 ALC_DVSS.2
PCIL44a ALC_DVSS.2
PCIL55 ALC_DVSS.2
PCIL66 ALC_DVSS.2
PCIL77 ALC_DVSS.2
PCIL88 ALC_DVSS.2
PCIM11 ALC_DVSS.2
PCIM22 ALC_DVSS.2
PCIM33 ALC_DVSS.2
PCIM44 ALC_DVSS.2
PCIM55 ALC_DVSS.2
PCIM66 ALC_DVSS.2
PCIM77 ALC_CMC
C.2
th
4 Page 213
POI P
Protection Profile
CAS- SFR SAR

requirrement
PCIM88 AGD_OPE
E.1
EPCN1.1 FDP_UIT.1/POI_D
DAT,
FDP_UCT.1/POI_DDATA,
FTP_IT
TC.1/POI_D
DATA
EPCN1.2 FDP_IT
TT.1/POI_D
DATA
EPCN1.3 FDP_IT
TT.1/POI_D
DATA ,
FDP_UIT.1/POI_D
DAT
EPCN22.1 FDP_RIIP.1/POI_D
DATA, ADV_ARC
C.1
FDP_ACF.1/POI_D DATA
DATA, ADV_ARC
C.1
DATA, ADV_ARC
C.1
EPCN33.1 FDP_IT
TC.1/MiddleeTSFLoadeer
FDP_IT
TC.1/AppliccationLoadeer
EPCN33.2 FDP_IT
TC.1/MiddleeTSFLoadeer
FDP_IT
TC.1/AppliccationLoadeer
EPCN44 FDP_IT
TT.1/POI_D
DATA,
FDP_UCT.1/POI_DDATA,
FTP_IT
TC.1/POI_D
DATA
EPCN55 Covered
d by the CC
C evaluation
n
EPCN66 FDP_IT
TC.2,
FTP_IT
TC.1/Cryptoo,
FPT_TD
DC.1
EPCN77 FPT_FL
LS.1/MiddleeTSF
th
4 6 March,
M 2015
POI P
Protection Profile
14 Ann
nex – Relattionship bettween AVA
A_POI and AVA_VAN
N.2 familiees
671 The relationshiip between AVA_VAN N.2 and thee requiremen nts of the eextended AV
VA_POI
fam
mily is essenntially one of
o refinemennt, as demoonstrated in the discusssion below. Howev-
er, tthe suitability of AVA_
_POI.1 as a substitutio
on in EAL POIP for AVA A_VAN.2 ini EAL2
alsoo relies on the interprretation of CC “Basicc” attack po otential (whhich is reqquired in
AVA A_VAN.2) as within th he limits off “POI-Basicc”, defined in [POI AtttackPot].
672 We assume thaat the points needed to rreach Basicc level in thee context off POI evaluaation are
loweer or equal than the po
oints neededd to reach th
he POI-Basic level (thiis can be co onfirmed
by cconsulting [POI
[ Attack
kPot]). Thiss assumption does not affect the ggenerality ofo the ar-
gum
mentation sinnce both Basic and PO OI-Basic are the lowesst levels in the attack potential
p
scales.
673 Let us show thaat AVA_PO OI.1 is a refi
finement of AVA_VAN
A N.2 for the PPOI compon
nents se-
lecteed in the insstantiation of
o AVA_PO OI.1.1D:
 AVA_PO OI.1.1D: Th his is the saame as AV VA_VAN.2.1D, restriccted to the selected
POI compponents.
 AVA_PO OI.1.2D: This
T is aan addition nal elemen nt, withouut counterrpart in
AVA_VA AN.2, that allows
a to reequire impleementation representati
r ion informaation and
the mappping to SFR Rs to be useed by the evaluator du uring the vuulnerability analysis
(cf. AVAA_POI.1.3E)). Formally,, this elemen nt is a refinement of A AVA_VAN.2 2.1D.
 AVA_PO OI.1.1C: Thiis is the sam me as AVA_ _VAN.2.1C C, restrictedd to the seleccted POI
components
 AVA_PO OI.1.1E: Thiis is the samme as AVA_ _VAN.2.1E E.
 AVA_PO OI.1.2E: Thiis is the sam me as AVA_ _VAN.2.2E E, restricted to the seleccted POI
components.
 AVA_PO OI.1.3E: Thiis is a refinnement of AVA_VAN.
A 2.3E, restriicted to the selected
POI compponents, thaat introducees the use off the availab ble implemeentation rep presenta-
tion and mapping
m to SFRs durinng the vulneerabilities an nalysis.
 AVA_PO OI.1.4E: Thiis is a refinnement of AVA_VAN.
A 2.4E, restriicted to the selected
POI comp
mponents, an nd allowingg any of the POI attack k potential tthresholds to t be as-
signed. Inn addition, it allows (ooptionally) certain more specific requiremen nts to be
stated onn parts of th
he attack pootential calcculation, to enable an author to set s mini-
mum threesholds for exploitation
e n aspects, fo
or example. The minim mum attack potential
p
that can be
b specified d in this elem ment is POII-Basic whiich replacess standard CC C Basic
attack pootential. By assumptionn Basic atttack potentiial is weakeer than or equal to
POI-Basiic attack po otential leveel, hence th he new req quirement iss stronger than the
original one.
o
674 In E
EAL POI, each POI co omponent inn the scope of the evalluation is adddressed by
y at least
one AVA_POI.1 iteraton: POI compoonents belon ng to one of the TSF pparts CoreTSFKeys,
CoreeTSF, PED D MiddleTSF F, MiddleT
TSF or MSR R and each of
o these parrts are addreessed by
at leeast one iteeration of AVA_POI.1
A . Hence, th
he set of AV
VA_POI iteerations inccluded in
EAL L POI consttitutes a refiinement of A
AVA_VAN N.2 applied to the wholle POI.
th
4 Page 215

Anssi Profil PP 2015 01à06

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

Anssi Profil PP 2015 01à06

Uploaded by

Copyright:

Available Formats

Point oof Interraction

Datee: 6th March 2015

Table oof contents

Table oof figures

Table oof tables

Table 1: TSF decom mposition by b base PP ...................................................................................... 30

1 Thiss documentt defines six x base Proteection Profifiles dedicatted to paym

1.1 Prottection Pro

Title Point of Inteeraction Prootection Pro

Title Point of Interaction Prootection Pro

Title Point of Interaction Prootection Pro

Title Point of Inteeraction Prootection Pro

Title Point of Inteeraction Prootection Pro

Note thaat the three base PPs deerived from

4 Thiss Protectionn Profile (PP

2 In otherr words: The PED-ONLY

Include SRED yes Is SRED

Include Open Protocol

25 The TOE is a product

Figure 2: Relations between vaarious defin

3.2.1.1 Generic Payment

28 The following figure show

10. Isssuer payment

8. Ask for paym

2. to 5. Paymeent transaction datta, managment

POI 3. PIN requestt 5. Transactio

4. PIN (if ooffline PIN verificattion)

29 Afteer the POI payment transaction

3.2.1.2 Generic Terminal

30 The generic Teerminal Man

2. TThe TMS sends

3. TThe internaal state of th

3.2.1.3 Generic POI

Fiigure 4: Geeneric POI Architectu

3.2.1.4 Generic POI

a) POI Ap pplication Logic

b) Applicaations. The objective oof a POI is to

 Carrd Readers: devices thhat provide interfaces

 Carrdholder Verification Devices (C CHV): devicces for Carrdholder autthentica-

d) Externaal IT Entitties. POI m

3.2.1.5 POI Exam

33 Figuure 5, Figurre 6 and Figure 7 show the minimu um set of co

Application Application Application

ICC User Input/Ouutput Mag

4This Prootection Profile addresses security

PIN entry and processing of PIN

Figure 9: TSF structure in P

39 The TSF parts define the logical

49 Table 1 definess the logicaal boundariees of each base

PPP Core- CoreTSFK

51 Appplication noote: The IC Card Readder SM is not requireed in integrrated architectures,

54 There is no nonn-TOE hard

55 The TOE is intended to bee used in paayment enviironments. The

56 The main phasees of the TO

3.5.1 Devveloper pha

62 POII developmeent and man

63 Durring manufaacturing, thee POI is asssembled, po owered on and

64 Softtware load agents

3.5.2 Userr phase

- configurration with specific parrameters,

- mutual recognitionn of POI coomponents (allowing

- test of thhe whole PO

- installattion of the address o f each Acq

3.5.2.2 Acquirer Initialisatiion