TÜBİTAK BİLGEM
National Research Center of Electronics and Cryptography
Common Criteria Protection Profile for
Application Firmware of
Secure Smartcard Reader for
National Electronic Identity Verification System
Revision No
2.5
Revision Date
09.11.2015
Document Code
SSR_PP_2.5
File Name
Protection Profile for Application Firmware of Secure Smartcard Reader (SSR) for
National electronic Identity Verification System
Prepared by
eID Applications Unit
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 2.thpage of 101pages
CONTENTS
1 PP Introduction................................................................................................................................ 6
1.1 PP Reference ........................................................................................................................... 6
1.2 TOE Overview.......................................................................................................................... 6
1.2.1 Major Security Features of a TOE.................................................................................... 6
1.2.2 Types of SSR Devices ....................................................................................................... 7
1.2.3 Non TOE Hardware/ Software/ Firmware....................................................................... 8
1.2.4 Actors and External Systems ......................................................................................... 10
1.2.5 Operational Environments of SSR ................................................................................. 10
1.2.6 TOE Life Cycle ................................................................................................................ 14
2 Conformance Claims...................................................................................................................... 16
2.1 CC Conformance Claim.......................................................................................................... 16
2.2 PP Claim................................................................................................................................. 16
2.3 Package Claim........................................................................................................................ 16
2.4 Conformance Rationale......................................................................................................... 16
2.5 Conformance Statement ....................................................................................................... 16
3 Security Problem Definition .......................................................................................................... 17
3.1 Factors Effecting the Security Problem Definition ................................................................ 17
3.2 Assets..................................................................................................................................... 17
3.3 Subjects and External Entities ............................................................................................... 19
3.4 Relevance of External Entities to the TOE on Different SSR Types ....................................... 21
3.5 Threats................................................................................................................................... 21
3.6 Organizational Security Policies ............................................................................................ 25
3.7 Assumptions.......................................................................................................................... 26
3.8 Relevance of Threats, OSPs and Assumptions to the TOE on Different SSR Types............... 28
4 Security Objectives........................................................................................................................ 30
4.1 Security Objectives for the TOE............................................................................................. 30
4.2 Security Objectives for the Operational Environment.......................................................... 35
4.3 Application of Security Objectives to the TOE on Different SSR Types................................. 41
4.4 Coverage Of Threats, OSPs and Assumptions by the Security Objectives ............................ 45
4.5 Security Objectives Rationale................................................................................................ 52
5 Extended Components Definition ................................................................................................. 59
5.1 FPT_IDA Imported TSF Data Authentication......................................................................... 59
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 3.thpage of 101pages
5.1.1 FPT_IDA.1 Imported TSF Data Authentication .............................................................. 59
5.2 FPT_EMSEC TOE Emanation.................................................................................................. 60
5.2.1 FPT_EMSEC.1 TOE Emanation....................................................................................... 60
5.3 FPT_SSY State Synchronization ............................................................................................. 61
5.3.1 FPT_SSY.1 State Synchronization .................................................................................. 61
6 Security Requirements .................................................................................................................. 62
6.1 Security Functional Requirements ........................................................................................ 62
6.1.1 Class FAU: Security Audit............................................................................................... 62
6.1.2 Class FCS: Cryptographic Support.................................................................................. 64
6.1.3 Class FIA: Identification and Authentication ................................................................. 70
6.1.4 Class FCO: Communication............................................................................................ 74
6.1.5 Class FMT: Security Management................................................................................. 74
6.1.6 Class FPT: Protection of the TSF .................................................................................... 77
6.1.7 Class FDP: User Data Protection.................................................................................... 81
6.1.8 Class FTP: Trusted Path/Channels ................................................................................. 85
6.2 Application of SFRs to TOE on different SSR Types and Biometric Sensor / EPP
Configurations................................................................................................................................... 85
6.3 Security Assurance Requirements......................................................................................... 86
6.4 Security Requirements Rationale.......................................................................................... 86
6.4.1 Security Functional Requirements Rationale ................................................................ 86
6.4.2 Security Functional Requirements Rationale Tables..................................................... 91
6.4.3 Security Assurance Requirements Rationale................................................................. 97
7 Glossary and Acronyms................................................................................................................. 98
7.1 Glossary ................................................................................................................................. 98
7.2 Acronyms............................................................................................................................... 99
7.3 References........................................................................................................................... 100
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 4.thpage of 101pages
LIST OF TABLES
Table 1. Comparison of SSR types........................................................................................................... 7
Table 2. Primary and Secondary Assets................................................................................................. 17
Table 3. Legitimate and malicious actors and external systems........................................................... 19
Table 4. Legitimate Entities vs SSR Types.............................................................................................. 21
Table 5. Threats..................................................................................................................................... 21
Table 6. Organizational security policies............................................................................................... 25
Table 7. Assumptions ............................................................................................................................ 26
Table 8. Relevance of Threats, OSPs and Assumptions to the three TOE types ................................... 28
Table 9. Security Objectives of the TOE ................................................................................................ 30
Table 10. Security Objectives for the Operational Environment .......................................................... 35
Table 11. Application of Objectives to the TOE on different SSR Types ............................................... 41
Table 12. Application of Environment Objectives to the different SSR Types and User Environments of
different SSR Types................................................................................................................................ 43
Table 13. Security Objectives Rationale Table for TOE on Either SSR Type I,II,II without Biometric
Sensor and External Pin Pad.................................................................................................................. 45
Table 14. Environmental Security Objectives Rationale Table for TOE on Either SSR Type I,II,II without
External Biometric Sensor and External Pin Pad................................................................................... 48
Table 15. Additions to Security Objective Rationale due to differences of SSR Type II, III from SSR Type
I.............................................................................................................................................................. 50
Table 16. Additions to Security Objective Rationale for TOE on SSR with External/Internal Biometric
Sensor and/or EPP................................................................................................................................. 51
Table17. SFR Rationale Table for TOE on SSR Type I without Biometric Sensor and External PIN Pad 91
Table18: SFR Rationale for additional objectives of TOE on SSR Type II and SSR Type III .................... 95
Table19: SFR rationale additions for TOE on SSR with External/Internal Biometric Sensor and/or EPP
............................................................................................................................................................... 95
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 5.thpage of 101pages
LIST OF FIGURES
Figure 1. Typical Software/Firmware Environment of TOE.................................................................... 8
Figure 2. Typical SSR Hardware.............................................................................................................. 9
Figure 3. User Environment of Type I................................................................................................... 11
Figure 4. User Environment of Type II (without SAS)........................................................................... 12
Figure 5. User Environment of Type II (with SAS) ................................................................................ 13
Figure 6. User Environment of Type III................................................................................................. 14
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 6.thpage of 101pages
1 PP INTRODUCTION
1.1 PP REFERENCE
Title: Protection Profile for Application Firmware of Secure Smartcard Reader for National Electronic
Identity Verification System
CC Version: 3.1 (Revision 4)
Assurance Level: EAL4+ with ALC_DVS.2 augmentation
Version Number: v2.5
Keywords: Electronic Identity, Smartcard Reader, Identity Verification, Electronic Identity Card,
Secure Smartcard Reader, Biometric Authentication
1.2 TOE OVERVIEW
The TOE is the Secure Smartcard Reader (SSR) Application Firmware running on SSR Device. The SSR
is the identity verification terminal for the National eID Verification System (eIT.DVS). As the
application firmware of the SSR, the TOE performs identity verification of Service Requester and
Service Attendee according to the eIDVS, securely communicating with the other system components
and as a result of the identity verification, produces an Identity Verification Assertion (IVA) signed by
the Secure Access Module (SAM) inside the SRR. The root certificates used for the identification &
authentication purposes are also covered by the TOE
1.2.1 MAJOR SECURITY FEATURES OF A TOE
The following security mechanisms are primarily mediated in the TOE:
 Identification and Authentication,
 Cardholder verification by using PIN and biometrics (fingerprint, finger vein,
or palm vein data).
 Authentication of eID Card by the TOE,
 Authentication of Role Holder by eID Card and by the TOE,
 Authentication of SAM by the TOE and by eID Card,
 Authentication of the TOE by SAM and by Card Holder (Service Requester
and Service Attendee) and by external entities (e.g. EPP, EBS, Role Holder,
etc.),
 Secure Communication between the TOE and
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 7.thpage of 101pages
 SAM
 eID Card
 Role Holder
 other trusted IT Components
 Security Management,
 Self-Protection,
 Audit.
Among the certificates used in the National eID Verification System, certificates of the root CA,
device management CA and eID management CA are included in the TOE.
1.2.2 TYPES OF SSR DEVICES
This Protection Profile supports TOE on three different operational environments. Operation
environment is the SSR Hardware and SSR User Environment including the other parties that SSR
communicates to the SSR Application Firmware.
Properties of the three operational environments are compared in Table 1.
Table 1. Comparison of SSR types
Type I Type II Type III
User Interface of SSR
Device
Pinpad,
Display,
One smartcard slot,
Biometric sensor
(internal, external or
does not exist)
External pinpad
(optional)
Pinpad,
Display,
Two smartcard slots,
Biometric sensor
(internal, external or
does not exist)
External pinpad
(optional)
Pinpad,
Display,
One or two smartcard
slots,
Biometric sensor
(internal, external or
does not exist)
External pinpad
(optional)
Service Provider Client
Application (SPCA)
Running on PC Running on PC Included in the TOE
SSR Access Server
(SAS)
N/A Optional N/A
Communication
Environment of SSR
SSR communicates to
Service Provider Client
Application (SPCA)
through USB
Interface. SPCA
SSR communicates to
Service Provider Client
Application through
USB interface or
communicates to SAS
SSR directly
communicates to
IVPS / APS/ OCSPS
through wireless
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 8.thpage of 101pages
communicates to
Identity Verification
Policy Server (IVPS) /
Application Server
(APS)/ Online
Certificate Status
Protocol Server
(OCSPS).
through Ethernet
interface. SPCA or SAS
communicates to IVPS
/ APS/ OCSPS.
interface.
Service Attendee
Support
N/A Yes Optional
Secure Upgrade Yes Yes Yes
Optional
Online/Offline Mode
Offline Certificate
Validation using
Certificate Revocation
List when the OCSP
Server isn’t reached
Offline Certificate
Validation using
Certificate Revocation
List when the OCSP
Server isn’t reached
Offline Certificate
Validation using
Certificate Revocation
List when the OCSP
Server isn’t reached
Storing Identity
Verification Assertions
when the connection
is failed
There are two offline use cases: (i) offline revocation list control and (ii) offline IVA generation &
storage. In first use case, only the certificate status control is performed offline, other identity
verification steps are performed online. As it is explained in Table 1, this use case could be included
in all three types of SSR Devices when OCSPS could not be reached. On the other hand, the second
use case is an option only for SSR Type III Devices. If the SSR type III Device has the offline IVA
generation and storage mode, the IVA can be generated and stored within the SSR when the SSR can
not reach to the APS. The confidentiality and the integrity of the IVAs shall be assured during storage.
1.2.3 NON TOE HARDWARE/ SOFTWARE/ FIRMWARE
1.2.3.1 Typical Software/ Firmware Environment of TOE
File System and Software Libraries
Embedded Operating System Kernel
Smartcard Reader IC Firmware
Figure 1. Typical Software/Firmware Environment of TOE
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 9.thpage of 101pages
In a typical software environment, the TOE runs at the top of an embedded operating system, its file-
system and software libraries. It communicates to a smartcard reader IC firmware within the device.
Other possible applications that could run on the SSR Device are not defined in this protection
profile.
1.2.3.2 Hardware Environment of TOE (SSR Hardware)
The TOE is stored in a non-volatile memory location in the SSR Hardware as an encrypted binary file.
During power-up, the encrypted TOE is decrypted before its execution. A Typical SSR Hardware
environment of TOE is shown in Figure 2.
Figure 2. Typical SSR Hardware
Minimum SSR Hardware includes:
 I/O interfaces
 User interfaces (keypad, display, optional biometric sensor),
 CPU,
 Memory components,
 At least one smart card slot,
 Secure Access Module (SAM),
 Real Time Clock (RTC),
 Physical and logical security barriers (shields, tamper switches etc.).
RTC Keypad Display
I/O
Interface
SC
Slot#1
SC
Slot#2
Smartcard
Controller
CPU
Memory:
(TOE)
SAM Sensors
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 10.thpage of 101pages
Some hardware components such as biometric sensor, Ethernet port or second smartcard slot are
optional depending on the SSR type. There are three possible SSR device types that TOE can be
deployed. These types are defined in Section 1.2.4.
1.2.3.3 Optional Hardware
SSR Devices may be developed to operate together with additional hardware components which are
Internal Biometric Sensor, External Biometric Sensor (EBS) and External PIN PAD (EPP). Biometric
verification feature is optional for SSR Devices. Both internal and external biometric sensors are
accepted for biometric verification. . In addition, an External PIN PAD could be supplied with the SSR
Hardware as an addition to the on board PIN PAD so as to give ease of use to the user. However,
when external biometric sensors or external PIN PADs are applicable, the TOE shall authenticate the
external device and protect the confidentiality of the communication between the TOE and the
external device.
1.2.4 ACTORS AND EXTERNAL SYSTEMS
Actors: Service Requester, Service Attendee
External Systems: Service Provider Client Application(SPCA, Identity Verification Policy Server (IVPS),
Application Server (APS), SSR Access Server (SAS), Identity Verification Server (IVS), Electronic Identity
Card of National Republic (eID Card), Service Requester (SR), Service Attendee (SA), Online Certificate
Status Protocol (OCSP) Server, Identity Faker, Illegitimate eID Card, SSR Access Server, PC, SAM,
External Biometric Sensor (if applicable), External Pinpad (if applicable).
1.2.5 OPERATIONAL ENVIRONMENTS OF SSR
User environments and usage scenarios are explained for the three types of TOE Environment.
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 11.thpage of 101pages
1.2.5.1 Operational Environment for SSR Type I
13. Identity Verification Assertion (IVA)
Validation Request
SSR
Type I
OCSP Server
PKI Center
IVPS
15. Identity Verification Assertion (IVA)
Validation Response
Identity Verifier
Application Server
14. Certificate Status
Identity Verification Server
(IVS)
2. Card Insertion Request (for SR)
3. eID Card
9. PIN-Biometrics Request (for SR)
10. PIN-Biometrics
11. Identity Verification Assertion
(IVA)
1. Identity Verification Request
4. Identity Verification Specification
(IVSP)
Service Provider
Service Provider
Client Application
(SPCA)
Service
Requester
7. Identity Verification Policy (IVP)
Figure 3. User Environment of Type I
The following scenario explains how Type I devices perform Identity Verification Operation in the
environment shown in Figure 3. Operation is initiated by the Service Provider Client Application
(SPCA) which is installed on a personal computer (PC).
First, SPCA sends an Identity Verification Request to TOE. Once the TOE receives this request, it asks
the SR to insert his/her eID card into the smartcard slot. After the eID card is inserted, the TOE sets
up a secure messaging session with the eID card. Having read the cardholder‘s personal message
from the eID card, the TOE displays it on the screen for the SR’s approval. If the displayed message is
approved by the SR, an Identity Verification Specification (IVSP), is generated by the TOE, and sent to
SPCA. Next, SPCA connects to the Identity Verification Policy Server (IVPS) and gets the Identity
Verification Policy (IVP) for the SR specified in the IVSP. After that, SPCA sends the IVP to the TOE.
Since the policy is signed by the IVPS, the TOE checks the signature to make sure it comes from a
legitimate IVPS and hasn't been modified. The IVP defines the Identity Verification Method (IVM) for
the SR and the organizational policies defined in TS 13584. If an IVPS doesn’t exist, the SPCA defines
the IVM itself. Otherwise, the TOE uses the predefined default IVM which has the highest security
level. During identity verification, the Identity Verification Certificate within the eID Card is not only
verified offline by the TOE, but also validated online with the help of the Online Certificate Status
Protocol (OCSP) Server. If the online certificate validation cannot be achieved due to technical
problems, there are two options to continue the operation: (i) the TOE validates the eID Card of the
Service Requester using the Certificate Revocation List downloaded on the SSR Device. In this case,
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 12.thpage of 101pages
the information that “OCSP check could not be achieved" shall be included in the IVA. (ii) The TOE
does not validate the eID Card of the Service Requester. In this case, the information that “OCSP
check and Revocation List control could not be achieved” shall be included in the IVA. In addition to
certificate verification and validation, according to the IVM, if requested, biometric verification of the
SR is done by the TOE using fingerprint, fingervein or palmvein data. At the end of the
authentication, an Identity Verification Assertion (IVA) is generated by the TOE. Since the IVA is
signed by the SAM, it assures origin of identity, time and place. The TOE sends the IVA to the SPCA
and finally, the SPCA forwards the IVA to the IVS, where it's further validated and kept as the
evidence for the operation. Until the IVA is validated by the IVS, the Identification and Authentication
of SR is regarded as incomplete.
1.2.5.2 Operational Environment for SSR Type II
4. Card Insertion Request (for SR)
13. PIN-Biometrics Request (for SR)
15. Identity Verification
Assertion (IVA)
17. Identity Verification Assertion
(IVA) Validation Request
SSR
Type II
5. eID Card
OCSP Server
PKI Center
Identity Verification Server
(IVS)
Application Server
IVPS
Service Provider
19. Identity Verification Assertion
(IVA) Validation Response
14. PIN-Biometrics
Identity Verifier
18. Certificate Status
1. Identity Verification Request
Service Provider
Client Application
(SPCA)
2. Card Insertion Request (for SA)
3. eID Card
11. PIN-Biometrics Request (for SA)
12. PIN-Biometrics
6. Identity Verification
Specification (IVSP)
Service
Requester
Service
Attendee
9. Identity Verification Policy (IVP)
Figure 4. User Environment of Type II (without SAS)
User environments for Type II devices are given in Figure 4 and Figure 5. As seen, two smartcard
slots are required for Type II devices. The second smartcard slot is needed for Service Attendee
support. Operation is initiated by the SPCA. If SSR Access Server (SAS) exists as shown in Figure 5, the
SPCA communicates to the TOE through the SAS via Ethernet interface, otherwise, it communicates
to the TOE via USB interface.
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 13.thpage of 101pages
5. Card Insertion Request (for SR)
14. PIN-Biometrics Request (for SR)
16. Identity Verification
Assertion (IVA)
20. Identity Verification Assertion
(IVA) Validation Request
SSR
Type II
6. eID Card
OCSP Server
PKI Center
Identity Verification
Server (IVS)
SAS
IVPS
Service Provider
22. Identity Verification Assertion
(IVA) Validation Response
15. PIN-Biometrics
Identity Verifier
21. Certificate Status
3. Card Insertion Request (for SA)
4. eID Card
12. PIN-Biometrics Request (for SA)
13. PIN-Biometrics
7. Identity Verification
Specification (IVSP)
Service
Requester
Service
Attendee
10 Identity Verification Policy
(IVP)
Application
Server
Service Provider
Client Application
(SPCA)
Figure 5. User Environment of Type II (with SAS)
In this scenario, the procedures are similar to the scenario for Type I SRR devices. However, in
addition to Identification and Authentication of SR, Type II SRR devices also support Identification
and Authentication of Service Attendee (SA) thanks to the second smartcard slot. At the end of the
Identification and Authentication of SR and SA, an Identity Verification Assertion (IVA) is generated
by the TOE. This time the IVA includes Service Attendee information as well. The TOE sends the IVA
to the SPCA. Finally, SPCA forwards the IVA to IVS, which validates it and keeps it as an evidence for
the operation. Until the IVA is validated by the IVS, the Identification and Authentication of SR and SA
is regarded as incomplete.
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 14.thpage of 101pages
1.2.5.3 Operational Environment for SSR Type III
10. Identity Verification Assertion
(IVA) Validation Request
SSR
Type III
Sertifika Sunucusu
PKI Center
Identity Verification Server
(IVS)
IVPS
Service Provider
12. Identity Verification Assertion
(IVA) Validation Response
Identity Verifier
Application
Server
11. Certificate Status
1. Identity Verification Request
2. Card Insertion Request (for SR)
3. eID Card
7. PIN-Biometrics Request (for SR)
8. PIN-Biometrics
Service
Requester
Figure 6. User Environment of Type III
User environment for Type III devices is given in Figure 6. Type III device is intended for mobile use.
As seen, the environment doesn’t require a PC. The TOE performs the functions of SPCA itself. It
directly communicates to OSPCS, Application Server and IVPS. Type III devices may have one or two
smartcard slots depending on usage. In the scenario, the procedures are similar to the scenario for
Type I and Type II devices. However, the TOE itself initiates the Identification and Authentication
Operation. In addition, offline usage scenarios are defined for mobile SSR Device. In case OCSP
Server is not reached, (i)TOE validates the eID Card of the Service Requester from the Revocation List
downloaded on the SSR Device and puts the information that OCSP could not be achieved into the
IVA. (ii)TOE does not validate the eID Card and puts the information that OCSP and Revocation List
control could not be achieved in the IVA. This scenario is the same as the Type I and Type II Devices.
However, the revocation list shall be downloaded onto the mobile SSR since SSR Device could run
totally offline for maximum offline working time duration. In addition, if the connection with the APS
is failed, IVAs could be stored in the SSR Device securely until the device becomes online again. The
maximum offline working time is defined by the authorized foundations. Stored IVAs stored be
transmitted to APS securely before this time.
1.2.6 TOE LIFE CYCLE
The TOE shall support:
 Initialization & Configuration
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 15.thpage of 101pages
 Operation Phases
After production, the TOE is in Initialization & Configuration Phase. In the Initialization &
Configuration Phase, the TOE and all other SSR firmware including operating system and file system
are installed to the SSR Device by Initialization agent in a secure environment. After the initialization
and the configuration, the TOE switches to the Operation Phase and doesn’t go back to the
Initialization & Configuration Phase again except tampering of the SSR. Tampering event is the only
condition to set the TOE back to the Initialization & Configuration Phase. If a tampering event is
detected, cryptographic data (keys, SAM Pin, etc.) within the SSR are deleted and the TOE becomes
out of service; all TOE software including operating system, file system and other firmware need to
be re-installed and it has to be initialized and configured by authorized personnel.
In addition, SSR and the TOE have close relations with the SAM in the SSR. Therefore SAM life cycle
and SAM processes related to the TOE and the SSR are given briefly in the following subsections.
1.2.6.1 Obtaining SAM to Produce an SSR
SAM cards and test SAM Cards are supplied by Authorized SAM Provider (ASP). Detailed information
about obtaining the SAM cards are provided by ASP.
During development of SSR, the TOE manufacturer configures the prototype SSR device with test-
SAM cards and then applies to an accredited CC Laboratory and the CC Scheme for CC certification. In
addition, the manufacturer applies to an accredited laboratory and the Turkish Standardization
Institution (TSE) for TS 13582 - TS 13585 conformance certification. Unless the SSR is certified
according to this PP and TS 13582, TS 13583, TS13584, TS 13585 Turkish Standards, the manufacturer
is not given production SAM cards by ASP.
In some cases, an External Biometric Sensor (EBS) and/or an External PIN Pad could be supplied
separately with the SSR. In these cases, the TOE authenticates and securely communicates to the EBS
and/or the EPP as defined in TS 13584[3]. EBS or EPP Developers acquires test- EBS SAM cards or
test-EPP SAM cards from ASP for testing their EBS or EPP.
After the test and certification processes are completed successfully, EBS, EPP and SSR Developers
apply for actual SAM cards.
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 16.thpage of 101pages
2 CONFORMANCE CLAIMS
2.1 CC CONFORMANCE CLAIM
This PP/ST claims conformance to
 Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and
General Model; CCMB-2012-09-001 Version 3.1 Revision 4, September 2012, (CC Part 1)
 Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional
Components; CCMB--2012-09-002 Version 3.1 Revision 4, September 2012, (CC Part 2)
 Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance
Requirements; CCMB--2012-09-003 Version 3.1 Revision 4, September 2012, (CC Part 3)
as follows
 Part 2 extended
 Part 3 conformant
 The Common Methodology for Information Technology Security Evaluation, Evaluation
Methodology; CCMB--2012-09-004 Version 3.1 Revision 4, September 2012, [CEM] has to be
taken into account.
2.2 PP CLAIM
This PP does not claim conformance to any other Protection Profiles.
2.3 PACKAGE CLAIM
This PP is conforming to assurance package EAL4 augmented with ALC_DVS.2 defined in CC part 3 (CC
Part 3).
2.4 CONFORMANCE RATIONALE
Since this PP is not claiming conformance to any other protection profile, no rationale is necessary
here.
2.5 CONFORMANCE STATEMENT
This PP requires demonstrable conformance of any ST or PP, which claims conformance to this PP. It
is required that conformance statement includes the Configuration Type of the TOE.
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 17.thpage of 101pages
3 SECURITY PROBLEM DEFINITION
This part of the PP defines the security problem that is to be addressed by the TOE. It consists of
Assets, Subjects and External Entities, Organizational Security Policies, Threats and Assumptions.
3.1 FACTORS EFFECTING THE SECURITY PROBLEM DEFINITION
Operational Environments for three SSR Types and interaction between the SSR device and external
system components are defined in Section 1.2.5. Optional external/ internal hardware components
of SSR Device are defined in Section 1.2.3.3. These two sections together define the possible
alternatives for the TOE operational environments. Operational environment of the TOE and optional
offline use cases of the TOE, given in Table 1, are the factors effecting the security problem
definition.
Each factor bring about additional security needs. Therefore, in this PP document, Security Problem
Definition, Security Objectives and Security Functional Requirements are designed to cover all the
possible alternatives. ST writer should chose the appropriate ones in the ST document according to
SSR Type, Operational environment, external/ internal optional hardware components and covered
offline use cases.
3.2 ASSETS
The Secure Smart Card Reader (SSR) and the TOE is a part of eID Verification System. TOE carries out
identification and authentication operations and accesses (reads out and performs management
operations of) eID Card on behalf of authorized entities (Role Holder) who has privileges on the eID
Card. TOE shall securely forward the user data read out from the eID Card; however, TOE does not
store any user data.
The TOE defined in this PP (the Application Firmware of the SSR) does not possess any user data.
Table 2. Primary and Secondary Assets
Primary Assets: User Data
Definition Protected against loss of
1. PIN and Biometry data.
PIN and Biometry data of
Service Requester and
Service Attendee.
Integrity and confidentiality
2. SAM-PIN
Used to authenticate the
TOE to the SAM
Integrity and confidentiality
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 18.thpage of 101pages
3. Identity Verification
Assertion (IVA)
Generated as the evidence
of the identity verification
operation.
Privacy, integrity and
authenticity
Secondary Assets: Security
Services
Definition Protected against loss of
4. Identification and
Authentication of Service
Requester and Service
Attendee
Personal Identity Verification
is performed by this service.
Correct operation
5. Identification and
Authentication of third
party trusted IT
Components
Identity Verification of third
party IT Components are
performed by this service.
These components are
Application Server (APS), SSR
Access Server (SAS), External
Biometric Sensor (EBS),
External PIN PAD (EPP) and
SAM
Correct operation
6. Access eID Card on behalf
of Role Holder
Secure messaging session
between the TOE and the
Role Holder is setup. The
TOE accesses the eID card on
behalf of the Role Holder.
Data transfer between the
TOE and the Role Holder is
managed in a secure manner
using the secure messaging
session.
Correct operation
Secondary Assets: TSF Data Definition Protected against loss of
7. Device Tracking Number
of SSR
A number specific to each
TOE that is written during
initialization of TOE. Stored
in the memory of the SSR.
Integrity
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 19.thpage of 101pages
8. Secure Messaging and
Role Card Verifiable
Certificates of SAM (in
CVC Fomat)
Secure Messaging Certificate
is used for Secure Messaging
between the TOE and eID
Card; Role Card Verifiable
Certificate is used for Role
Authentication of the SSR.
These certificates are given
by Device Management
Certificate Authority and
imported from SAM to the
SSR Device and updated by
the TOE before the expiry
date.
Correctness
9. Current Time
The time defined by OCSP
server. TOE uses this time for
ID verification assertion.
Integrity
10. Audit Data
Audit Data Integrity
3.3 SUBJECTS AND EXTERNAL ENTITIES
Table 3. gives the legitimate and the malicious actors and external entities. The legitimate ones are
given in the left column and the malicious ones are given in the right column of Table 3.
Table 3. Legitimate and malicious actors and external systems
Legitimate subjects and entities
Malicious subjects and entities
Service Provider Environment
Service Provider Client Application See Note 1
Identity Verification Policy Server Illegitimate Identity Verification Policy Server
Application Server Illegitimate Application Server
SSR Access Server Illegitimate SSR Access Server
Identity Verification Server See Note 2
Identity Verification Environment
eID Card Illegitimate eID Card
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 20.thpage of 101pages
Service Requester (SR) Identity Faker (not real Service Requester)
Service Attendee (SA): validates photo of
the card holder and has rights to proceed
the operation even if the biometric
verification fails
SA Masquerader (attacker acting as if Service
Attendee)
SAM Illegitimate SAM
External Biometric Sensor Illegitimate External Biometric Sensor
External Pin Pad Illegitimate External Pin Pad
Secure Smartcard Reader (SSR) hardware. Illegitimate SSR hardware (manipulated
and/or probed)
Role Holder Illegitimate Role Holder (Malicious)
The Proxy Entities
PC (on which the SPCA runs) See Note 3.
Other Activities
Initialization agent -
Manufacturer service operator Illegitimate service operator
Attacker
Attacker (also covers the Identity Faker, SA
Masquerader, Illegitimate Role Holder)
Note 1: It is assumed that no illegitimate Service Provider Client Application (SPCA) exists within the
current context.
Note 2: No illegitimate Identity Verification Server (IVS) exists within the current context. The reason
the IVS is taken into the scope this PP, is its required ability to distinguish the IVAs created by the TOE
with the IVAs created by illegitimate TOEs.
Note 3: It is assumed that (1) the PC is free of any malicious software and (2) the environment
between the USB Interface Software and the TOE is secure. So no illegitimate USB Interface Software
and illegitimate PC are defined within the system.
Note 4: Within the current system context, the role holder has privileges on the eID Card. The
attacker will try to exploit these privileges to gain benefits.
Note 5: Initialization agent is assumed to pose no threat because the environment is secure and
personal acts responsively.
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 21.thpage of 101pages
Note 6: The attacker is the threat agent who tries to violate the security of the eID Verification
System. Note that the attacker here is assumed to possess at most enhanced-basic attack potential
(which means that the TOE to be tested against AVA_VAN.3).
3.4 RELEVANCE OF EXTERNAL ENTITIES TO THE TOE ON DIFFERENT SSR TYPES
Some of the entities defined in the Subsection 3.3 are valid for all the three types of SSR Device,
however, some entities are irrelevant for one or two types of the SSR Device. Table 4 shows the
relevance of these entities for three types of SSR Device.
Table 4. Legitimate Entities vs SSR Types
Entity
Applies to
Service Provide Client Application Applies to Type I and Type II.
Identity Verification Policy Server Applies to all
Application Server Applies to all (but only TOE on SSR Type III has direct
contact)
SSR Access Server Applies to Type II
Identity Verification Server Applies to all
eID Card Applies to all
Service Requester Applies to all
Service Attendee Applies to Type II and Type III
Online Certificate Status Protocol
Server
Applies to all
PC Applies to Type I and Type II
Security Access Module Applies to all
SSR Hardware Applies to all
External Biometric Sensor Applies to configurations with External Biometric Sensor
External Pinpad Applies to configurations with External Pin Pad
3.5 THREATS
The threats that could be met by the TOE and its environment are given in Table 5.
Table 5. Threats
Threat
Definition
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 22.thpage of 101pages
T.Counterfeit_eIDC An attacker (Identity Faker) may present a counterfeit eID
Card (form of illegitimate eID Card) to the TOE for faking his or
her identity. This action is also regarded as damaging the
correct operation of the Identification and Authentication of
the Service Requester and the Service Attendee.
T.Revoked_eIDC An attacker (Identity Faker) may present a revoked eID Card
(form of illegitimate eID Card) to the TOE for faking his or her
identity. This action is also regarded as damaging the correct
operation of the Identification and Authentication of the
Service Requester and the Service Attendee.
T.Stolen_eIDC
An attacker (Identity Faker) may present a stolen (not an
illegitimate eID Card) to the TOE for faking his or her identity.
This action is also regarded as damaging the correct operation
of the Identification and Authentication of the Service
Requester and the Service Attendee.
T.IVA_Fraud An attacker may create a fraudulent Identity Verification
Assertion IVA (totally fake, build from scratch, or modified
from a legitimate IVA).
T.IVA_Eavesdropping The attacker may obtain Identity Verification Assertion by
monitoring the communication line between Identity
Verification Server and the Application Server or the
communication line between Application Server and the
Connected part (Service Provider Client Application for Type I,
SPCA and SAS for Type II and TOE for Type III).
T.IVA_Confidentiality_Integrity
[valid only for offline mode of TOE
on SSR Type III]
An attacker may steal or change the IVAs stored in the SSR
Type III memory area during the offline operation of the SSR
Type III.
T.Repudiation The Service Requester (or the Service Attendee) may
repudiate the Identification Verification Assertion.
T.Fake_TOE_to_SR An attacker may prepare a fake SSR Hardware and introduce it
to the Service Requesters (and/or Service Attendee). This way,
the attacker may collect the Identity Verification Card-PIN and
Biometric Information.
T.Fake_TOE_to_External_Entities An attacker may introduce himself/herself as legitimate TOE
to the external entities: eID Card, External Biometric Sensor,
External PIN Pad. Thus obtain the PIN and biometric
information of the Service Requester (or the Service
Attendee) and gain access to eID Card on behalf of the Role
Holder.
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 23.thpage of 101pages
T.SA_Masquerader An attacker may act as if he/she is a legitimate service
attendee and perform the photo verification and thus damage
the Identification and Authentication Service of the Service
Requester.
T.SA_Abuse_of_Session An attacker may abuse the service attendee’s authentication
session. Thus the attacker can validate the photo and/or
accept negative result of biometric verification in an
unauthorized way. This action therefore is regarded as
damaging the correct operation of the Identification and
Authentication of the Service Requester and the Service
Attendee.
T.Fake_Policy An attacker may send a fraudulent policy to manage the
authentication process in an unauthorized manner. This
action is also regarded as damaging the correct operation of
the Identification and Authentication of the SA and the SR.
T.Fake_OCSP_Response An attacker may mimic a legitimate Online Certificate Status
Protocol Server (OCSPS) or manipulate the TSF Data
transmitted by OCSPS. This action is also regarded as
damaging the correct operation of the Identification and
Authentication of the SA and the SR.
T.RH_Comm An attacker may access or modify the eID Card contents
through eavesdropping and manipulating the communication
between the Role Holder and eID Card.
T.RH_Session_Hijack An attacker may access or modify the eID Card contents
through hijacking the authentication session between the eID
Card and the Role Holder.
T.Illegitimate_EBS An attacker may change the outcome of biometric
verification1
or steal or modify the transmitted biometric
template, thus collect biometric information from the
Cardholders or damage the correct operation of the
Identification and Authentication of Service Requester or
Service Attendee by using an illegitimate biometric sensor.
T.EBS_Comm An attacker may change the outcome of biometric
verification; steal or modify the transmitted biometric
template, thus collect biometric information from the
Cardholders or damage the correct operation of the
Identification and Authentication of Service Requester or
1 If biometric verification is implemented on the sensor then biometric verification result is subject of the
attack otherwise biometric template is subject of the attack.
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 24.thpage of 101pages
Service Attendee through (1) eavesdropping and modifying
the communication; (2) hijacking or replaying the
authentication session between the TOE and the EBB.
T.Illegitimate_EPP An attacker may change the outcome of PIN verification or
steal or modify the transmitted PIN, thus collect PIN
information from the Cardholders or damage the correct
operation of the Identification and Authentication or Service
Requester of Service Attendee by using an illegitimate
external PIN-PAD.
T.EPP_Comm An attacker may steal or modify the transmitted PIN, thus
collect PIN information from the Cardholders or damage the
correct operation of the Identification and Authentication of
Service Requester or Service Attendee through (1)
eavesdropping and modifying the communication; (2)
hijacking or replaying the authentication session between SSR
and EPP.
T.eIDC_Comm An attacker may access or modify the eID Card contents, steal
the PIN and biometric information, block the PIN and
biometric verification through (1) eavesdropping and
modifying the communication; (2) hijacking or replaying the
authentication session between the TOE and eID Card.
T.Illegitimate_SAS An attacker may use illegitimate SSR Access Server (SAS) to
undermine security policies. This action is also regarded as
damaging the correct operation of the Identification and
Authentication of third party IT Components for TOE on SSR
Type II.
T.Illegitimate_APS An attacker may use illegitimate Application Server (APS) to
undermine security policies. This action is also regarded as
damaging the correct operation of the Identification and
Authentication of third party IT Components for TOE on SSR
Type III.
T.DTN_Change An attacker may change the Device Tracking Number of the
TOE through physically gaining access to the memories. This
also damage the correctness of the IVA generated by the TOE.
T.SAM-PIN_Theft An attacker may read or change the SAM-PIN of the TOE
during normal operation by physically accessing the SAM PIN
memory area or while TOE is entering the SAM PIN, i. e.
sending the SAM PIN to the SAM.
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 25.thpage of 101pages
T.Audit_Data_Compromise An attacker may change or delete the audit data by physically
accessing the audit memory area.
T.TOE_Manipulation An attacker may manipulate the operation or probe the
internals of the SSR. SAM PIN could be obtained by probing
the internals of the SSR, or DTN or Audit data could be
manipulated. In addition, a counterfeit Identity Verification
Assertion could be created.
T.Fake_SAM An attacker may issue a fake SAM to obtain the SAM-PIN.
T.Stolen_SAM An attacker may steal a SAM and use it to build an illegitimate
SSR.
T.Revoked_SAM An attacker may use a Revoked SAM to build an illegitimate
SSR.
3.6 ORGANIZATIONAL SECURITY POLICIES
The OSPs are given in Table 6.
Table 6. Organizational security policies
Policy
Policy Category and Definition
P.IVM_Management The TOE shall apply the identity verification methods defined by the
IVPS. Otherwise if IVPS is not present, identity verification methods
defined by the SPCA shall be applied. In absence of those, the TOE shall
apply the default policy which has the highest security level
P.TOE_Upgrade The TOE will have mechanisms for secure field upgrade.
P.Re-Authentication Authentication of third party IT components will be renewed after 24
hours.
P.Terminal_Cert_Update Terminal Certificate will be renewed within a period defined in TS 13584
[3]. Client application (for TOE on SSR type I or II), SSR Access Server
(for TOE on Type II with SAS) or Application Server (for TOE on SSR Type
III) shall update the Secure Messaging and Role Card Verifiable
Certificates of SAM one day before the expiration day.
P.Time_Update The time shall be updated using the real time that is received only from
trusted entities.
P.Offline_Operation In case SSR Device cannot reach to OCSP Server, downloading the
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 26.thpage of 101pages
Revocation List onto the SSR Device and checking the certificate
revocation status of the Service Requester (and the Service Attendee if
applicable) from this list is allowed. The revocation list shall be up to
date. When the certificate revocation check is carried out without OCSP
Server, the information regarding that OCSP check could not be realized
shall be put in the IVA. If the OCSP Server is not reached and there is no
downloaded revocation list, then the information that OCSP check and
revocation list control could not be realized shall be put in the IVA. In
this case, only the certificate status control is performed offline, other
identity verification steps shall be performed online. Unless IVA is
validated at IVS and revocation check is completed, Identity Verification
is not regarded as completed.
Additionally, in cases when the SSR Type III (mobile SSR) cannot reach to
Application Server, TOE on SSR Type III is allowed to operate offline for
at most maximum offline working time which is defined by the
authorized foundation. IVAs shall be stored on the SSR Device securely
and transmitted to APS before this time.
P.DPM The TOE shall support Initialization & Configuration and Operation
lifecycle phases. The phase change shall be from Initialization &
Configuration Phase to Operation Phase except tamper event detection
case. If a tamper event is detected, TOE shall be out of service and
require re-initialization. This shall be the only condition to go back to
Initialization & Configuration Phase.
DTN and SAM PIN shall be written to the SSR Device during Initialization
& Configuration Phase.
3.7 ASSUMPTIONS
The assumptions for the operational environment are given in Table 7.
Table 7. Assumptions
A.SPCA
It is assumed that Service Provider Client Application is a
trusted third party and its communication with SSR occurs in a
secure environment via USB interface. However, for SSR Type
II with SAS, there is no direct connection between the SSR and
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 27.thpage of 101pages
the SPCA, SPCA communicates to the SAS through Ethernet
interface.
When the Service Provider Client Application determines the
identity verification method, it is assumed that the Service
Provider Client Application selects the appropriate method.
In addition, integrity and the confidentiality of the private data
transferred from SSR Device to the Client Application is
preserved by the foundation sustaining the Client Application
A.IVPS It is assumed that the IVPS prepares and sends the policy
correctly.
A.EBS-EPP It is assumed that legitimate External Biometric Sensor (EBS)
and legitimate External Pin Pad (EPP) work correctly.
A.PC It is assumed that the PC executing the Client Application is
malicious code free and located in secure environment. In
addition, the confidentiality of the private data that might be
written into the IVA by the Application Owner as Application
Specific Data is preserved by the Application Owner.
A.APS-IVPS It is assumed that the Application Server and the Identity
Verification Policy Server are malicious code free and located
in secure environment.
A.Management_Environment It is assumed that the environments, where initialization and
configuration are performed, are secure. And the personal
that hold initialization and configuration roles act responsively.
A.SAM_ PIN_Environment It is assumed that the PIN value of the SAM in the SSR is
defined in the SSR in secure environment.
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 28.thpage of 101pages
3.8 RELEVANCE OF THREATS, OSPS AND ASSUMPTIONS TO THE TOE ON DIFFERENT SSR
TYPES
Threats, OCPs and assumptions defined in the Security Problem Definition are matched with the
three types of the SSR Device in Table 8.
Table 8. Relevance of Threats, OSPs and Assumptions to the three TOE types
Security Problem Definition Applies to
T.Revoked_eIDC Applies to all
T.Stolen_eIDC Applies to all
T.IVA_Fraud Applies to all
T.IVA_Eavesdropping Applies to all
T.IVA_Confidentiality_Integrity Applies to TOE on SSR Type III with offline mode feature
T.Repudiation Applies to all
T.Fake_TOE_to_SR Applies to all
T.Fake_TOE_to_External_Entities Applies to all
T.SA_Masquerader Applies to TOE on SSR Type II and Type III
T.SA_Abuse_of_Session Applies to TOE on SSR Type II and Type III
T.Fake_Policy Applies to all
T.Fake_OCSP_Response Applies to all
T.RH_Comm Applies to all
T.RH_Session_Hijack Applies to all
T.Illegitimate_EBS Applies to TOE on SSR with External Biometric Sensor
T.EBS_Comm Applies to TOE on SSR with External Biometric Sensor
T.Illegitimate_EPP Applies to TOE on SSR with External Pin Pad
T.EPP_Comm Applies to TOE on SSR with External Pin Pad
T.eIDC_Comm Applies to all
T.Illegitimate_SAS Applies to TOE on SSR Type II
T.Illegitimate_APS Applies to TOE on SSR Type III
T.DTN_Change Applies to all
T.SAM-PIN_Theft Applies to all
T.Audit_Data_Compromise Applies to all
T.TOE_Manipulation Applies to all
T.Fake_SAM Applies to all
T.Stolen_SAM Applies to all
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 29.thpage of 101pages
T.Revoked_SAM Applies to all
P.TOE_Update Applies to all
P.Re-Authentication Applies to all
P.Terminal_Cert_Update Applies to all
P.Time_Update Applies to all
P.Offline_Operation
Applies to TOE on SSR Type I, Type II and Type III but
differently.
A.SPCA Applies to all
A.IVPS Applies to all
A.EBS-EPP Applies to TOE on SSR with EBS and/or EPP
A.PC Applies to all
A.APS-IVPS Applies to all
A.Management_Environment Applies to all
A.SAM_ PIN_Environment Applies to all
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 30.thpage of 101pages
4 SECURITY OBJECTIVES
In this section part-wise solutions are given against the security problem defined in Part 3.
4.1 SECURITY OBJECTIVES FOR THE TOE
Security Objectives for the TOE are given in Table 9.
Table 9. Security Objectives of the TOE
Objective
Definition
OT.IVM_Management The TOE shall apply the identity verification methods
defined by the IVPS. Otherwise if IVPS is not present,
identity verification methods defined by the SPCA
shall be applied. In absence of those, the TOE shall
apply the default policy which has the highest
security level.
OT.Security_Failure When a tampering event is detected or SAM - PIN
authentication failure occurs the TOE shall delete all
user and/or security related data and enter out of
service mode becoming unusable until reinstallation
and re-initialization of the TOE.
OT. eIDC_Authentication The TOE shall support the Card Authentication
mechanism defined in TS 13584 [3].
When OCSP Server is not reached, certificate
revocation status control of the Service Requester
and the Service Attendee could be done using the
Revocation List downloaded to SSR Device. The
revocation list shall be up to date.
If the certificate status control of Service Requester
or the Service Attendee is carried out without OCSP
Server, the information that OCSP check could not be
realized shall be put in the IVA. If the OCSP Server is
not reached and the Revocation List does not exist
within the SRR, then the information that OCSP check
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 31.thpage of 101pages
and Revocation List check could not be realized shall
be put in the IVA.
OT.PIN_Verification The TOE shall support PIN Verification mechanism
defined in TS 13584 [3] for Identification and
Authentication of Service Requester and Service
Attendee.
OT.Photo_Verification The TOE shall support Photo Verification defined in
TS 13584 [3] for Identification and Authentication of
Service Requester.
OT.Biometric_Verification The TOE shall support Biometric Verification defined
in TS 13584 [3] for Identification and Authentication
of Service Requester and Service Attendee if
applicable.
OT.IVA_Confidentiality_Authentication The created Identity Verification Assertion shall be
electronically signed by the TOE (using SAM). If the
TOE is on SSR Type III, IVA shall be sent through a
secure channel to the IVS. Otherwise the secure
channel is founded in between SPCA and IVS.
If the created IVA in the TOE on SSR Type III cannot
be transmitted due to connection problems, this IVA
shall be stored in the SSR Device in encrypted form.
Integrity of the stored IVAs shall be also protected.
The keys for encryption/decryption and integrity
control are generated by the SAM and transferred to
the TOE via secure messaging. .
The stored IVAs shall be transmitted to the APS (after
being decrypted) as soon as possible and not later
than the maximum offline working time.
OT.PM_Verification The eID Card lets the TOE to access Personal Message
of the service requester after the secure messaging
session defined in TS 13584 [3] is established
between the TOE and the eID Card. The TOE shall
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 32.thpage of 101pages
display the Personal Message to the Service
Requester, so that, the Service Requester verifies the
authenticity of the TOE and the SSR, since only
legitimate TOE can access to the Personal Message.
OT.SA_Identity_Verification The TOE shall support Identification and
Authentication of Service Attendee as defined in TS
13585 [4].
OT.Session_Ending The TOE shall end the authentication session of the
Service Attendee whenever the session expires
and/or the eID Card of the Service Attendee is taken
out. In addition TOE shall re-authenticate each
authenticated third party IT product after 24 hours.
(SAS for TOE on SSR Type II (if applicable) , APS for
TOE on SSR Type III, EPP if applicable, EBS if
applicable)
OT.Identity_Verification
Policy_Authentication
The TOE shall verify that the source of received
Identity Verification Policy is a legitimate IVPS.
OT.OCSP_Query_Verify The TOE shall verify that the source of received
information is a legitimate OCSPS.
OT.APS_DA Mutual authentication between the TOE on SSR Type
III and the APS shall be setup before TOE's doing any
action.
OT.SAS_DA Mutual authentication between the TOE on SSR Type
II and the SAS (if applicable) shall be setup before
TOE's doing any action.
OT.APS_SC The TOE on SSR Device Type III shall communicate to
APS securely via SSL-TLS as defined in TS 13584 [3].
OT.SAS_SC The TOE on SSR Device Type II shall communicate to
SAS (if applicable) securely via SSL-TLS as defined in
TS 13584 [3].
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 33.thpage of 101pages
OT.RH_DA
[Role Holder Device Authentication]
Mutual authentication between the TOE and Role
Holder shall be setup as defined in TS 13584 [3]
before TOE's doing any action.
OT.RH_SC
Secure Communication with Role Holder
The communication between the TOE and the Role
Holder shall be secured by AES-256 CBC and AES-256
CMAC algorithms, mutual authentication
mechanisms and key exchange method defined in TS
13584 [3].
OT.RH_Session_Ending The TOE shall end the role holder authentication
session of eID Card when the secure communication
between the TOE and Role Holder ends.
OT.EBS_DA The TOE shall support mutual authentication with the
External Biometric Sensor as defined in TS 13584 [3].
OT.EBS_SC The TOE shall ensure the confidentiality, integrity and
authenticity of the communication going between
the TOE and the External Biometric Sensor as defined
in TS 13584 [3]..
OT.EPP_DA
[External PIN-PAD Device Authentication]
The TOE shall support mutual authentication with
the External PIN-PAD defined in SSR Standard TS
13584 [3].
OT.EPP_SC The TOE shall ensure the confidentiality, integrity and
authenticity of the communication going between
the TOE and External PIN-PAD as defined in TS 13584
[3]..
OT.SM_eID Card
[Secure Messaging between TOE and eID
Card]
The TOE shall ensure the confidentiality, integrity and
authenticity of the communication going between
the TOE and the eID Card.
OT.TOE_Upgrade The TOE shall accept only the Upgrade Package
associated with the corresponding SSR SAM. The
upgrade operation shall only be enabled by the
following roles:
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 34.thpage of 101pages
(i) Manufacturer Service Operator for manual
upgrade operation,
(ii) The following third party IT components for online
upgrade operation:
 SPCA for TOE on SSR Type I,
 SPCA or SAS for TOE on SSR Type II,
 APS for SSR Type III.
TOE shall verify that the source of received upgrade
package is a legitimate software publisher and TOE
shall have a mechanism to decrypt the received TOE
upgrade package as defined in TS TS 13584 [3].
OT.DPM
[Device Phase Management]
The TOE shall support Initialization & Configuration
and Operation lifecycle phases. The phase change
shall be from Initialization & Configuration to
Operation. The TOE shall not be switched to the
Initialization & Configuration Phase from the
Operation Phase unless a tamper event is detected
and the TOE becomes out of service.
OT.SAM-PIN_Mgmt The TOE shall have a management function to write
the SAM-PIN to the SSR Device. The SAM PIN shall be
written only by the initialization agent during
Initialization & Configuration phase.
OT.DTN_Mgmt The TOE shall have a management function to write
the Device Tracking Number to the TOE. The DTN
shall be written only by the initialization agent during
Initialization & Configuration phase..
OT.Time_Mgmt The TOE shall have a management function to set the
real time that is received only from the OCSP Server.
OT.SM_ TOE_and_SAM
[Secure Messaging between TOE and SAM]
The TOE shall protect the confidentiality, integrity
and the authenticity of the communication between
the TOE and the SAM.
OT.SAM-PIN_Sec The TOE shall protect the confidentiality and integrity
of the SAM-PIN during storage and operation
regardless of device power state with the help of the
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 35.thpage of 101pages
SSR hardware.
OT.DTN_Integrity The TOE shall protect the integrity of the Device
Tracking Number.
OT.Audit_Data_Integrity The TOE shall protect the integrity of the audit data.
OT.RIP
[Residual Information Protection]
PIN, Biometry data, other user data and TSF data
shall be copied to only volatile memory under
electronic mesh cover and deleted in a secure way
right after the end of the usage.
OT.Auth_SAM_by_TOE [Authentication of
SAM by TOE]
The TOE shall authenticate the SAM before doing any
operation.
OT.Cert_Update At each Identity Verification Operation, the TOE shall
control the validity of the Secure Messaging and Role
Card Verifiable Certificates of the SAM.
If the expiration date of these certificate(s) are closer
than one day, TOE shall request updated certificates
from the SPCA (for TOE on SSR type I or II without
SAS), the SSR Access Server (for TOE on Type II with
SAS) or the Application Server (for TOE on SSR Type
III) and update the certificates.
4.2 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT
Security objectives for the SSR Hardware and the User Environment of the SSR.
Table 10. Security Objectives for the Operational Environment
Objective
Definition
OE.SPCA Service Provider Client Application shall be developed and used by
trusted parties thus accepted as a trusted third party IT product. In
addition the communication between SPCA and the SSR shall occur
in secure environment.
For the cases when the SPCA determines the identity verification
method, the SPCA shall select the appropriate method.
SPCA shall encrypt the Identity Verification Assertion before sending
it to the Application Server (APS).
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 36.thpage of 101pages
OE.IVPS The IVPS shall:
 prepare and send the correct policy,
 protect the integrity and the authenticity of the policy (it
shall sign the policy using its signing certificate),
 protect the confidentiality of the private key of its signing
certificate.
OE.eID Card The eID Card shall have the following properties:
 support PIN verification,
 prevent usage of IVC Certificate Private key prior to PIN
verification,
 store the cardholder’s digital photo,
 store the cardholder’s biometric data (fingerprint,
fingervein and palmvein),
 support terminal authentication as defined in TS 13584 [3],
 store the cardholder’s personal message(shall not let any
subject access to the personal message prior to terminal
authentication),
 support role holder authentication as defined in TS 13584
[3],
 support secure messaging as defined in TS 13584 [3],
 protect the integrity and confidentiality of the user data
and TSF data.
OE.SAM The SAM shall
 store security credentials for eID Card Authentication,
 support signing the IVA,
 store security credentials for External Device Authentication
to authenticate External Biometric Sensor and External Pin
Pad,
 support Secure Messaging key generation mechanisms for
the communication between the TOE and the following
entities: (1) eID Card, (2) Role Holder, (3) External Biometric
Sensor, (4) External Pin Pad as defined in TS 13584 [3],
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 37.thpage of 101pages
 store the private key (Key Encryption Key) to decrypt the
TOE Upgrade package as defined in TS 13584 [3],
 support SAM-PIN verification mechanism to authenticate
the TOE,
 require SAM-PIN verification to allow the TOE to use its
services,
 support Secure Messaging with the TOE as defined in TS
13584 [3],
 support authentication of itself to the TOE,
 offer Random Number Generation,
 have minimum EAL4+ (AVA_VAN.5) Common Criteria
Certificate.
OE.Service_Requester The Service Requester shall:
 Protect his/her PIN,
 Not enter his/her PIN, or give his/her biometric data prior
to personal message verification,
 Immediately, inform his/her stolen or lost eID Card.
OE.Service_Attendee The Service Attendee shall:
 protect his or her PIN,
 not enter his/her PIN, or give his/her biometric data prior to
personal message verification,
 immediately inform the stolen or lost eID Card,
 act responsively during photo verification,
 not leave the TOE unattended while his/her identity is
verified (shall remove his/her eID Card whenever he/she
leaves the environment).
OE.OCSPS The OCSPS shall:
 operate correctly,
 sign the OCSP answer ,
 protect the confidentiality of the signing key.
OE.IVS The IVS shall have the following properties:
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 38.thpage of 101pages
 Supports the verification of the authenticity of the IVA with
the Authentication Reference Data (Public Key of IVA
Signing Certificate’s integrity is protected)
OE.SSR_Platform The SSR platform shall not have vulnerabilities exploitable by
attackers possessing Enhanced-Basic attack potential for the below
mentioned security features:
 including minimum hardware configuration to provide
correct operation of the TOE,
 possessing tamper-detection and response mechanisms
that cause the SSR to become immediately out of service
and result in the automatic and immediate erasure of SAM
PIN and cryptographic keys stored in tamper protected
area, such that it becomes infeasible to recover these
sensitive data.
 being designed and implemented in a secure manner such
that
 hardware components are chosen to prevent
probing (they shall be BGA);
 it protects the unencrypted data and address
busses carrying the user data and TSF data so
that they are not directly reachable;
 including a Real Time Clock (RTC) Unit with at most 20
seconds fault within 24 hours,
 providing hardware based protection mechanisms to
ensure the integrity and confidentiality of the TOE during
storage, instantiation and operation.
OE.EBS The EBS shall:
 support Secure Communication between the EBS and the
TOE as defined in TS 13584 [3],
 support Terminal Authentication as defined in TS 13584 [3],
 protect security credentials within the EBS.
 display the personal message of the Service Requester prior
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 39.thpage of 101pages
to requesting biyometric input
OE.EPP The EPP shall:
 support Secure Communication between the EPP and
theTOE as defined in TS 13584 [3],
 support Terminal Authentication as defined in TS 13584 [3],
 protect security credentials within the EPP,
 display the personal message of the Service Requester prior
to PIN
OE.Role_Holder The role holder shall:
 act responsively
 have the appropriate role certificate and its Private Key for
Role Holder Authentication
 support Secure Communication between the Role Holder
and the TOE as defined in TS 13584 [3].
OE.PC The PC that executes the SPCA shall be malicious code free and be
located in secure environment.
OE.Security_Management The security management environment shall be secure and
unauthorized personnel shall not access to the TOE.
The security management roles shall act responsively,
OE.SAS The SAS will support Secure Communication with the TOE on SSR
Type II.
SAS shall encrypt the Identity Verification Assertion before sending
it to the SPCA.
OE.Terminal_Cert_Directory SPCA (for TOE on SSR type I or II without SAS), SSR Access Server (for
TOE on Type II with SAS) or Application Server (for TOE on SSR Type
III) shall get the updated Secure Messaging and Role Card Verifiable
Certificates of the SAM in periods defined in TS 13585 [4] and
forward them to the TOE.
OE.PKI The issuer of the eID Card shall establish a public key infrastructure
for the authentication mechanisms of eID Card Authentication,
External Biometric Sensor Authentication, External Pin Pad
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 40.thpage of 101pages
Authentication, Role Holder Device Authentication, OCSP Response
Verification, Identity Verification Policy Verification, and the TOE
Upgrade Package Verification.
OE.CM [Credential
Management]
All credentials, certificates, authentication reference data, shall be
securely created and distributed to the relevant entities.
If Revocation List is used for certificate verification, this Revocation
List shall be up to date.
OE.APS The Application server (APS) shall support Secure Communication
with the TOE on SSR Type III and with client application for SSR Type
I and SSR Type II without SAS.
For the cases when the APS determines the identity verification
method, the APS shall select the appropriate method.
APS shall encrypt the Identity Verification Assertion before sending
it to the IVS (if IVA received is decrypted in the APS).
OE.SSR_Initialization_Environ
ment
The initialization environment of the SSR Device where SAM PIN is
defined to the SSR shall be physically secure.
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 41.thpage of 101pages
4.3 APPLICATION OF SECURITY OBJECTIVES TO THE TOE ON DIFFERENT SSR TYPES
Application of Objectives to the TOE on different SSR Types are given in Table 11.
Table 11. Application of Objectives to the TOE on different SSR Types
Objective Applies to
OT.IVM_Management Applies to all
OT.Security_Failure Applies to all
OT.eIDC_Authentication Applies to all
OT.PIN_Verification Applies to all
OT.Photo_Verification Applies to the Type II and Type III configurations
OT.Biometric_Verification
Applies to configurations with external/internal
Biometric Sensor
OT.IVA_Confidentiality_Authentication
Applies to TOE on SSR Type I, Type II and Type III
differently.
OT.PM_Verification Applies to all
OT.SA_Identity_Verification Applies to the Type II and Type III configurations
OT.Session_Ending Applies to all
OT.Identity_Verification
Policy_Authentication
Applies to all
OT.OCSP_Query_Verify Applies to all
OT.APS_DA Applies to TOE on SSR Type III.
OT.SAS_DA Applies to TOE on SSR Type II with SAS.
OT.APS_SC Applies to TOE on SSR Type III.
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 42.thpage of 101pages
OT.SAS_SC Applies to TOE on SSR Type II with SAS.
OT.RH_DA
[Role Holder Device Authentication]
Applies to all
OT.RH_SC [Secure Communication with Role
Holder]
Applies to all
OT.RH_Session_Ending Applies to all
OT.EBS_DA Applies to the configuration with EBS
OT.EBS_SC Applies to the configuration with EBS
OT.EPP_DA
[External PIN-PAD Device Authentication]
Applies to the configuration with EPP
OT.EPP_SC Applies to the configuration with EPP
OT.SM_eID Card Applies to all
OT.TOE_Upgrade Applies to all
OT.DPM Applies to all
OT.SAM-PIN_Mgmt Applies to all
OT.DTN_Mgmt Applies to all
OT.Time_Mgmt Applies to all
OT.SM_TOE_and_SAM
[Security between TOE and SAM]
Applies to all
OT.SAM-PIN_Sec Applies to all
OT.DTN_Integrity Applies to all
OT.Audit_Data_Integrity Applies to all
OT.RIP [Residual Information Protection] Applies to all
Applies to all
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 43.thpage of 101pages
OT.Auth_SAM_by_TOE [Authentication of
SAM by TOE]
Applies to all
Application of Environment Objectives to the different SSR Types and User Environments of different
SSR Types are given in Table 12.
Table 12. Application of Environment Objectives to the different SSR Types and User Environments
of different SSR Types
Environment Objective Applies to
OE.SPCA Applies to Type I and Type II
OE.IVPS Applies to all
OE.eID Card Applies to all
OE.SAM Applies to all
OE.Service_Requester Applies to all
OE.Service_Attender Applies to the Type II and Type III
OE.OCSPS Applies to all
OE.IVS Applies to all
OE.SSR_Platform Applies to all
OE.EBS Applies to the configuration with EBS
OE.EPP Applies to the configuration with EPP
OE.Role_Holder Applies to all
OE.PC Applies to all
OE.Security_Management Applies to all
OE.SAS Applies to TOE on SSR Type II with SAS
OE.Terminal_Cert_Directory Applies to all
OE.PKI Applies to all
OE.CM [Credential Management] Applies to all
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 44.thpage of 101pages
OE.APS Applies to all
OE.SSR_Initialization_Environment Applies to all
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 45.thpage of 101pages
4.4 COVERAGE OF THREATS, OSPS AND ASSUMPTIONS BY THE SECURITY OBJECTIVES
Table 13, Table 14, Table 15 and Table 16 give the coverage of threats, OSPs and assumptions by the security objectives. Table 13 gives the coverage of
threats and OSPs by the common TOE security objectives of the TOE on all three types of SSR devices and EPP, EBS configurations and optional offline mode
features. Table 14 gives the coverage of threats, OSPs and assumptions by the common environmental security objectives of the TOE on all three types of
SSR devices and EPP, EBS configurations and optional offline mode features. Due to different SSR types and presence of EPP, biometric sensor and optional
offline mode features, additions to the rationale given in Table 15 and Table 16.
Table 13. Security Objectives Rationale Table for TOE on Either SSR Type I,II,II without Biometric Sensor and External Pin Pad
OT.IVM_Management
OT.Security_Failure
OT.
eIDC
_Authentication
OT.PIN_Verification
OT.IVA
_Confidentiality_
Authentication
OT.PM_Verification
OT.Session_Ending
OT.Identity_Verification_P
olicy_Autjentication
OT.OCSP_Query_Verify
OT.RH_DA
OT.RH_SC
OT.RH_Session_Ending
OT.SM_eID
Card
OT.TOE_Upgrade
OT.
DPM
OT.SAM-PIN_Mgmt
OT.DTN_Mgmt
OT.Time_Mgmt
OT.SM_TOE_and_SAM
OT.SAM-PIN_Sec
OT.DTN_Integrity
OT.Audit_Data_Integrity
OT.RIP
OT.Auth_SAM_by_TOE
OT.Cert_Update
T.Counterfeit_eIDC   
T.Revoked_eIDC 
T.Stolen_eIDC 
T.IVA_Fraud 
T.IVA_Eavesdropping 
T.IVA_Confidentiality_Int
egrity
 
T.Repudiation 
T.Fake_TOE_to_SR 
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 46.thpage of 101pages
OT.IVM_Management
OT.Security_Failure
OT.
eIDC
_Authentication
OT.PIN_Verification
OT.IVA
_Confidentiality_
Authentication
OT.PM_Verification
OT.Session_Ending
OT.Identity_Verification_P
olicy_Autjentication
OT.OCSP_Query_Verify
OT.RH_DA
OT.RH_SC
OT.RH_Session_Ending
OT.SM_eID
Card
OT.TOE_Upgrade
OT.
DPM
OT.SAM-PIN_Mgmt
OT.DTN_Mgmt
OT.Time_Mgmt
OT.SM_TOE_and_SAM
OT.SAM-PIN_Sec
OT.DTN_Integrity
OT.Audit_Data_Integrity
OT.RIP
OT.Auth_SAM_by_TOE
OT.Cert_Update
T.Fake_TOE_to_External_
Entities
 
T.Fake_Policy 
T.Fake_OCSP_Response 
T.RH_Comm 
T.RH_Session_Hijack  
T.eIDC_Comm 
T.DTN_Change 
T.SAM-PIN_Theft   
T.Audit_Data_Compromis
e
 
T.TOE_Manipulation     
T.Fake_SAM 
T.Stolen_SAM    
T.Revoked_SAM 
P.IVM_Management 
P.TOE_Upgrade 
P.Terminal_Cert_Update 
P.Re-Authentication 
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 47.thpage of 101pages
OT.IVM_Management
OT.Security_Failure
OT.
eIDC
_Authentication
OT.PIN_Verification
OT.IVA
_Confidentiality_
Authentication
OT.PM_Verification
OT.Session_Ending
OT.Identity_Verification_P
olicy_Autjentication
OT.OCSP_Query_Verify
OT.RH_DA
OT.RH_SC
OT.RH_Session_Ending
OT.SM_eID
Card
OT.TOE_Upgrade
OT.
DPM
OT.SAM-PIN_Mgmt
OT.DTN_Mgmt
OT.Time_Mgmt
OT.SM_TOE_and_SAM
OT.SAM-PIN_Sec
OT.DTN_Integrity
OT.Audit_Data_Integrity
OT.RIP
OT.Auth_SAM_by_TOE
OT.Cert_Update
P.Time_Update 
P.Offline_Operation  
P.DPM   
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 48.thpage of 101pages
Table 14. Environmental Security Objectives Rationale Table for TOE on Either SSR Type I,II,II without External Biometric Sensor and External Pin Pad
OE.SPCA
OE.IVPS
OE.eID
Card
OE.SAM
OE.Service_Attendee
OE.Service_Requester
OE.OCSP
OE.IVS
OE.SSR_Platform
OE.Role_Holder
OE.PC
OE.Security_Management
OE.SAS
OE.Terminal_Cert_Directory
OE.PKI
OE.CM
OE.APS
OE.SSR_Initialization_Environment
T.Counterfeit_eID Card    
T.Revoked_eID Card    
T.Stolen_eID Card    
T.IVA_Fraud    
T.IVA_Eavesdropping     
T.IVA_Confidentiality_Integrity 
T.Repudiation    
T.Fake_TOE_to_SR     
T.Fake_TOE_to_External_Entities    
T.Fake_Policy   
T.Fake_OCSP_Response   
T.RH_Comm  
T.RH_Session_Hijack     
T.eIDC_Comm  
T.DTN_Change 
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 49.thpage of 101pages
OE.SPCA
OE.IVPS
OE.eID
Card
OE.SAM
OE.Service_Attendee
OE.Service_Requester
OE.OCSP
OE.IVS
OE.SSR_Platform
OE.Role_Holder
OE.PC
OE.Security_Management
OE.SAS
OE.Terminal_Cert_Directory
OE.PKI
OE.CM
OE.APS
OE.SSR_Initialization_Environment
T.SAM-PIN_Theft 
T.Audit_Data_Compromise 
T.TOE_Manipulation 
T.Fake_SAM   
T.Stolen_SAM  
T.Revoked_SAM  
P.TOE_Upgrade    
P.Terminal_Cert_Update  
P.Offline_Operation 
A.SPCA 
A.IVPS 
A.EBS-EPP
A.PC 
A.APS 
A.Management_Environment 
A.SAM_ PIN_Environment 
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 50.thpage of 101pages
TOE on SSR Type II and TOE on SSR Type III adds the Photo Verification mechanism and Service Attendee and Security Service Provider entities. In addition,
TOE on SSR Type II adds the SSR Access Server (SAS) related objectives and TOe on SSR Type III adds the Application Server (APS) related objectives. The
additions for the coverage of the threats, OCPs and assumptions ( that are not valid for Type I) is given in Table 15.
Table 15. Additions to Security Objective Rationale due to differences of SSR Type II, III from SSR Type I
OT.Photo_Verification
OE.Service_Attendee
OT.SA_Identity_Verification
OT.Session_Ending
OT.SAS_DA
OT.SAS_SC
OT.APS_DA
OT.APS_SC
OE.APS
OE.SAS
OE.PKI
OE.CM
OE.SAM
OE.eID_Card
T.Illegitimate_SAS (SSR Type II)  
T.Illegitimate_APS (SSR Type III)  
T.IVA_Eavesdropping  
T.Fake_TOE_to_External_Entities  
T.Stolen_eIDC  
T.SA_Masquerader     
T.SA_Abuse_of_Session  
For all three types of SSR Device, External Biometric sensor or External PIN Pad could be connected. For the TOE on SSR device connected with an EBS or
EPP, the additional threats, OSPs and assumptions are given in Table 16.
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 51.thpage of 101pages
Table 16. Additions to Security Objective Rationale for TOE on SSR with External/Internal Biometric Sensor and/or EPP
OT.Biometric_Verification
OT.EPP_DA
OT.EPP_SC
OE.EPP
OE.PKI
OE.CM
OT.EBS_DA
OT.EBS_SC
OE.SAM
OE.EBS
T.Stolen_eIDC 
T.Fake_TOE_to_External_Entities    
T.Repudiation 
T.Illegitimate_EPP     
T.EPP_Comm   
T.Illegitimate_EBS     
T.EBS_Comm   
A.EBS-EPP  
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 52.thpage of 101pages
4.5 SECURITY OBJECTIVES RATIONALE
T.Counterfeit_eID Card: The security objectives OT.eIDC_Authentication and OT.SM_eID Card
protect the eID Card against counterfeiting by authentication of the eID Card and Secure Messaging
with the card. These mechanisms brings about some requirements on eID card, which is addressed
by OE.eID and the support of SAM, which is addressed by OE.SAM. The authentication mechanism
requires the public key infrastructure and the secure credential management. The public key
infrastructure is addressed by OE.PKI; the security of credential management is addressed by OE.CM.
Security Objectives: OT.eIDC_Authentication, OT.SM_eID Card, OT.IVM_Management, OE.eID Card,
OE.SAM, OE.PKI, OE.CM
T.Stolen_eID Card: The justification of this threat changes according to the configuration of the TOE.
Without Biometric Sensor
(internal or external) and
EPP
With Biometric Sensor
and EPP
TOE on SSR
Type I
OT.PIN_Verification,
OE.Service_Requester,
OE.eID Card,
OE.SSR_Platform.
OT.PIN_Verification,
OT.Biometric_Verification
OE.Service_Requester,
OE.eID Card,
OE.SSR_Platform.
Type II and
III
OT. PIN_Verification,
OT.Photo_Verification,
OE.Service_Requester,
OE.Service_Attendee,
OE.eID Card,
OE.SSR_Platform.
OT.PIN_Verification,
OT.Photo_Verification,
OT.Biometric_Verification
OE.Service_Requester,
OE.Service_Attendee,
OE.eID Card,
OE.SSR_Platform.
At minimum PIN Verification mechanism verifies if the person presenting the card is legitimate
owner of the eID Card or an attacker trying to masquerade the identity of legitimate card holder
(OT.PIN_Verification adresses the features in the TOE for this operation, OE.eID_Card adresses the
eID Card requirements for this operaiton, and OE.Service_Requester addresses the Service Requester
requirements for this operaiton). Photo Verification and Biometric Verification strengthens the
resistance against the T.Stolen_eID Card. (OT.Biometric_Verification for biometric verification;
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 53.thpage of 101pages
OT.Photo_Verification and OE.Service_Attendee for photo verification). In addition to this the SSR
Platform shall prevent the attacker to steal the PIN or the biometric data of the user.
Security Objectives: OT.PIN_Verification, OT.Photo_Verification and OT.Biometric_Verification,
OE.eID Card, OE.Service_Requester, OE.Service_Attendee, OE.SSR_Platform.
T.Revoked_eID Card: Authentication methods required by OT.IVM_Management prevent the
revocation attack on the eID Card. OT.IVM_Management and OE.OCSPS cover the threat.
Security Objectives: OT.IVM_Management, OE.OCSPS, OE.eID Card, OE.PKI, OE.CM.
T.IVA_Fraud: OT.IVA_Confidentiality_Authentication allows the IVS to verify the IVA and identify the
SSR that created the IVA. Hence, if an illegitimate IVA is created by an attacker, the IVS can detect it.
The signing of IVA is performed by the SAM. Therefore, the OT.IVA_Confidentiality_Authentication,
OE.SAM and OE.IVS cover the current threat together with OE.PKI and OE.CM which also cover the
required PKI and the secure creation and distribution of the credentials and authentication reference
data respectively.
Security Objectives: OT.IVA_Confidentiality_Authentication, OE.SAM, OE.IVS, OE.PKI, OE.CM
T.IVA_Eavesdropping: OT.IVA_Confidentiality_Authentication requires the secure communication of
IVS and the TOE on SSR Type III. OT.SAS_SC, OT.APS_SC requires the secure communication of the
TOE with SAS and APS for SSR Type II and Type III correspondingly. In addition for TOE on SSR Type I
and Type II, OE.SPCA requires secure transfer of the IVA to APS by SPCA whereas OE.APS requires
secure transfer of the IVA to IVS by APS. Similarly, for SSR Type II with SAS, OE.SAS requires secure
transfer of the IVA to SPCA by SAS. Hence, T.IVA_Eavesdropping is covered by
OT.IVA_Confidentiality_Authentication, OE.IVS, OE.APS, OE.SAS and OE.SPCA.
Security Objectives: OT.IVA_Confidentiality_Authentication, OT.SAS_SC, OT.APS_SC, OE.APS, OE.SAS,
OE.SPCA, OE.IVS, OE.PC.
T.IVA_Confidentiality_Integrity: OT.IVA_Confidentiality_Authentication addresses the secure
storage of the IVAs in SSR Type III. The encryption keys are generated by SAM thus OE.SAM
addresses the secure storage of this encryption keys. These keys shall be transferred to the TOE via
the secure messaging which is addressed by OT.SM_TOE_and_SAM
Security Objectives: OT.IVA_Confidentiality_Authentication, OT.SM_TOE_and_SAM, OE.SAM,
T.Repudiation: PIN Verification or Biometric Verification mechanisms ensure that Service Requester
and eID Card had joined to the Identification Process. OE.CM covers the secure creation and
distribution of the credentials and authentication reference data. Thus OT.PIN_Verification,
OT.Biometric_Verification, OE.Service_Requester, OE.eID Card, OE.PKI, and OE.CM cover the
T.Repudiation.
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 54.thpage of 101pages
Security Objectives: OT.PIN_Verification, OT.Biometric_Verification, OE.Service_Requester, OE.eID
Card, OE.PKI and OE.CM
T.Fake_TOE_to_SR: OT.PM_Verification allows the Service Requester identifying a legitimate SSR.
OE.Service_Requester protects the service requester from entering his or her PIN and interacting
with the biometric sensor without Personal Message Verification. OE.eID Card prevents the fake SSR
accessing the Personal Message and OE.SAM provides the TOE the ability of proving its identity to
the eID Card. Finally OE.PKI and OE.CM cover the required PKI and the secure creation and
distribution of the credentials and authentication reference data.
Security Objectives: OT.PM_Verification, OE.eID Card, OE.Service_Requester, OE.SAM, OE.PKI, OE.CM
T.Fake_TOE_to_External_Entities: Authentication objectives for eID Card, Role Holder, SAS, APS,
EBS, EPP are OT.SM_eIDCard, OT.RH_DA, OT.SAS_DA, OT.APS_DA, OT.EBS_DA, OT.EPP_DA
correspondingly require TOE to prove its identity before doing any action. SAM card in the SSR Device
is used to prove identity of the TOE to the external entities. OE.PKI and OE.CM cover the required PKI
and the secure creation and distribution of the credentials and authentication reference data. Thus
OE.SAM covers the threat with OE.eID Card, OE.EBS (depends on the configuration), and OE.EPP
(depends on the configuration).
Security Objectives: OT.SM_eIDCard, OT.RH_DA, OT.SAS_DA, OT.APS_DA, OT.EBS_DA, OT.EPP_DA,
OE.SAM, OE.eID Card, OE.EBS (depends on the configuration), OE.EPP (depends on the
configuration), OE.PKI, OE.CM.
T.SA_Masquerader: OT.SA_Identity_Verification addresses the verification of Service Attendee’s
identity. Service Attendee’s identity verification is similar to the identity verification of Service
Requester. OE.eID Card, OE.SAM and the OE.Service_Attender address the necessary contributions
of the eID Card, SAM and Service Attendee to the mechanisms covered in Service Attendee identity
verification. Finally OE.PKI and OE.CM cover the required PKI and the secure creation and distribution
of the credentials and authentication reference data.
Security Objectives:OT.SA_Identity_Verification, OE.eID Card, OE.SAM OE.Service_Attendee, OE.PKI,
OE.CM
T.SA_Abuse_of_Session: OT.Session_Ending addresses the termination of authentication session of
Service Attendee whenever the session expires or the Service Attendee removes the eID Card.
OE.Service_Attendee states that the Service Attendee shall not leave his or her eID Card when he or
she leaves the SRR environment.
Security Objectives: OT.Session_Ending, OE.Service_Attendee
T.Fake_Policy: OT.Identity_Verification_Policy_Authentication addresses verifying the integrity and
origin of Identity Verification Policy and OE.IVPS states that Identity Verification Policy shall be signed
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 55.thpage of 101pages
electronically by the IVPS. OE.PKI and OE.CM cover the required PKI and the secure creation and
distribution of the credentials and authentication reference data.
Security Objectives: OT.Identity Verification Policy_Authentication, OE.IVPS, OE.PKI, OE.CM
T.Fake_OCSP_Response: OT.OCSP_Query_Auth addresses verifying the integrity and the origin of the
OCSP response. OE.OCSPS states that OCSP response shall be signed by the OCSPS. OE.PKI and
OE.CM cover the required PKI mechanism and the secure creation and distribution of the credentials
and authentication reference data.
Security Objectives: OT.OCSP_Query_Verify, OE.OCSPS, OE.PKI, OE.CM
T.RH_Comm: The OT.RH_SC, OE.SAM and OE.Role_Holder together agree on the secure
communication keys. OT.RH_SC and OE.Role_Holder addresses the secure communication between
the Role Holder and the TOE.
Security Objectives: OT.RH_SC, OE.SAM, OE.Role_Holder
T.RH_Session_Hijack: OT.RH_DA [Role Holder Device Authentication], OE.SAM and OE.Role_Holder
provides mutual authentication of the TOE and the Role Holder.. OT.RH_Session_Ending resets the
authentication status of Role Holder in eID Card when the secure communication session is
terminated. This prevents the attacker to abuse the authentication status present in the eID Card.
OE.eID Card helps the OT.RH_Session_Ending by providing an authentication reset mechanism to the
TOE. Finally OE.PKI and OE.CM cover the required PKI mechanism and the secure creation and
distribution of the credentials and authentication reference data.
Security Objectives:OT.RH_DA [Role Holder Device Authentication], OT.RH_Session_Ending,
OE.Role_Holder, OE.SAM, OE.eID Card, OE.PKI, OE.CM.
T.Illegitimate_EBS: OT.EBS_DA addresses the authentication of EBS by SAM. OE.PKI and OE.CM cover
the required PKI echanism and the secure creation and distribution of the credentials and
authentication reference data. So the threat is covered OT.EBS_DA, OE.SAM, OE.EBS, OE.PKI and
OE.CM.
Security Objectives: OT.EBS_DA, OE.SAM, OE.EBS, OE.PKI, OE.CM
T.EBS_Comm: OT.EBS_SC and OE.EBS addresses secure communication between the TOE and the
EBS. The OE.SAM and OE.EBS contribute to the key agreement protocol between the TOE and the
EBS.
Security Objectives: OT.EBS_SC, OE.SAM, OE.EBS
T.Illegitimate_EPP: OT.EPP_DA, OE.EPP and OE.SAM addresses the authentication of EPP by SAM.
OE.PKI and OE.CM cover the required PKI mechanism and the secure creation and distribution of the
credentials and authentication reference data. So the threat is covered by OT.EPP_DA, OE.SAM,
OE.EPP, OE.PKI, and OE.CM.
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 56.thpage of 101pages
Security Objectives: OT.EPP_DA, OE.SAM, OE.EPP, OE.PKI, OE.CM
T.EPP_Comm: OT.SC_EPP, OE.EPP and OE.SAM address the secure communication between the TOE
and the EPP therefore cover the threat.
Security Objectives:OT.SC_EPP, OE.EPP, OE.SAM
T.eIDC_Comm: OT.SM_eID Card and OE.eID Card create the cryptographic keys and perform secure
communication. OE.SAM supports the cryptographic key agreement between the TOE and the eID
Card. Hence the threat is covered by OT.SM_eID Card, OE.eID Card and OE.SAM.
Security Objectives: OT.SM_eID Card, OE.eID Card and OE.SAM.
T.Illegitimate_SAS: This threat is covered by OT.SAS_DA which guarantee the authentication of the
SAS before any other action and OE.SAS which ensures that the SAS has the ability to be
authenticated by the TOE.
Security Objectives: OT.SAS_DA, OE.SAS.
T.Illegitimate_APS: This threat is covered by OT.APS_DA which guarantee the authentication of the
APS before any other action and OE.APS which ensures that the APS has the ability to be
authenticated by the TOE.
Security Objectives: : OT.APS_DA, OE.APS.
T.DTN_Change: OT.DTN_Mgmt and OE.SSR_Platform addresses the protection against unauthorized
modification to the DTN.
Security Objectives:OT.DTN_Mgmt, OE.SSR_ Platform.
T.SAM-PIN_Theft: OT.Security_Failure, OT.SM_TOE_and_SAM, OE.SSR_ Platform and OT.SAM-PIN_Sec
address the protection of SAM-PIN against theft and unauthorized change.
Security Objective: OT.Security_Failure, OT.SAM-PIN_Mgmt, OT.SAM-PIN_Sec, OE.SSR_ Platform.
T.Audit_Data_Compromise: OT.Security_Failure, OT.Audit_Data_Integrity and OE.SSR_ Platform
covers the protection of audit data from unauthorized change.
Security Objective: OT.Security_Failure, OT.Audit_Data_Integrity, OE.SSR_ Platform.
T.TOE_Manipulation: OT.Security_Failure addresses protection of the TOE against physical
tampering together with OE.SSR_Platform. OT.SM_TOE_and_SAM [Secure Messaging between TOE
and SAM], addresses the protection of communication between the SAM and the TOE. OT.SAM-
PIN_Sec protects the SAM-PIN against probing, OT.DTN_Integrity protects the DTN from
manipulation, and the OT.Audit_Data_Integrity protects the audit data from manipulation. OT.RIP
provides protection against probing attacks and de-allocates any resources when they are no longer
needed.
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 57.thpage of 101pages
Security Objectives: OT.SM_TOE_and_SAM [Security between TOE and SAM], OT.SAM-PIN_Sec,
OT.DTN_Integrity, OT.Audit_Data_Integrity, OT.RIP [Residual Information Protection],
OE.SSR_Platform
T.Fake_SAM: OT.Auth_SAM_by_TOE addresses the authentication of SAM by TOE. OE.SAM provides
the TOE for the capability to authenticate itself. Finally OE.PKI and OE.CM cover the required PKI
mechanism and the secure creation and distribution of the credentials and authentication reference
data. Thus OT.Auth_SAM_by_TOE, OE.SAM, OE.PKI, and OE.CM cover the threat.
Security Objectives:OT.Auth_SAM_by_TOE [Authentication of SAM by TOE], OE.SAM, OE.PKI, OE.CM
T.Stolen_SAM: OT.Auth_SAM_by_TOE addresses the authentication of SAM by TOE and OE.SAM
requires the SAM-PIN verification before allowing the SSR (the legitimate or the fake) access its
services. OT.SAM-PIN_Secand OT.SM_TOE_and_SAM requires the SAM PIN security during operation
of the SSR Device. The OE.CM protects the SAM-PIN during generation and writing to the SAM and
the TOE.
Security Objectives: OT.Auth_SAM_by_TOE, OT.SAM-PIN_Sec, OT.SAM-PIN_Mgmt,
OT.SM_TOE_and_SAM, OE.SAM and OE.CM.
T.Revoked_SAM: Authentication of SAM by TOE mechanism also involves the revocation query. The
OT.Auth_SAM_by_TOE, OE.SAM, OE.OCSP cover the threat.
Security Objectives: OT.Auth_SAM_by_TOE, OE.SAM, OE.OCSPS.
P.IVM_Management: OT. IVM_Management matches the requirement.
Security Objective: OT. IVM_Management
P.TOE_Upgrade: OT.TOE_Upgrade covers the policy together with OE.SPCA, OE.SAM, OE.SAS and
OE.APS since the upgrade package could be installed onto the SSR via SPCA, SAS or APS and SAM
stores the certificates to validate the upgrade package.
Security Objectives: OT.TOE_Upgrade, OE.SPCA, OE.SAM, OE.SAS, OE.APS.
P.Re-Authentication: OT.Session_Ending requires necessary re-authentications for each
authentication session.
Security Objectives: OT.Session_Ending
P.Terminal_Cert_Update: OT.Cert_Update, OE.Terminal_Cert_Directory and OE.CM matches the
policy. OE.Terminal_Cert_Directory requires the related server to obtain the updated certificates and
OT.Cert_Update covers the update of the certificates by the TOE.
Security Objectives: OT.Cert_Update, OE.Terminal_Cert_Directory and OE.CM.
P.Time_Update: OT.Time_Mgmt matches the time update requirement.
Security Objective:OT.Time_Mgmt
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 58.thpage of 101pages
P.Offline_Operation: OT. eIDC _Authentication defines the offline certificate verification together with
OE.CM. OT.IVA _Confidentiality_and_Authentication mathes the offline identity verification with TOE on
SSR Type III.
Security Objectives: OT. eIDC _Authentication, OE.CM and OT.IVA _Confidentiality_ Authentication.
P.DPM: OT.DPM addresses the phase management policy of the P.DPM. DTN and PIN writing policy is
addressed by OT.DTN_Mgmt and OT.SAM-PIN_Mgmt objectives correspondingly.
Security Objectives: OT.DPM, OT.DTN_Mgmt and OT.SAM-PIN_mgmt
A.SPCA: The security objective OE.SPCA covers the assumption.
Security Objective: OE.SPCA
A.IVPS: The security objective OE.IVPS covers the assumption.
Security Objective: OE.IVPS
A.EBS-EPP: OE.EBS and OE.EPP covers the assumption.
Security Objective: OE.EBS, OE.EPP
A.PC:OE.PC covers the assumption
Security Objective: OE.PC
A.APS: The security objective OE.APS covers the assumption.
Security Objective: OE.APS
A.Management_Environment: OE.Security_Management covers the assumption.
Security Objective: OE.Security_Management
A.SAM_ PIN_Environment: OE.SSR_Initialization_Environment covers the assumption.
Security Objective: OE.SSR_Initialization_Environment
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 59.thpage of 101pages
5 EXTENDED COMPONENTS DEFINITION
5.1 FPT_IDA IMPORTED TSF DATA AUTHENTICATION
Family Behavior:
This family requires that the TOE has the ability to verify that the defined imported TSF Data
originates from the stated external entity.
Component Leveling:
5.1.1 FPT_IDA.1 IMPORTED TSF DATA AUTHENTICATION
Management: FPT_IDA.1
The following actions could be considered for the management functions in FMT:
 Management of authentication data by an administrator.
Audit: FPT_IDA.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in
the PP/ST:
 Minimal: The final decision on authentication;
FPT_IDA.1 Imported TSF Data Authentication
Hierarchical to: No other components
Dependencies: No dependencies
FPT_IDA.1.1 The TSF shall verify that the [assignment: list of TSF Data] originates from
[assignment: list of external entities] using [assignment: list of authentication
mechanisms].
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 60.thpage of 101pages
5.2 FPT_EMSEC TOE EMANATION
Family Behavior:
This family is defined to prevent attacks against secret data stored in and used by the TOE where the
attack is based on external observable physical phenomena of the TOE. The examples to these
attacks are Differential Power Analysis, Simple Power Analysis and Timing Attacks.
Component Leveling:
5.2.1 FPT_EMSEC.1 TOE EMANATION
Management: FPT_EMSEC:1
There are no management activities foreseen
Audit: FPT_EMSEC.1
FPT_EMSEC.1 TOE Emanation
Hierarchical to: No other components
Dependencies: No dependencies
FPT_EMSEC.1.1 The TOE shall not emit [assignment: types of emissions] in excess of
[assignment: specified limits] enabling access to [assignment: list of types of
TSF data] and [assignment: list of types of user data].
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 61.thpage of 101pages
5.3 FPT_SSY STATE SYNCHRONIZATION
Family Behavior:
This family requires that the TOE has ability to synchronize its internal state with another trusted
external entity.
Component Leveling:
5.3.1 FPT_SSY.1 STATE SYNCHRONIZATION
Management: FPT_SSY.1
The following actions could be considered for the management functions in FMT:
 Management of conditions where state synchronization is mandatory, not necessary
if it fails, or not required
Audit: FPT_SSY.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in
the PP/ST:
 Minimal: Result of synchronization: success or failure
FPT_SSY.1 State Synchronization
Hierarchical to: No other components
Dependencies: No dependencies
FPT_SSY.1.1 The TSF shall check [assignment: status of the user security attributes] from
the [assignment: the external entities] in times: [assignment: defined
periods].
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 62.thpage of 101pages
6 SECURITY REQUIREMENTS
6.1 SECURITY FUNCTIONAL REQUIREMENTS
This part of the PP defines the detailed security requirements that shall be satisfied by the TOE. The
statement of TOE security requirements shall define the functional and assurance security
requirements that the TOE needs to satisfy in order to meet the security objectives for the TOE. The
CC allows several operations to be performed on functional requirements; refinement, selection,
assignment, and iteration are defined in Section 8.1 of Common Criteria Part1 [17]. The following
operations are used in the PP.
The refinement operation is used to add detail to a requirement, and thus further restricts a
requirement. Refinements of security requirements are denoted in such a way that added words are
in bold text and removed are crossed out.
The selection operation is used to select one or more options provided by the CC instating a
requirement. Selections having been made are denoted as underlined text.
The assignment operation is used to assign a specific value to an unspecified parameter, such as the
length of a password. Assignments are denoted by italicized text.
The iteration operation is used when a component is repeated with varying operations. Iteration is
denoted by showing a slash “/”, and the iteration indicator after the component identifier.
6.1.1 CLASS FAU: SECURITY AUDIT
6.1.1.1 FAU_GEN.1 - Audit data generation
Hierarchical to: No other components.
Dependencies: [FPT_STM.1 Reliable time stamps] fulfilled by FPT_STM.1
FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable
events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the minimal2
level of audit; and
c) Insertion and removal of eID Card and SAM, Service requester
authentication, service attendee authentication, start and end of secure
messaging, card authentication, received data integrity failure, role holder
2[selection, choose one of: minimum, basic, detailed, not specified]
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 63.thpage of 101pages
authentication, external biometric sensor authentication, external pin pad
authentication, SAM authentication, SAM-PIN verification failure, TOE
update, IVP verification, OCSP answer verification, Switching to offline
mode (for TOE on SSR Type III), SAS authentication and tampering of the
SSR3
.
FAU_GEN.1.2 The TSF shall record within each audit record at least the following
information:
a) Date and time of the event, type of event, subject identity (if applicable),
and the outcome (success or failure) of the event; and
b) For each audit event type, based on the auditable event definitions of the
functional components included in the PP/ST, reason of the failure (if
applicable)4
.
Configuration Note:
Refinement for TOE on SSR Type I: Exclude the service attendee authentication process.
6.1.1.2 FAU_ARP.1 - Security alarms
Hierarchical to: No other components.
Dependencies: [FAU_SAA.1 Potential violation analysis] fulfilled by FAU_SAA.1
FAU_ARP.1.1 The TSF shall take the action of entering Out of Service Mode and delete
SAM PIN and Cryptographic Keys used for storage security5
upon detection
of a potential security violation.
Application Note 1: The instantiation "Cryptographic Keys used for storage security" matches the IVA
Confidentiality and Integrity Keys for TOE on SSR Type III with offline working feature.
6.1.1.3 FAU_STG.1 - Protected audit trail storage
Hierarchical to: No other components.
Dependencies: [FAU_GEN.1 Audit data generation] fulfilled by FAU_GEN.1
FAU_STG.1.1 The TSF shall protect the stored audit records in the audit trail from
unauthorized deletion..
3[assignment: other specifically defined auditable events]
4[assignment: other audit relevant information]
5[assignment: list of actions]
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 64.thpage of 101pages
FAU_STG.1.2 The TSF shall be able to detect6
unauthorized modifications to the stored
audit records in the audit trail.
6.1.1.4 FAU_STG.4 - Prevention of audit data loss
Hierarchical to: FAU_STG.3 Action in case of possible audit data loss.
Dependencies: [FAU_STG.1 Protected audit data storage] fulfilled by FAU_STG.1
FAU_STG.4.1 The TSF shall overwrite the oldest stored audit records7
and none8
if the
audit trail is full.
6.1.1.5 FAU_SAA.1 - Potential violation analysis
Hierarchical to: No other components.
Dependencies: [FAU_GEN.1 Audit data generation] fulfilled by FAU_GEN.1
FAU_SAA.1.1 The TSF shall be able to apply a set of rules in monitoring the audited
events and based upon these rules indicate a potential violation of the
enforcement of the SFRs.
FAU_SAA.1.2 The TSF shall enforce the following rules for monitoring audited events:
a) Tampering of the SSR9
known to indicate a potential security violation;
b)none10
.
6.1.2 CLASS FCS: CRYPTOGRAPHIC SUPPORT
6.1.2.1 FCS_CKM.1/SM - Cryptographic key generation for secure messaging with eID,
SA, EBS, EPP and Role Holder
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic operation]
fulfilled by FCS_COP.1/AES-CBC and FCS_COP.1/AES-CMAC
[FCS_CKM.4 Cryptographic key destruction] fulfilled by FCS_CKM.4
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified
6 [selection, choose one of: prevent, detect]
7 [selection, choose one of: “ignore audited events”, “prevent audited events, except those taken by the authorised user
with special rights”, “overwrite the oldest stored audit records”]
8 [assignment: other actions to be taken in case of audit storage failure]
9[assignment: subset of defined auditable events]
10[assignment: any other rules].
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 65.thpage of 101pages
cryptographic key generation algorithm Encryption and CMAC Key
Generation Algorithm for Secure Messaging11
and specified cryptographic
key sizes 256 bits12
that meet the following: TS 13584 [3]13
.
Application Note 2: Above mentioned Secure Messaging are founded between TOE and eID; TOE and
SAM; TOE and EBS (if applicable); TOE and EPP (if applicable); TOE and Role Holder.
6.1.2.2 FCS_CKM.1/SM_TLS - Cryptographic key generation for secure messaging with
Identity Verification Server, Application Server and SSR Access Server
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic operation]
fulfilled by FCS_COP.1/AES-CBC and FCS_COP.1/AES-CMAC
[FCS_CKM.4 Cryptographic key destruction] fulfilled by FCS_CKM.4
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm TLS v1.2 or above14
and specified
cryptographic key sizes 256 Bits15
that meet the following: RFC 524616
.
Application Note 3: TLS Key Generation is performed between TOE and APS for TOE on SSR Type III;
between TOE and SAS for TOE on SSR Type II.
6.1.2.3 FCS_CKM.1/IVA_Keys - Cryptographic key generation for IVA Confidentiality and
Integrity
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic operation]
fulfilled by FCS_COP.1/AES-CBC and FCS_COP.1/AES-CMAC
[FCS_CKM.4 Cryptographic key destruction] fulfilled by FCS_CKM.4
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm True Random Number Generation17
11[assignment: cryptographic key generation algorithm]
12[assignment: cryptographic key sizes]
13[assignment: list of standards]
14[assignment: cryptographic key generation algorithm]
15[assignment: cryptographic key sizes]
16[assignment: list of standards]
17[assignment: cryptographic key generation algorithm]
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 66.thpage of 101pages
and specified cryptographic key sizes 256 bits18
that meet the following:
none19
.
Application Note 4: True Random Numbers should be generated by the SAM. Since the
communication between the TOE and the SAM is secure, these keys are securely transferred to the
TOE and stored in the tamper proof area.
Refinement: Keys above refers to IVA Encryption/Decryption key used in AES CBC algorithm and the
IVA Integrity key used in AES CMAC algorithm. These keys are used to Encrypt/Decrypt the stored
IVAs on SSR Type III.
Application Note 5: FCS_CKM.1/IVA_Keys defined above should be included in the ST if only the TOE
is on SSR Type III and includes the optional offline IVA Generation and Storage use case.
6.1.2.4 FCS_CKM.4 - Cryptographic key destruction
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of
user data with security attributes, or FCS_CKM.1 Cryptographic key generation]
fulfilled by FCS_CKM.1/SM, FCS_CKM.1/IVA_Keys and FCS_CKM.1/SM_TLS
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method [assignment: cryptographic key
destruction method]20
that meets the following: [assignment: list of
standards]21
.
Application Note 6: The dependency of FCS_CKM.4 is satisfied by the FCS_CKM.1/SM,
FCS_CKM.1/IVA_Keys and FCS_CKM.1/SM_TLS. Note here that the coverage of these SFRs differs
according to SSR Type and whether EBS, EPP and offline modes are included. Therefore, FCS_CKM.4
is required only for the covered SSR Configuration just as it is for FCS_CKM.1.
Application Note 7: FCS_CKM.4 determines the key destruction method for the secure messaging
keys, secure storage keys and the Upgrade Package key (the decrypted key). In case there are
different key destruction algorithms for different keys (e.g. secure messaging with SAM and secure
messaging with role owner), each different key destruction method shall be given in the ST as a
different iteration.
18[assignment: cryptographic key sizes]
19[assignment: list of standards]
20[assignment: cryptographic key destruction method]
21[assignment: list of standards]
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 67.thpage of 101pages
6.1.2.5 FCS_COP.1/SHA-256 - Cryptographic operation SHA 256
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of
user data with security attributes, or FCS_CKM.1 Cryptographic key generation] not
fulfilled but justified.
[FCS_CKM.4 Cryptographic key destruction] not fulfilled but justified.
Justification: A hash function does not use a key so there is neither need to create nor need to
destroy.
FCS_COP.1.1 The TSF shall perform hash value calculation22
in accordance with a
specified cryptographic algorithm SHA-256 [5]23
and cryptographic key sizes
none24
that meet the following: FIPS 180-425
.
6.1.2.6 FCS_COP.1/AES-CBC - Cryptographic AES CBC operation
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of
user data with security attributes, or FCS_CKM.1 Cryptographic key generation]
fulfilled by FCS_CKM.1/SM, FCS_CKM.1/IVA_Keys, FCS_CKM.1/SM_TLS
[FCS_CKM.4 Cryptographic key destruction] fulfilled by FCS_CKM.4
Justification: The first dependency is not satisfied for the decryption requirement for the TOE
Upgrade package. The encrypted keys of the TOE Upgrade package are installed onto
the TOE together with the Upgrade Package. The Key Decryption Keys for these keys
are stored in the SAM. Therefore encrypted keys are decrypted in the SAM using the
Key Decryption Keys and used in the TOE.
FCS_COP.1.1 The TSF shall perform encryption and decryption26
in accordance with a
specified cryptographic algorithm AES-256 CBC Mode27
and cryptographic
key sizes 256 bits28
that meet the following: FIPS 197 (for AES) [6], NIST
22[assignment: list of cryptographic operations]
23[assignment: cryptographic algorithm]
24[assignment: cryptographic key sizes]
25[assignment: list of standards]
26[assignment: list of cryptographic operations]
27[assignment: cryptographic algorithm]
28[assignment: cryptographic key sizes]
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 68.thpage of 101pages
Recommendation for Block Cipher Modes of Operations (for CBC mode)[
7]29
.
6.1.2.7 FCS_COP.1/AES-CMAC - Cryptographic CMAC operation
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of
user data with security attributes, or FCS_CKM.1 Cryptographic key generation]
fulfilled by FCS_CKM.1/SM, FCS_CKM.1/IVA_Keys, FCS_CKM.1/SM_TLS .
[FCS_CKM.4 Cryptographic key destruction] fulfilled by FCS_CKM.4.
FCS_COP.1.1 The TSF shall perform message authentication30
in accordance with a
specified cryptographic algorithm AES-CMAC31
and cryptographic key sizes
256 bits32
that meet the following: FIPS 197 (for AES) [6], RFC 4493 (for
CMAC operation) [9]33
.
6.1.2.8 FCS_COP.1/RSA - Cryptographic RSA encryption operation
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of
user data with security attributes, or FCS_CKM.1 Cryptographic key generation] not
fulfilled but justified.
[FCS_CKM.4 Cryptographic key destruction] fulfilled by FCS_CKM.4
Justification: RSA encryption operation is performed during the key agreement between the SAM
and the TOE. Certificate of the secure messaging between the TOE and the SAM is
stored in the SAM. This certificate contains the public RSA key needed for this RSA
encryption operation and is read by the TOE before key agreement process starts.
FCS_COP.1.1 The TSF shall perform encryption 34
in accordance with a specified
cryptographic algorithm RSA OAEP 35
and cryptographic key sizes 204836
29[assignment: list of standards]
30[assignment: list of cryptographic operations]
31[assignment: cryptographic algorithm]
32[assignment: cryptographic key sizes]
33[assignment: list of standards]
34 [assignment: list of standards]
35 [assignment: cryptographic algorithm]
36 [ assignment: cryptographic key sizes]
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 69.thpage of 101pages
that meet the following: TS 13584 [3], and RSA Cryptography Standard
[10]37
.
6.1.2.9 FCS_COP.1/Sign_Ver - Cryptographic signature verification operation
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of
user data with security attributes, or FCS_CKM.1 Cryptographic key generation] not
fulfilled but justified.
[FCS_CKM.4 Cryptographic key destruction] not fulfilled but justified.
Justification: The public key needed to perform the cryptographic operation is written to the card
via FMT_MTD.1/Ver_Cert. So neither key creation nor import operation is necessary
within the SFR. Also the public key used in the operation does not have
confidentiality requirements so FCS_CKM.4 is also not required here.
FCS_COP.1.1 The TSF shall perform Signature Verification by Cryptographic Validation
and Certificate Validation38
in accordance with a specified cryptographic
algorithm RSA, PKCS#1 v2.1 with PSS padding method39
and cryptographic
key sizes 204840
that meet the following: ETSI TS 102 853[12] and TS 13584
[3]41
.
Application Note 8: This signature verification shall be done for the following signature verification
operations:
 verification of Identity Verification Certificate (eID Card Certificate),
 verification of the OCSP Answer signature,
 verification of the Signature of the Identity Verification Policy sent by the Identity Verification
Policy Server (IVPS) and,
 verification of the Secure Access Module (SAM) certificate,
 verification of upgrade package signature.
Other required signature verification operations required according to the additions to TOE shall be
added in the ST.
37 [assignment: list of standards]
38[assignment: list of cryptographic operations]
39[assignment: cryptographic algorithm]
40[assignment: cryptographic key sizes]
41[assignment: list of standards]
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 70.thpage of 101pages
6.1.3 CLASS FIA: IDENTIFICATION AND AUTHENTICATION
6.1.3.1 FIA_AFL.1 Authentication failure handling
Hierarchical to: No other components.
Dependencies: [FIA_UAU.1 Timing of authentication] fulfilled by FIA_UAU.2 which is hierarchic to
FIA_UAU.1
FIA_AFL.1.1 The TSF shall detect when number of Biometric Verification Failure (defined
in TS 13584 [3]) times42
unsuccessful authentication attempts occur related
to Biometric Verification43
.
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has
been met44
, the TSF shall not allow further biometric verification45
.
Application Note 9: Unsuccessful biometric verification number is written into the eID Card by the
TOE and updated each time the counter is changed.
6.1.3.2 FIA_UID.2 User Identification before any action
Hierarchical to: No other components.
Dependencies: No dependencies
FIA_UID.2.1 The TSF shall require each user to be successfully identified before allowing
any other TSF-mediated actions on behalf of that user.
Refinement: User above refers to Role Holder, Secure Access Module, External PIN Pad (if
applicable), External Biometric Sensor (if applicable) and eID Card. In addition, for TOE on SSR Type II
user also refers to SAS, for TOE on SSR Type III user also refers to APS.
6.1.3.3 FIA_UAU.2 User authentication before any action
Hierarchical to: FIA_UAU.1.
Dependencies: [FIA_UID.1 Timing of identification] fulfilled by FIA_UID.2 which is hierarchic to
FIA_UID.1
FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated
before allowing any other TSF-mediated actions on behalf of
42[selection: [assignment: positive integer number], an administrator configurable positive integer within[assignment:
range of acceptable values]]
43[assignment: list of authentication events]
44[selection: met, surpassed]
45[assignment: list of actions]
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 71.thpage of 101pages
that user.
Refinement: User above refers to Role Holder, Secure Access Module, External PIN Pad (if
applicable), External Biometric Sensor (if applicable) and eID Card. In addition, for TOE on SSR Type II
user also refers to SAS, for TOE on SSR Type III user also refers to APS.
6.1.3.4 FIA_UAU.5 Multiple authentication mechanisms
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UAU.5.1 The TSF shall provide the following authentication mechanisms:
 Service Attendee authentication ,
 Service Requester authentication,
 eID Card authentication,
 SAM authentication,
 Role Holder Device authentication,
 SAS authentication for TOE on SSR Type II,
 APS authentication for TOE on SSR Type III,
 external PIN Pad authentication (if applicable),
 external biometric sensor authentication (if applicable)46
to support user authentication.
FIA_UAU.5.2 The TSF shall authenticate any user's claimed identity according to the
following rules:
 Service requester authentication is done by methods defined in TS
13585 [4]. Verification method is determined by the Identity Verification
Policy Server (IVPS) or the Client Application. For the cases when there is
no IVPS and Client Application does not determine the method, default
method shall be used which is the combination of certificate verification,
PIN authentication, photo verification (if applicable) and biometric
verification (if applicable) as defined in TS 13585 [4].
 Service Attendee authentication is done by methods defined in TS
TS 13585 [4]. Verification method is determined by the Identity
Verification Policy Server (IVPS) or the Client Application. For the cases
46[assignment: list of multiple authentication mechanisms]
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 72.thpage of 101pages
when there is no IVPS and Client Application does not determine the
method, default method shall be used which is the combination of
certificate verification, PIN authentication and biometric verification (if
applciable) as defined in TS 13585 [4].
 eID Card, SAM, Role Holder, external PIN Pad and external
biometric sensor authentications are done by certificate verification.
 APS and SAS authentication are done by SSL/ TLS certificate
authentication. SAS verification is a mutual authentication started by
the TOE. APS verification is a one way server authentication 47
.
Refinement: User above refers to Secure Access Module, External PIN Pad, External Biometric
Sensor, Service Requester, Service Attendee, eID Card. In addition, for TOE on SSR Type II user also
refers to SAS, for TOE on SSR Type III user also refers to IVPS and APS.
Refinement for TOE on SSR Type I: Exclude the Photo Verification and Service Attendee
Authentication.
Refinement for TOE on SSR with no external biometric sensor: Exclude the external biometric
sensor authentication.
Refinement for TOE on SSR with no external PIN Pad: Exclude the external PIN Pad authentication.
Application Note 10: Certificates stored in the SAM are used for the SSL/ TLS client authentication.
Application Note 11: eID Card is the smart card with the National eID Application. Card holder
(either Service Requester or the Service Attendee) is the person who possesses the eID Card. The
authentication of the eID Card and the Card Holder are handled separately because the former is to
validate that the card is not counterfeit, not forged or notrevoked and the latter is to validate that
the card is not stolen. However, due to the authentication policy, in some cases Service Attendee and
Service Requester authentication consist of certificate verification. In this case one refers to the
other.
6.1.3.5 FIA_UAU.6 - Re-authenticating
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UAU.6.1 The TSF shall re-authenticate the user under the conditions given below.
When 4 hours is exceeded after Service Attendee authentication, this
47[assignment: rules describing how the multiple authentication mechanisms provide authentication]
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 73.thpage of 101pages
authentication process is repeated.
 In each authentication request for Service Requester, Service
Requester is re-authenticated even if the card is not removed.
 After 24 hours are exceeded the following sessions' keys are
renewed:
 SAM authentication,
 Role Holder Device authentication,
 APS authentication for TOE on SSR Type III,
 SAS authentication for TOE on SSR Type II
 external PIN Pad authentication (if applicable),
 external biometric sensor authentication (if applicable)48
.
Refinement for TOE on SSR Type I: Exclude the Photo Verification and Service Attendee
Authentication
Refinement: User above refers to Service Attendee, Service Requester, SAM, Role Holder, APS for
TOE on SSR Type III, SAS for TOE on SSR Type II, EPP (if applicable) or EBS (if applicable) according to
the context.
6.1.3.6 FIA_UAU.7 Protected authentication feedback
Hierarchical to: No other components.
Dependencies: [FIA_UAU.1 Timing of authentication] fulfilled by FIA_UAU.2 which is hierarchical to
FIA_UAU.1.
FIA_UAU.7.1 The TSF shall provide
 a dummy character for each entered PIN entry for authentication
by PIN
 a dummy fingerprint representation for authentication by biometry
on the SSR screen 49
to the user Service Requester or Service Attendee
while the authentication is in progress.
48[assignment: list of conditions under which re-authentication is required]
49[assignment: list of feedback]
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 74.thpage of 101pages
6.1.4 CLASS FCO: COMMUNICATION
6.1.4.1 FCO_NRO.2 Enforced proof of origin for Identity Verification Assertion
Hierarchical to: Selective proof of origin.
Dependencies: [FIA_UID.1 Timing of identification] fulfilled by FIA_UID.1
FCO_NRO.2.1 The TSF shall enforce the generation of evidence of origin for transmitted
Identity Verification Assertion Data50
at all times.
FCO_NRO.2.2 The TSF shall be able to relate the identity of origin51
of the originator of
the information, and the Identity Verification Assertion Data52
of the
information to which the evidence applies.
FCO_NRO.2.3 The TSF shall provide a capability to verify the evidence of origin of
information to Identity Verification Server53
given immediately in online
mode, within a 72 hours period in offline mode for TOE on SSR Type III54
.
Refinement: Evidence above shall be the signature of the SAM card. Before sending the Identity
Verification Assertion (IVA) to the Identity Verification Server (IVS), TOE shall ensure that the Identity
Verification Assertion Data is signed by the SAM Signature Certificate as defined in TS 13584 [3].
Application Note 12: - IVS verifies the IVA. This is why the assignment is instantiated as “Identity
Verification Server”. However, TOE on SSR Type I and Type II gives the IVA to SPCA and SPCA sends
the IVA to APS. TOE on SSR Type III directly sends the IVA to APS. In all cases APS sends the IVA to
IVS.
6.1.5 CLASS FMT: SECURITY MANAGEMENT
6.1.5.1 FMT_MOF.1 /Verify- Management of security functions behavior - verify
Hierarchical to: No other components.
Dependencies: [FMT_SMR.1 Security roles] fulfilled by FMT_SMR.1
[FMT_SMF.1 Specification of Management Functions] fulfilled by FMT_SMF.1
FMT_MOF.1.1 The TSF shall restrict the ability to determine the behavior of55
the function
Identity Verification Operation56
to the Identity Verification Policy Server or
50 [assignment: list of information types]
51 [assignment: list of attributes]
52 [assignment: list of information fields]
53 [assignment: list of third parties]]
54 [assignment: limitations on the evidence of receipt]
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 75.thpage of 101pages
Client Application57
.
Application Note 13 A default Identity Verification Method shall be defined in the TOE during
production for the cases when this method is not determined by IVPS or Client Application.
6.1.5.2 FMT_MOF.1 /Upgrade-Management of security functions behavior - upgrade
Hierarchical to: No other components.
Dependencies: [FMT_SMR.1 Security roles] fulfilled by FMT_SMR.1
[FMT_SMF.1 Specification of Management Functions] fulfilled by FMT_SMF.1
FMT_MOF.1.1 The TSF shall restrict the ability to enable58
the function TOE Upgrade59
to
Client Application for TOE on Type I and Type II, Application Server for TOE
on Type III and Manufacturer service operator60
.
Refinement: TOE Upgrade above shall be allowed only for the higher versions and the Upgrade
Package shall be associated with the SAM in the corresponding SSR.
6.1.5.3 FMT_MTD.1/SAM-PIN Management of TSF data
Hierarchical to: No other components.
Dependencies: [FMT_SMR.1 Security roles] fulfilled by FMT_SMR.1
[FMT_SMF.1 Specification of Management Functions] fulfilled by FMT_SMF.1
FMT_MTD.1.1 The TSF shall restrict the ability to write61
the SAM-PIN62
to Initialization
Agent63
.
6.1.5.4 FMT_MTD.1/DTN Management of TSF data - Device Tracking Number
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles fulfilled by FMT_SMR.1
FMT_SMF.1 Specification of Management Functions fulfilled by FMT_SMF.1
FMT_MTD.1.1 The TSF shall restrict the ability to write64
the Device Tracking Number65
to
55[selection: determine the behaviour of, disable, enable, modify the behaviour of]
56[assignment: list of functions]
57[assignment: the authorised identified roles]
58[selection: determine the behaviour of, disable, enable, modify the behaviour of]
59[assignment: list of functions]
60[assignment: the authorised identified roles]
61[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
62[assignment: list of TSF data]
63[assignment: the authorised identified roles]
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 76.thpage of 101pages
Initialization Agent66
.
6.1.5.5 FMT_MTD.1/Time Management of TSF data -Time
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles fulfilled by FMT_SMR.1
FMT_SMF.1 Specification of Management Functions fulfilled by FMT_SMF.1
FMT_MTD.1.1 The TSF shall restrict the ability to update67
the Time68
to OCSP server69
.
Application Note 14: TOE gets the time information from OCSP Server and stores this time
information on the SSR real time Clock (RTC). Upon use of time information in TSF functions, RTC
provides time information.
6.1.5.6 FMT_SMF.1 Specification of Management Functions
Hierarchical to: No other components.
Dependencies: No dependencies.
FMT_SMF.1.1 The TSF shall be capable of performing the following management functions:
 TOE initialization (including SAM PIN and DTN initialization),
 TOE upgrade,
 time and date setting,
 audit generation,
 identity verification method determination 70
.
6.1.5.7 FMT_SMR.1 Security roles
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification fulfilled by FIA_UID.2 which is hierarchic to
FIA_UID.1
FMT_SMR.1.1 The TSF shall maintain the roles
64[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
65[assignment: list of TSF data]
66[assignment: the authorised identified roles]
67[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
68[assignment: list of TSF data]
69[assignment: the authorised identified roles]
70[assignment: list of management functions to be provided by the TSF]
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 77.thpage of 101pages
 Initialization Agent,
 SSR Access Server for TOE on SSR Type II,
 Client Application for TOE on Type I and Type II,
 Application Server for TOE on Type III,
 Identity Verification Policy Server,
 OCSP Server,
 Manufacturer service operator
 Software Publisher71
.
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
6.1.6 CLASS FPT: PROTECTION OF THE TSF
6.1.6.1 FPT_STM.1 Reliable Time Stamps
Hierarchical to: No other components
Dependencies: No dependencies
FPT_STM.1.1 The TSF shall be able to provide reliable time stamps.
Refinement: Reliable time stamp shall be provided from the OCSP server and stored in a real time
clock on SSR Device.
6.1.6.2 FPT_IDA.1/CVC – Imported TSF Data Authentication - Card Verifiable Certificate s
Hierarchical to: No other components
Dependencies: No dependencies
FPT_IDA.1.1 The TSF shall verify that the Secure Messaging Card Verifiable Certificates
and Role Card Verifiable Certificates72
originates from Card Publisher73
using
CVC Authentication Mechanism defined in TS 13584 [3]74
.
71[assignment: the authorized identified roles]
72[assignment: list of TSF Data]
73[assignment: list of external entities]
74[assignment: list of authentication mechanisms].
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 78.thpage of 101pages
6.1.6.3 FPT_IDA.1/IVP - Imported TSF Data Authentication - Identity Verification Policy
Hierarchical to: No other components
Dependencies: No dependencies
FPT_IDA.1.1 The TSF shall verify that the Identity Verification Policy75
originates from
Identity Verification Policy Server76
using IVP authentication mechanism
defined in TS 13584 [3]77
.
6.1.6.4 FPT_IDA.1/OCSP Imported TSF Data Authentication - OCSP
Hierarchical to: No other components
Dependencies: No dependencies
FPT_IDA.1.1 The TSF shall verify that the OCSP Response78
originates from legitimate
OCSP Server79
using OCSP Response Verification Mechanism defined TS 13584
[3]80
.
Application Note 15: For offline Revocation Status Control from the Revocation List downloaded
onto the SSR Device this verification mechanism is still valid.
6.1.6.5 FPT_IDA.1/TOE_Upgrade - Imported TSF Data Authentication - TOE Upgrade
Package
Hierarchical to: No other components
Dependencies: No dependencies
FPT_IDA.1.1 The TSF shall verify that the TOE upgrade package81
originates from
legitimate Software Publisher 82
using TOE Upgrade Authentication
mechanism defined in TS 13584 [3]83
.
75[assignment: list of TSF Data]
76[assignment: list of external entities]
77[assignment: list of authentication mechanisms].
78[assignment: list of TSF Data]
79[assignment: list of external entities]
80[assignment: list of authentication mechanisms].
81[assignment: list of TSF Data]
82[assignment: list of external entities]
83[assignment: list of authentication mechanisms].
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 79.thpage of 101pages
6.1.6.6 FPT_SSY.1/Cert State Synchronization -Secure Messaging and Role CVC
Hierarchical to: No other components
Dependencies: No dependencies
FPT_SSY.1.1 The TSF shall check the validity of the Secure Messaging and Role Card
Certificates of the SAM 84
and request updated certificates from the:
 SPCA for TOE on SSR Type I and Type II with no SAS
 SAS for TOE on SSR Type II with SAS
 APS for TOE on SSR Type III85
in times: at each Identity Verification Operation86
.
6.1.6.7 FPT_SSY.1/SAM State Synchronization -SAM
Hierarchical to: No other components
Dependencies: No dependencies
FPT_SSY.1.1 The TSF shall check SAM Card Certificate revocation status87
from the OCSP
Server88
in times: immediately after opening of the SSR89
.
6.1.6.8 FPT_SSY.1/IVC State Synchronization -IVC
Hierarchical to: No other components
Dependencies: No dependencies
FPT_SSY.1.1 The TSF shall check Identity Verification Certificate revocation status90
from
the OCSP Server or SSR Platform on which up-to-date Revocation List is
present91
in times: during Identity Verification Operation.
Application Note 16: The instantiation of the assignment operation with "SSR Platform on which
up-to-date Revocation List is present " should be included in the ST only if the TOE has the capability
of offline Revocation Control, i.e. downloads the revocation list onto SSR device and do offline
revocation controls. If a new update is present for the revocation list but the OSCP is not reached, in
84[assignment: security attributes]
85[assignment: the external entities]
86 [assignment: defined periods]
87[assignment: security attributes]
88[assignment: the external entities]
89 [assignment: defined periods]
90[assignment: security attributes]
91[assignment: the external entities]
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 80.thpage of 101pages
this case the foundation giving the service is responsible for defining the time for using old
revocation list
6.1.6.9 FPT_SSY.1/RH_Auth_Status State Synchronization Role Holder Authentication
Status
Hierarchical to: No other components
Dependencies: No dependencies
FPT_SSY.1.1 The TSF shall check Role Holder authentication status in eID Card92
from the
eID Card93
in times: after the secure communication between Role Holder and
the TSF is terminated 94
.
Application Note 17: The TSF shall reset the authentication status of the Role Holder in eID Card
after the secure communication between Role Holder and the TSF is terminated as defined in TS
13584 [3]
6.1.6.10 FPT_TST.1 TSF testing
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_TST.1.1 The TSF shall run a suite of self tests during initial start-up95
to
demonstrate the correct operation of the TSF96
.
FPT_TST.1.2 The TSF shall provide authorized users with the capability to verify the
integrity of [selection: [assignment: parts of TSF data], TSF data97
.
FPT_TST.1.3 The TSF shall provide authorized users with the capability to verify the
integrity of [selection: [assignment: parts of TSF], TSF].
92[assignment: security attributes]
93[assignment: the external entities]
94 [assignment: defined periods]
95[selection: during initial start-up, periodically during normal operation, at the request of the authorised user,at the
conditions[assignment: conditions under which self-test should occur]]
96[selection: [assignment: parts of TSF], the TSF].
97 [selection: [assignment: parts of TSF data], TSF data]
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 81.thpage of 101pages
6.1.6.11 FPT_EMSEC.1 TOE Emanation
Hierarchical to: No other components
Dependencies: No dependencies
FPT_EMSEC.1.1 The TOE shall not emit power consumption, electromagnetic emanation or
timing information98
in excess of non useful information99
enabling access to
secret keys of symmetric cryptographic operations, private keys of
asymmetric cryptographic operations, biometric verification counter100
and
SAM PIN101
.
6.1.6.12 FPT_FLS.1 Failure with preservation of secure state
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of
failures occur: a tampering event is detected, identification and
authentication services for SAM are disturbed102
.
6.1.7 CLASS FDP: USER DATA PROTECTION
6.1.7.1 FDP_SDI.2 Stored data integrity monitoring and action
Hierarchical to: Stored data integrity monitoring.
Dependencies: No dependencies.
FDP_SDI.2.1 The TSF shall monitor user data stored in containers controlled by the TSF
for any integrity error103
on all objects encrypted IVAs stored during
offline operation on SSR Type III, based on the following attributes: AES-
CMAC value of the stored encrypted IVAs shall be checked before they are
transmitted to the APS104
.
98 [assignment: types of emissions]
99 [assignment: specified limits]
100 [assignment: list of types of TSF data]
101 [assignment: list of types of user data]
102 assignment: list of types of failures in the TSF
103 [assignment: integrity errors]
104 [assignment: user data attributes]
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 82.thpage of 101pages
FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall give an error
message to the APS indicating the integrity fault and do not continue
offline Identity Verification Operation105
.
Application Note 18: FDP_SDI.2 defined above should be included in the ST if only the TOE is on SSR
Type III and includes the optional offline IVA Generation and Storage use case.
6.1.7.2 FDP_IFC.1 Subset Information Flow Control
Hierarchical to: No other components
Dependencies: FDP_IFF.1 Simple security attributes fulfilled by FDP_IFF.1
FDP_IFC.1.1 The TSF shall enforce the Information Flow Control Policy106
on :
Subjects:
SPCA (subject of TOE on SSR Type I and SSR Type II), SAS (subject for TOE
on SSR Type II with SAS), APS (subject for TOE on SSR Type III), OCSP Server
for TOE on SSR Type III, IVPS for SSR Type III.
Information:
TOE Upgrade Package, IVA, IVM, OCSP response, SAM Secure Messaging
CVC and SAM Role CVC
Operations:
Write (installed to the TOE), read (sent by the TOE)107
.
6.1.7.3 FDP_IFF.1 Simple Security Attributes
Hierarchical to: No other components
Dependencies: FDP_IFC.1 Subset information flow control fulfilled by FDP_IFC.1
FMT_MSA.3 Static attribute initialisation not fulfilled but justified
Justification: The initial value for IVM is defined in the TOE during manufacturing. For other
information under Information Flow Control Policy, initial value is not required, nor meaningful.
FDP_IFF.1.1 The TSF shall enforce the Information Flow Control Policy 108
based on the
following types of subject and information security attributes: Subjects:
105 [assignment: action to be taken]
106 [assignment: information flow control SFP]
107 [assignment: list of subjects, information, and operations that cause controlled information to flow to and from
controlled subjects covered by the SFP]
108 [assignment: information flow control SFP]
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 83.thpage of 101pages
SPCA (subject of TOE on SSR Type I and SSR Type II), SAS (subject for TOE
on SSR Type II with SAS), APS (subject for TOE on SSR Type III), OCSP Server
for TOE on SSR Type III, IVPS for SSR Type III.
Information:
TOE Upgrade Package, IVA, IVM, OCSP response, SAM Secure Messaging
CVC and SAM Role CVC
Attributes:
Software Publisher Signature for TOE Upgrade Package , SAM Signature
for IVA, IVP Signature for IVM, OCSP signature for OCSP response, eID
management CA Signature correspondingly109
.
FDP_IFF.1.2 The TSF shall permit an information flow between a controlled subject
and controlled information via a controlled operation if the following
rules hold: IVA is sent only if communication channel with corresponding
SPCA, SAS or APS is established as defined in this PP and other information
under the control of Information Flow Control Policy are accepted and
written if signature verification is completed successfully110
.
FDP_IFF.1.3 The TSF shall enforce the none 111
.
FDP_IFF.1.4 The TSF shall explicitly authorise an information flow based on the
following rules: none112
.
FDP_IFF.1.5 The TSF shall explicitly deny an information flow based on the following
rules: none 113
.
6.1.7.4 FDP_ITC.1 Import of user data without security attributes
Hierarchical to: No other components
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control] fulfilled by FDP_IFC.1
FMT_MSA.3 Static attribute initialisation not fulfilled but justified
Justification: The initial value for IVM is defined in the TOE during manufacturing. For other
information under Information Flow Control Policy, initial value is not required, nor meaningful.
109 [assignment: list of subjects and information controlled under the indicated SFP, and for each, the security attributes]
110 [assignment: for each operation, the security attribute-based relationship that must hold between subject and
information security attributes]
111 [assignment: additional information flow control SFP rules]
112 [assignment: rules, based on security attributes, that explicitly authorise information flows]
113 [assignment: rules, based on security attributes, that explicitly deny information flows]
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 84.thpage of 101pages
FDP_ITC.1.1 The TSF shall enforce the Information Flow Control Policy114
when
importing user data, controlled under the SFP, from outside of the TOE
FDP_ITC.1.2 The TSF shall ignore any security attributes associated with the user data
when imported from outside the TOE.
FDP_ITC.1.3 The TSF shall enforce the following rules when importing user data
controlled under the SFP from outside the TOE: none115
6.1.7.5 FDP_ETC.2 Export of User Data with Security Attributes
Hierarchical to: No other components
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control] fulfilled by FDP_IFC.1
FDP_ETC.1.1 The TSF shall enforce the Information Flow Control Policy116
when
exporting user data, controlled under the SFP(s), outside of the TOE.
FDP_ETC.1.2 The TSF shall export the user data with the user data's associated security
attributes
FDP_ETC.1.3 The TSF shall ensure that the security attributes, when exported outside
the TOE, are unambiguously associated with the exported user data.
FDP_ETC.1.4 The TSF shall enforce the following rules when user data is exported from
the TOE: none117
.
6.1.7.6 FDP_RIP.1 Subset residual information protection
Hierarchical to: No other components.
Dependencies: No dependencies.
FDP_RIP.1.1 The TSF shall ensure that any previous information content of a resource
is made unavailable upon the deallocation of the resource from118
the
following objects cryptographic credentials, IVA data fields, PIN, photo
and biometric information119
.
114 [assignment: access control SFP(s) and/or information flow control SFP(s)]
115 [assignment: additional importation control rules]
116 [assignment: access control SFP(s) and/or information flow control SFP(s)]
117 [assignment: additional exportation control rules]
118 [selection: allocation of the resource to, deallocation of the resource from]
119 [assignment: list of objects]
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 85.thpage of 101pages
6.1.8 CLASS FTP: TRUSTED PATH/CHANNELS
6.1.8.1 FTP_ITC.1 Inter-TSF trusted channel
Hierarchical to: No other components.
Dependencies: No dependencies.
FTP_ITC.1.1 The TSF shall provide a communication channel between itself and another
trusted IT product each one of the following trusted products: Role Holder
Device, External Biometric Sensor (if applicable), External Pin Pad (if
applicable), eID Card, SSR SAM, SAS for TOE on SSR Type II (with SAS) and
APS for TOE on SSR Type III that is logically distinct from other
communication channels and provides assured identification of its
endpoints and protection of the channel data from modification or
disclosure.
FTP_ITC.1.2 The TSF shall permit the TSF120
to initiate communication via the trusted
channel.
FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for all
functions121
.
Refinement: The role holder certificate used to construct the trusted channel shall be kept in the
HSM device. External Biometric Sensor and the external Pin Pad shall include a Secure Access
Module. Trusted paths with SSR Access Server and Application Server are founded using SSL-TLS
using SSL- TLS certificates.
6.2 APPLICATION OF SFRS TO TOE ON DIFFERENT SSR TYPES AND BIOMETRIC SENSOR /
EPP CONFIGURATIONS
The application of the SFRs to the TOEs on different SSR types and biometric sensor and EPP
configurations and whether the device will run in offline mode or not are stated in Section 6.1 as
Application Notes right after the corresponding SFRs. The relevant SFR corresponding to the Type of
the SSR and other configurations should be chosen by the ST writer.
120[selection: the TSF, another trusted IT product]
121[assignment: list of functions for which a trusted channel is required]
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 86.thpage of 101pages
6.3 SECURITY ASSURANCE REQUIREMENTS
For the evaluation of the TOE and its development and operating environment are those taken from
the Evaluation Assurance Level (EAL4) and augmented by taking the following component:
ALC_DVS.2.
6.4 SECURITY REQUIREMENTS RATIONALE
6.4.1 SECURITY FUNCTIONAL REQUIREMENTS RATIONALE
OT.IVM_Management: FIA_UAU.5 selects the rules for authentication of Service Requester and
Service Attendee. FMT_MOF.1/Verify restricts the use of the management function to the security
role: Identity Verification Policy Server and SPCA. FMT_SMF.1 and FMT_SMR.1 determines the
management functions and roles.
SFRs: FIA_UAU.5, FMT_MOF.1/Verify, FMT_SMF.1 and FMT_SMR.1.
OT.Security_Failure: This objective is covered by FPT_FLS. 1, FAU GEN.1 and FAU_SAA.1 which
requires preserving the secure state, auditing and taking the action of entering out of service mode
respectively upon detection of a security failure.
SFRs: FPT_FLS.1, FAU GEN.1 and FAU_SAA.1.
OT.eIDC_Authentication: Card authentication mechanism is covered by the FIA_UAU.5, FIA_UID.2
and FIA_UAU.2. FPT_SSY/IVC addresses that the eID Card certificate is not expired. Generation of
audit data when failure of authentication happens is provided by FAU.GEN.1.
SFR: FIA_UAU.5, FAU_GEN.1, FIA_UID.2, FPT_SSY/IVC and FIA_UAU.2.
OT.PIN_Verification: Identity Verification Certificate PIN verification is covered by the FIA_UAU.5,
FIA_UAU.2 and FIA_UID.2 and protection of PIN during entry is addressed by the FIA_UAU.7.
Generation of audit data when failure of authentication happens is provided by FAU.GEN.1.
SFRs: FIA_UAU.2, FIA_UID.2, FIA_UAU.5, FIA_UAU.7 and FAU_GEN.1
OT.Photo_Verification: Authentication needs for Photo verification is covered by the FIA_UAU.5,
FIA_UAU.2 and FIA_UID.2.. Generation of audit data when failure of authentication happens is
provided by FAU.GEN.1.
SFRs: FIA_UAU.5, FAU_GEN.1, FIA_UAU.2 and FIA_UID.2.
OT.Biometric_Verification: Biometric verification is covered by the FIA_UAU.5. Generation of audit
data when failure of authentication happens is provided by FAU.GEN.1. Authentication failure
handling of biometric verification is handled by FIA_AFL.1. Protection of biometry data during entry is
addressed by the FIA_UAU.7.
SFRs: FIA_UAU.5, FIA_AFL.1, FAU_GEN.1 and FIA_UAU.7.
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 87.thpage of 101pages
OT.IVA_Confidentiality_Authentication: FAU_GEN.1 requires auditing the created IVAs. The
FCO_NRO.2 guaranties the authentication of the IVA. The hash value of the IVA is created and signed
in SAM. This requirement is covered by FCS_COP.1/SHA-256. IVA is directly sent to APS in TOE on SSR
Type III. Thus confidentiality of the IVA during transmission is covered by FCS_CKM.1/SM-TLS,
FCS_CKM.1/SM_TLS,FCS_CKM.4 and FTP_ITC.1.
The cryptographic requirement for IVA integrity and confidentiality for the TOE on SSR Type III in the
offline mode is guaranteed by FDP_SDI.2, FDP_RIP, FCS_COP.1/AES-CBC and FCS_COP.1/AES-CMAC
together with FPT_EMSEC.1 which guaranties the protection against Side Channel Attacks. The
generation and destruction of the encryption/decryption and integrity keys are addressed by
FCS_CKM.1/IVA_Keys and FCS_CKM.4. These keys are generated by SAM and stored in the tamper
proof area. The confidentiality of this key is guaranteed by FCS_CKM.1/SM, FCS_CKM.4 and
FPT_ITC.1 during transmission from SAM to TOE and by FAU_ARP.1 during storage. The stored IVA
integrity for TOE on SSR Type III in offline mode is addressed by FDP_SDI.2.
SFRs: FCS_COP.1/AES-CBC, FCS_COP.1/AES-CMAC, FPT_EMSEC.1, FAU_GEN.1, FAU_ARP.1
FCO_NRO.2, FCS_COP.1/SHA-256, FCS_CKM.1/SM, FCS_CKM.1/IVA_Keys, FCS_CKM.1/SM-TLS,
FCS_CKM.4, FPT_ITC.1, FDP_SDI.2 , FDP_RIP.1
OT.PM_Verification: Since only the legitimate TOE could found secure messaging with eID Card and
read personnal message FCS_CKM.1/SM, FCS_CKM.4, FCS_COP.1/AES-CBC and FCS_COP.1/AES-
CMAC covers the OT.PM_Verification with FAU_GEN.1 which audits the confirmation of the
personnal message
SFR: FAU_GEN.1, FCS_CKM.1/SM, FCS_COP.1/AES-CBC, FCS_COP.1/AES-CMAC and FCS_CKM.4.
OT.SA_Identity_Verification: FIA_UID.2, FIA_UAU.2 and FIA_UAU.5 covers the identity verification of
Service Attendee and FAU_GEN.1 requires the auditing of the authentication.
SFR: FIA_UID.2, FIA_UAU.2, FIA_UAU.5 and FAU_GEN.1
OT.Session_Ending: FIA_UAU.6 and FAU_GEN.1 covers the objective.
SFRs: FIA_UAU.6, FAU_GEN.1.
OT.ID_Verification_Policy_Authentication: FPT_IDA.1/IVP covers the objective and the Identity
Verification Policy Authentication mechanism addressed in the FPT_IDA.1/IVP requires the
cryptographic support of FCS_COP.1/ Sign_Ver. FAU_GEN.1 audits the authentication.
SFRs:FPT_IDA.1/IVP, FCS_COP.1/ Sign_Ver and FAU_GEN.1.
OT.OCSP_Query_Verify:FPT_IDA.1/OCSP covers the objective and the OCSP Query Response
Verification Mechanism addressed in the FPT_IDA.1/OCSP requires the cryptographic support of
FCS_COP.1/ Sign_Ver. FAU_GEN.1 audits the authentication.
SFRs:FPT_IDA.1/OCSP, FCS_COP.1/ Sign_Ver and FAU_GEN.1.
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 88.thpage of 101pages
OT.RH_DA [Role Holder Device Authentication]: FIA_UAU.5 and FPT_IDA.1/CVC covers the
authentication of role holder and role holder CVC certificate. This requires the cryptographic support
of FCS_COP.1/ Sign_Ver. FAU_GEN.1 audits the authentication.
SFR: FIA_UAU.5, FPT_IDA.1/CVC, FCS_COP.1/ Sign_Ver and FAU_GEN.1.
OT.RH_SC [Secure Communication with Role Holder]: FTP_ITC.1 covers the secure communication
between the Role Holder and the TOE. FCS_CKM.1/SM, FCS_CKM.4, FCS_COP.1/AES-CBC,
FCS_COP.1/AES-CMAC give the necessary cryptographic support for the secure communication and
FPT_EMSEC.1 guarantees the protection of cryptographic keys against SCA.
SFRs: FTP_ITC.1, FCS_CKM.1/SM, FCS_CKM.4, FCS_COP.1/AES-CBC, FCS_COP.1/AES-CMAC,
FPT_EMSEC.1.
OT.RH_Session_Ending: FPT_SSY.1/RH_Auth_Status covers the objective.
SFR: FPT_SSY.1/RH_Auth_Status
OT.EBS_DA: FIA_UID.2, FIA_UAU.2 and FIA_UAU.5 covers the identity verification of EBS,
FPT_SSY/IVC addresses that the EBS SAM certificate is not expired and FAU_GEN.1 requires the
auditing of the authentication.
SFR: FIA_UID.2, FIA_UAU.2, FIA_UAU.5, FPT_SSY/IVC and FAU_GEN.1
OT.EBS_SC: FTP_ITC.1 covers the secure communication between the EBS and the TOE.
FCS_CKM.1/SM, FCS_CKM.4 FCS_COP.1/AES-256, FCS_COP.1/AES-CMAC give the necessary
cryptographic support for the secure communication and FPT_EMSEC.1 guarantees the protection of
cryptographic keys against SCA.
SFRs: FTP_ITC.1, FCS_CKM.1/SM, FCS_CKM.4, FCS_COP.1/AES-CBC, FCS_COP.1/AES-CMAC,
FPT_EMSEC.1.
OT.EPP_DA[External PIN-PAD Device Authentication]: FIA_UID.2, FIA_UAU.2 and FIA_UAU.5 covers
the identity verification of EPP, FPT_SSY/IVC addresses that the EPP SAM certificate is not expired
and FAU_GEN.1 requires the auditing of the authentication.
SFR: FIA_UID.2, FIA_UAU.2, FIA_UAU.5, FPT_SSY/IVC and FAU_GEN.1
OT.EPP_SC: FTP_ITC.1 covers the secure communication between the EPP and the TOE.
FCS_CKM.1/SM, FCS_CKM.4 FCS_COP.1/AES-CBC, FCS_COP.1/AES-CMAC give the necessary
cryptographic support for the secure communication and FPT_EMSEC.1 guarantees the protection of
cryptographic keys against SCA.
SFRs: FTP_ITC.1, FCS_CKM.1/SM, FCS_CKM.4, FCS_COP.1/AES-CBC, FCS_COP.1/AES-CMAC,
FPT_EMSEC.1.
OT.SM_eID Card: FTP_ITC.1 and FPT_IDA.1/CVC covers the secure communication between the eID
Card and the TOE. FCS_CKM.1/SM, FCS_CKM.4 FCS_COP.1/AES-CBC, FCS_COP.1/AES-CMAC give the
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 89.thpage of 101pages
necessary cryptographic support for the secure communication and FPT_EMSEC.1 guarantees the
protection of cryptographic keys against SCA.
SFRs: FTP_ITC.1, FPT_IDA.1/CVC , FCS_CKM.1/SM, FCS_CKM.4, FCS_COP.1/AES-CBC, FCS_COP.1/AES-
CMAC, FPT_EMSEC.1
OT:DPM: FMT_SMF and FMT_SMR covers the phase management functions and roles thus covers
the objective.
SFRs: FMT_SMF.1 and FMT_SMR.1.
OT.TOE_Upgrade: The management function and roles of TOE upgrade is addressed by FMT_SMF.1
and FMT_SMR.1. Unauthorized TOE Update is protected by FMT_MOF.1/Upgrade_Management and
FPT_IDA.1/TOE_Upgrade. The authentication before the upgrade is guarantied by the FIA_UAU.2
and FIA_UID.2. Required cryptographic support is covered by FCS_COP.1/SHA-256, FCS_COP.1/AES-
CBC and FCS_COP.1/Sign_Ver. Audit generation is needed thus FAU_GEN.1 is covered.
SFRs: FAU_GEN.1, FMT_SMF.1, FMT_SMR.1, FMT_MOF.1/Upgrade_Management,
FPT_IDA.1/TOE_Upgrade, FCS_COP.1/SHA-256, FCS_COP.1/AES-CBC, FCS_COP.1/Sign_Ver
FIA_UAU.2 and FIA_UID.2.
OT.SAM-PIN_Mgmt: The management function of writing the SAM-PIN is addressed by FMT_SMF.1;
and protection of SAM-PIN from unauthorized access is provided by FMT_MTD.1/SAM-PIN.
FMT_SMR.1 addresses the security role Initialization Agent who is allowed to write the SAM-PIN.
SFRs: FMT_MTD.1/SAM-PIN, FMT_SMF.1, FMT_SMR.1
OT.DTN_Mgmt: The device tracking number can only written by the configuration agent; this
requirement is covered by FMT_MTD.1/DTN. Relevant management function and role are covered by
FMT_SMF.1 and FMT_SMR.1. Authentication of the role before DTN writing is covered by FIA_UAU.2
and FIA_UID.2.
SFRs: FMT_MTD.1/DTN, FMT_SMF.1, FMT_SMR.1, FIA_UAU.2 and FIA_UID.2.
OT.Time_Mgmt: Time data may only be updated by the security role(s) defined by the ST writer. This
is addressed by FMT_MTD.1/Time. Security role and management function regarding the writing the
Default Method is given in the SFRs: FMT_SMR.1 and FMT_SMF.1. Authentication of the role before
time update is covered by FIA_UAU.2 and FIA_UID.2.
SFRs: FMT_MTD.1/Time, FMT_SMF.1, FMT_SMR.1, FIA_UAU.2 and FIA_UID.2.
OT.SM_TOE_and_SAM [Security between TOE and SAM]: FTP_ITC.1 covers the secure
communication between the TOE and the SAM. The necessary cryptographic support is given by
FCS_CKM.1/SM, FCS_CKM.4, FCS_COP.1/RSA, FCS_COP.1/AES-CBC, and FCS_COP.1/AES-CMAC and
FPT_EMSEC.1 guarantees the protection of cryptographic keys against SCA.
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 90.thpage of 101pages
SFRs: FTP_ITC.1, FCS_CKM.1/SM, FCS_CKM.4, FCS_COP.1/RSA, FCS_COP.1/AES-CBC, FCS_COP.1/AES-
CMAC, FPT_EMSEC.1.
OT.SAM-PIN_Sec: The security of the SAM-PIN is satisfied by the deletion of the SAM PIN upon
detection of a tamper event. This objective is covered by FPT_FLS.1, FAU GEN.1 and FAU_ARP.1
SFRs: FPT_FLS.1, FAU GEN.1 and FAU_ARP.1.
OT.DTN_Integrity: The objective OT.DTN_Integrity is provided by FPT_TST.1 and FPT_FLS.1.
SFR: FPT_TST.1 and FPT_FLS.1.
OT.Audit_Data_Integrity: FAU_STG1 and FAU_STG.4 covers the audit integrity
SFR: FAU_STG1 and FAU_STG.4
OT.RIP [Residual Information Protection]: The SFR FDP_RIP.1 provides the protection aimed by
OT.RIP.
SFR: FDP_RIP.1
OT.Auth_SAM_by_TOE [Authentication of SAM by TOE]: FIA_UAU.5 addresses the authentication of
SAM by the TOE. FPT_SSY.1/SAM addresses the revocation status control.
SFRs: FIA_UAU.5, FPT_SSY.1/SAM.
OT.SAS_DA: FIA_UID.2, FIA_UAU.2 and FIA_UAU.5 covers the objective of device authentication of
SAS with FAU_GEN.1
SFRs: FIA_UID.2, FIA_UAU.2, FIA_UAU.5, FAU_GEN.1
OT.SAS_SC: FCS_CKM.1/SM_TLS, FCS_COP.1/AES-CBC, FCS_COP.1/SHA-256 and FTP_ITC.1 covers
the objective
SFRs: FCS_CKM.1/SM_TLS and FTP_ITC.1
OT.APS_DA: FIA_UID.2, FIA_UAU.2 FIA_UAU.6, and FIA_UAU.5 covers the objective of device
authentication of SAS with FAU_GEN.1
SFRs: FIA_UID.2, FIA_UAU.2, FIA_UAU.5, FAU_GEN.1
OT.APS_SC: FCS_CKM.1/SM_TLS, FCS_COP.1/AES-CBC, FCS_COP.1/SHA-256 and FTP_ITC.1 covers the
objective.
SFRs: FCS_CKM.1/SM_TLS and FTP_ITC.1
OT.Cert_Update: FPT_SSY.1/Cert covers the objective.
SFRs: FPT_SSY.1/Cert
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 91.thpage of 101pages
6.4.2 SECURITY FUNCTIONAL REQUIREMENTS RATIONALE TABLES
The coverage of objectives by the SFRs are given in Table17, Table18 and Table19.
Table17 given below includes the objectives that are valid for TOE on all of the three SSR Types where external PIN Pad and External/Internal Biometric
Sensor is not present.
Table17. SFR Rationale Table for TOE on SSR Type I without Biometric Sensor and External PIN Pad
SFR s
OT.IVM_Management
OT.Security_Failure
OT.eIDC_Authentication
OT.PIN_Verification
OT.IVA_Confidentiality_Authentic
ation
OT.PM_Verification
OT.ID_Verification
Policy_Authentication
OT.OCSP_Query_Verify
OT.RH_DA
OT.RH_SC
OT.RH_Session_Ending
OT.SM_eID
Card
OT.DPM
OT.TOE_Upgrade
OT.SAM-PIN_Mgmt
OT.DTN_Mgmt
OT.Time_Mgmt
OT.SM_
TOE_and_SAM
OT.SAM-PIN_Sec
OT.DTN_Integrity
OT.Audit_Data_Integrity
OT.RIP
OT.Auth_SAM_by_TOE
OT.Cert_Update
FAU_GEN.1          
FAU_ARP.1  
FAU_STG.1 
FAU_STG.4 
FAU_SAA.1 
FCS_CKM.1/SM     
FCS_CKM.1/SM_TLS 
FCS_CKM.1/IVA_Keys 
FCS_CKM.4     
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 92.thpage of 101pages
SFR s
OT.IVM_Management
OT.Security_Failure
OT.eIDC_Authentication
OT.PIN_Verification
OT.IVA_Confidentiality_Authentic
ation
OT.PM_Verification
OT.ID_Verification
Policy_Authentication
OT.OCSP_Query_Verify
OT.RH_DA
OT.RH_SC
OT.RH_Session_Ending
OT.SM_eID
Card
OT.DPM
OT.TOE_Upgrade
OT.SAM-PIN_Mgmt
OT.DTN_Mgmt
OT.Time_Mgmt
OT.SM_
TOE_and_SAM
OT.SAM-PIN_Sec
OT.DTN_Integrity
OT.Audit_Data_Integrity
OT.RIP
OT.Auth_SAM_by_TOE
OT.Cert_Update
FCS_COP.1/SHA-256  
FCS_COP.1/AES-CBC      
FCS_COP.1/AES-CMAC     
FCS_COP.1/RSA 
FCS_COP.1/ Sign_Ver    
FIA_UID.2     
FIA_UAU.2     
FIA_UAU.5     
FIA_UAU.7 
FCO_NRO.2 
FMT_MOF.1/Verify 
FMT_MOF.1/Upgrade_Mana
gement

FMT_MTD.1/SAM-PIN 
FMT_MTD.1/DTN 
FMT_MTD.1/Time 
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 93.thpage of 101pages
SFR s
OT.IVM_Management
OT.Security_Failure
OT.eIDC_Authentication
OT.PIN_Verification
OT.IVA_Confidentiality_Authentic
ation
OT.PM_Verification
OT.ID_Verification
Policy_Authentication
OT.OCSP_Query_Verify
OT.RH_DA
OT.RH_SC
OT.RH_Session_Ending
OT.SM_eID
Card
OT.DPM
OT.TOE_Upgrade
OT.SAM-PIN_Mgmt
OT.DTN_Mgmt
OT.Time_Mgmt
OT.SM_
TOE_and_SAM
OT.SAM-PIN_Sec
OT.DTN_Integrity
OT.Audit_Data_Integrity
OT.RIP
OT.Auth_SAM_by_TOE
OT.Cert_Update
FMT_SMF.1      
FMT_SMR.1      
FPT_STM.1
FPT_IDA.1/CVC  
FPT_IDA.1/IVP 
FPT_IDA.1/OCSP 
FPT_IDA.1/TOE_Upgrade 
FPT_EMSEC.1    
FPT_SSY.1/IVC 
FPT_SSY.1/SAM 
FPT_SSY.1/RH_Auth_Status 
FPT_TST.1 
FDP_SDI.2 
FDP_RIP.1  
FPT_FLS.1   
FTP_ITC.1    
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 94.thpage of 101pages
SFR s
OT.IVM_Management
OT.Security_Failure
OT.eIDC_Authentication
OT.PIN_Verification
OT.IVA_Confidentiality_Authentic
ation
OT.PM_Verification
OT.ID_Verification
Policy_Authentication
OT.OCSP_Query_Verify
OT.RH_DA
OT.RH_SC
OT.RH_Session_Ending
OT.SM_eID
Card
OT.DPM
OT.TOE_Upgrade
OT.SAM-PIN_Mgmt
OT.DTN_Mgmt
OT.Time_Mgmt
OT.SM_
TOE_and_SAM
OT.SAM-PIN_Sec
OT.DTN_Integrity
OT.Audit_Data_Integrity
OT.RIP
OT.Auth_SAM_by_TOE
OT.Cert_Update
FPT_SSY.1/Cert 
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 95.thpage of 101pages
Table18 gives the SFR Rational for additional objectives of TOE on SSR Type II and SSR Type III.
Table18: SFR Rationale for additional objectives of TOE on SSR Type II and SSR Type III
OT.Photo_Verification
OT.SA_Identity_Verification
OT.Session_Ending
OT.SAS_DA
OT.SAS_SC
OT.APS_DA
OT.APS_SC
FAU_GEN.1     
FCS_CKM.1/SM_TLS  
FCS_COP.1/SHA-256  
FCS_COP.1/AES-CBC  
FIA_UID.2    
FIA_UAU.2    
FIA_UAU.5    
FIA_UAU.6  
FTP_ITC.1  
Table19 gives the SFR Rational for additional objectives of TOE on SSR with biometric sensor and/pr
external PIN PAD.
Table19: SFR rationale additions for TOE on SSR with External/Internal Biometric Sensor and/or
EPP
OT.Biometric_
Verification
OT.EPP_DA
OT.EPP_SC
OT.EBS_DA
OT.EBS_SC
OT.Session_Ending
FAU_GEN.1   
FIA_AFL.1 
FIA_UID.2  
FIA_UAU.2  
FIA_UAU.5   
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 96.thpage of 101pages
FIA_UAU.6 
FIA_UAU.7 
FCS_CKM.1/SM  
FCS_CKM.4  
FCS_COP.1/AES-CBC  
FCS_COP.1/AES-CMAC  
FPT_EMSEC.1  
FPT_SSY.1/IVC  
FTP_ITC.1  
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 97.thpage of 101pages
6.4.3 SECURITY ASSURANCE REQUIREMENTS RATIONALE
EAL4 is chosen to permit a developer to gain maximum assurance from positive security engineering
based on good commercial development practices which, though rigorous, do not require substantial
specialist knowledge, skills, and other resources. EAL4 is the highest level at which it is likely to be
economically feasible to retrofit to an existing product line.
EAL4 is applicable in those circumstances where developers or users require a moderate to high level
of independently assured security in conventional commodity TOEs and are prepared to incur
additional security-specific engineering costs.
The selection of the component ALC_DVS.2 provides a higher assurance of the security of the TOE’s
development and manufacturing especially for the secure handling of the TOE’s material.
The component ALC_DVS.2 augmented to EAL4 has no dependencies to other security requirements.
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 98.thpage of 101pages
7 GLOSSARY AND ACRONYMS
7.1 GLOSSARY
Service Provider Environment:
SCPA (Service Provider Client Application): The external system that requests the identity
verification. The SCPA may directly state the method that will be used in the identity verification
process or may state the method will be declared by the IVPS. And as a final option the SCPA may
state that the default method stored in the TOE should be used in the identity verification process.
IVPS (Identity Verification Policy Server):The external system that prepares the Identity Verification
Policy (Identity Verification Policy) and sends it to the TOE. The TOE performs the identity verification
method defined in the policy.
IVS (Identity Verification Server): The external entity that validates the IVAs created by the TOE.
Identity Verification Environment:
eID Card (Electronic Identity Card): The national identity card used by service requester for claiming
and proving his or her identity. eID Card is issued by or on behalf of General Directorate of Civil
Registration and Nationality – Ministry of the Interior.
SR (Service Requester): Service requester is the person who claims and proves his or her identity.
The service requester claim starts with presenting eID Card to the SSR. The TOE, the SAM and the
Service Attendee122
together verify the claim interacting with the Service Requester and the eID
Card123
.
SA (Service Attendee): Service Attendee is the person who attends the identity verification process
and approves if the photo displayed by the SSR belongs to the service requester. Service Attendee is
also subject to prove his or her identity one of the methods.
OCSPS (Online Certificate Status Protocol Server): The server that keeps the revocation status of the
IVCs. The OCSPS responds to the OCSP queries with the revocation status of the queried IVC.
Malicious Actors and Malicious External Systems:
Identity Faker: The attacker who tries to masquerade his or her identity with someone else’s
identity.
Illegitimate eID Card: An identity faker may use three types of illegitimate eID Card: a counterfeit eID
Card, a forged eID Card and a revoked eID Card.
122The Service Attendee’s presence and role depends on the Configuration of the TOE and the selected identity verification
method.
123 PIN Verification involves interaction of Service Requester with eIDC.
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 99.thpage of 101pages
The Proxy Entities:
PC (Personal Computer): The computer the UIS or NIS is running on.
SSR Environment:
SAM (Secure Access Module): The SAM is the secure element of the SSR. The critical security
functionality of the SSR is performed by the SAM. Since the TOE is the application software of the
SSR, the SAM is an external element. The TOE accesses the SAM services through PIN verification.
The SSR Platform:The SAM and the SSR Environment are the non-TOE hardware, software and
firmware that the TOE needs to function. The SSR environment at minimum consists of USB
Interface, the smart card interfaces, graphic display, Service Requester interface, real time clock,
execution environment and file system. Optionally depending on the configuration, the TOE may
have Service Attendee interface, biometric sensor, Ethernet interface and interfaces for EBS and EPP.
The SSR environment should also include security features to protect itself from tampering.
EBS124
(External Biometric Sensor): Optional external entity connected to the TOE. Depending on the
sensor type, it sends the biometric template or biometric verification result to the TOE.
EPP125
(External PIN-PAD):Optional external entity connected to the TOE.The EPP is present only for
TOE of Configuration Type III. External PIN_PAD offers convenience to the Service Requester. When
external PIN-PAD is available, the Service Requester inserts his or her eID Card and enters IVC-PIN to
external PIN-PAD.
7.2 ACRONYMS
APS: Application Server
CRL: Certificate Revocation List
CVC: Card Verifiable Certificate
DA: Device Authentication
DTN: Device Tracking Number
EBS: External Biometric Sensor
eID: Electronic Identity
EPP: External pin Pad
eIDMS: Electronic Identity Management System
eID Card: Electronic Identity Card of National Republic
eIDVS: Electronic Identity Verification System
124EBS presence depends on the SSR configuration.
125EPP presence depends on the SSR configuration.
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 100.thpage of 101pages
eSign: Electronic Signature
IV: Identity Verification
IVA: Identity Verification Assertion
IVC: Identity Verification Certificate
Identity Verification Policy: Identity Verification Policy
IVPS: Identity Verification Policy Server
IVR: Identity Verification Request
IVS: Identity Verification Server
IVSP: Identity Verification Specification
OCSPS: Online Certificate Status Protocol Server
SAM: Security Access Module
SAS: SSR Access Server
SPCA: Service Provider Client Application
SPSA: Service Provider Server Application
SSR: Card Acceptance Device
TA: Terminal Authentication
7.3 REFERENCES
1. TS 13582 - T.C Kimlik Kartları İçin Güvenli Kart Erişim Cihazları Standardı – Bölüm-1: Genel
Bakış, (Secure Smart Card Reader Standard - Part-1: Overview) 2013, Türk Standartları Enstitüsü
2. TS 13583 - T.C Kimlik Kartları İçin Güvenli Kart Erişim Cihazları Standardı – Bölüm-2: Arayüzler
ve Özellikleri, (Secure Smart Card Reader Standard - Part-2: Interfaces and their characteristics) 2013,
Türk Standartları Enstitüsü
3. TS 13584 - T.C Kimlik Kartları İçin Güvenli Kart Erişim Cihazları Standardı - Bölüm-3: Güvenlik
Özellikleri (Secure Smart Card Reader Standard - Part-3: Security Properties), 2013, Türk Standartları
Enstitüsü.
4. TS 13585 - T.C Kimlik Kartları İçin Güvenli Kart Erişim Cihazları Standardı - Bölüm-4: SSR
Uygulama Yazılımı Özellikleri, (Secure Smart Card Reader Standard - Part-4: Secure Smart Card
Reader Application Firmware Specifications), 2013, Türk Standartları Enstitüsü.
5. FIPS 180-4, Secure Hash Standard (SHS), March 2012, U.S. Department of Commerce,
National Institude of Standards and Technology
6. FIPS 197, Advanced Encryption Standard (AES), November 2001, National Institude of
Standards and Technology
Application Firmware of SSR for National eID Verification System
rev: 2.5 date: 09.11.2015 SSR_PP_2.5 101.thpage of 101pages
7. Recommendation for Block Cipher Modes of Operation, National Institute of Standards and
Technology Special Publication 800-38A 2001 ED Natl. Inst. Stand. Technol. Spec. Publ. 800-38A 2001
ED, 66 pages (December 2001)
8. NIST Special Publications 800-38A, Recommendation for Block Cipher Modes of Operations,
http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf, 2001.
9. RFC 4493, The ESP CBC-Mode Cipher Algorithms, https://tools.ietf.org/html/rfc4493, June
2006, Internet Society Network Working Group.
10. PKCS #1 v2.1, RSA Cryptography Standard, September 2012, RSA Laboratories.
11. RFC 3447, RSA Cryptography Specifications, https://www.ietf.org/rfc/rfc3447.txt, Feb 2003,
Internet Society Network Working Group.
12. ETSI TS 102 853, Electronic Signatures and Infrastructures (ESI); Signature verification
procedures and policies, V1.1.1, July 2012.
13. TST 2015101199 T.C. Kimlik kartlari için elektronik kimlik doğrulama sistemi - bölüm 1: genel
bakiş ve t.c. kimlik karti
14. TST 2015101200 T.C. Kimlik Kartlari Için Elektronik Kimlik Doğrulama Sistemi - Bölüm 2: Kimlik
Doğrulama Sunucusu
15. TST 2015101201 T.C. Kimlik Kartlari Için Elektronik Kimlik Doğrulama Sistemi - Bölüm 3: Kimlik
Doğrulama Politika Sunucusu
16. TST 2015101202 T.C. Kimlik Kartlari Için Elektronik Kimlik Doğrulama Sistemi - Bölüm 4: Kimlik
Doğrulama Yöntemleri
17. Common Criteria for Information Technology Security Evaluation Part I: Introduction and
General Model; Version 3.1 Revision 4 CCMB-2012-09-001
18. Common Criteria for Information Technology Security Evaluation Part II: Security Functional
Requirements; Version 3.1 Revision 4 CCMB-2012-09-002
19. Common Criteria for Information Technology Security Evaluation Part III: Security Assurance
Requirements; Version 3.1 Revision 4 CCMB-2012-09-003
20. Common Criteria for Information Technology Security Evaluation, Evaluation Methodology;
Version 3.1, Revision 4, CCMB-2012-09-004