Security Target for
SSR_Core v1.0
Version Lite
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 2/101
Author
Name - Surname Title Date
Ercan Ã‡INAR Project Engineer 31.01.2020
Quality Department Approval
Name - Surname Title Date
Fatma Ã‡INAR Quality Manager 31.01.2020
Approver
Name - Surname Title Date
Serkan ORÃ‡AN Project Manager 31.01.2020
Revision History
Rev. No Author Change Summary Date
1.0 GÃ¶kÃ§enur CANLI First Creation 24.05.2016
1.1 GÃ¶kÃ§enur CANLI Observation report findings were corrected. 01.07.2016
1.1 GÃ¶kÃ§enur CANLI
Design arrangement was done,and page
numbers were added.
01.07.2016
1.1 GÃ¶kÃ§enur CANLI Document name was changed. 01.07.2016
1.2 GÃ¶kÃ§enur CANLI Observation reports finding was corrected. 14.07.2016
1.3 GÃ¶kÃ§enur CANLI Observation report 02 finding was corrected. 02.08.2016
1.4 GÃ¶kÃ§enur CANLI
Observation report 2.1.2 findings were
corrected
08.08.2016
1.5 GÃ¶kÃ§enur CANLI
Observation report 02 -3.2.2 findings were
corrected
11.08.2016
1.6 GÃ¶kÃ§enur CANLI
Observation report 02 -4.3.2 findings were
corrected
07.08.2016
1.7 GÃ¶kÃ§enur CANLI Observation report 07 findings were corrected 13.10.2016
1.8 GÃ¶kÃ§enur CANLI
Observation report 07 v2.1.2 findings were
corrected.
04.11.2016
1.9 GÃ¶kÃ§enur CANLI Observation report 11 findings were corrected 18.01.2017
2.0 GÃ¶kÃ§enur CANLI Observation report 16 findings were corrected 23.05.2017
2.1 GÃ¶kÃ§enur CANLI PP v2.8 changes were applied. 14.11.2017
2.2
Ziya Ã–vÃ¼nÃ§
BABADAÄžI
Observation report 20 findings were corrected 06.02.2018
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 3/101
2.3
Ziya Ã–vÃ¼nÃ§
BABADAÄžI
Observation report 23 findings were corrected 29.03.2018
2.4
Ziya Ã–vÃ¼nÃ§
BABADAÄžI
Observation report 23 findings were corrected 10.04.2018
2.5
Ziya Ã–vÃ¼nÃ§
BABADAÄžI
Observation report 24 findings were corrected 09.05.2018
2.6
Ziya Ã–vÃ¼nÃ§
BABADAÄžI
Observation report 24 v2.1.2 findings were
corrected
23.05.2018
2.7
Ziya Ã–vÃ¼nÃ§
BABADAÄžI
Observation report 25 v1.0.2 findings were
corrected
29.06.2018
2.8
Ziya Ã–vÃ¼nÃ§
BABADAÄžI
Observation report findings were corrected 28.09.2018
2.9
Ziya Ã–vÃ¼nÃ§
BABADAÄžI
Observation report findings were corrected 21.12.2018
2.10
Ziya Ã–vÃ¼nÃ§
BABADAÄžI
Observation report findings were corrected 15.01.2020
Lite Ercan Ã‡INAR Lite Verison was created 31.01.2020
TABLE OF CONTENT
TABLE OF CONTENT........................................................................................................................................3
LIST OF TABLES................................................................................................................................................6
LIST OF FIGURES..............................................................................................................................................6
1.INTRODUCTION .............................................................................................................................................7
1.1 SECURITY TARGET AND TOE REFERENCE...........................................................................................................7
1.2 TOE OVERVIEW ..................................................................................................................................................7
1.2.1 The usage and Major Security Features of TOE...........................................................................................7
1.2.2 TOE Type .....................................................................................................................................................9
1.2.3 Non TOE Hardware/Software/Firmware.....................................................................................................9
1.2.3.1 SOFTWARE/FIRMWARE ENVIRONMENT OF TOE ............................................................................................9
1.2.3.2 HARDWARE ENVIRONMENT OF TOE (SSR HARDWARE) .............................................................................10
1.3 TOE DESCRIPTION.............................................................................................................................................11
1.3.1 LIFE CYCLE.....................................................................................................................................................11
1.3.2 TOE PHYSICAL SCOPE....................................................................................................................................11
1.3.3 TOE LOGICAL SCOPE .....................................................................................................................................12
2. CONFORMANCE CLAIM............................................................................................................................13
2.1 CC CONFORMANCE CLAIM................................................................................................................................13
2.2 PP CLAIM ..........................................................................................................................................................14
2.3 CONFORMANCE RATIONALE ..............................................................................................................................14
2.4 PACKAGE CLAIM ...............................................................................................................................................14
3. SECURITY PROBLEM DEFINITION.........................................................................................................15
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 4/101
3.1 INTRODUCTION ..................................................................................................................................................15
3.1.1 ASSETS ...........................................................................................................................................................15
3.1.2 SUBJECTS AND EXTERNAL ENTITIES...............................................................................................................17
3.2 ASSUMPTIONS....................................................................................................................................................19
3.3 THREATS............................................................................................................................................................21
3.4 ORGANIZATIONAL SECURITY POLICIES..............................................................................................................25
3.5 RELEVANCE OF THREATS, OSPS AND ASSUMPTIONS TO THE THREE TOE TYPES...............................................27
4. SECURITY OBJECTIVES............................................................................................................................29
4.1 SECURITY OBJECTIVES FOR TOE.......................................................................................................................29
4.2 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ........................................................................34
4.3 APPLICATION OF SECURITY OBJECTIVES TO THE TOE ON DIFFERENT SSR TYPES ............................................39
4.4 SECURITY OBJECTIVES RATIONALE...................................................................................................................43
4.5 COVERAGE OF THREATS, OSPS AND ASSUMPTIONS BY THE SECURITY OBJECTIVES.........................................50
5. EXTENDED COMPONENT DEFINITION..................................................................................................58
5.1 FPT_IDA IMPORTED TSF DATA AUTHENTICATION ..............................................................................58
5.1.1 FPT_IDA.1 IMPORTED TSF DATA AUTHENTICATION ........................................................................58
5.2 FPT_SSY STATE SYNCHRONIZATION ......................................................................................................58
5.2.1 FPT_SSY.1 STATE SYNCHRONIZATION.................................................................................................59
6. SECURITY REQUIREMENT.......................................................................................................................59
6.1 SECURITY FUNCTIONAL REQUIREMENT.............................................................................................................59
6.1.1 CLASS FAU: SECURITY AUDIT................................................................................................................60
6.1.1.1 FAU_GEN.1- AUDIT DATA GENERATION ....................................................................................................60
6.1.1.2 FAU_ARP.1 - SECURITY ALARMS ..............................................................................................................61
6.1.1.3 FAU_SAR.1 AUDIT REVIEW .......................................................................................................................61
6.1.1.4 FAU_STG.1 PROTECTED AUDIT TRAIL STORAGE ........................................................................................61
6.1.1.5 FAU_STG.4 - PREVENTION OF AUDIT DATA LOSS .......................................................................................62
6.1.1.6 FAU_SAA.1 - POTENTIAL VIOLATION ANALYSIS ........................................................................................62
6.1.2 CLASS FCS: CRYPTOGRAPHIC SUPPORT ..............................................................................................62
6.1.2.1 FCS_CKM.1/SM - CRYPTOGRAPHIC KEY GENERATION FOR SECURE MESSAGING WITH EID, SA, EBS, EPP
AND ROLE HOLDER .................................................................................................................................................62
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 .............................................................63
6.1.2.3 FCS_CKM.1/IVA_KEYS - CRYPTOGRAPHIC KEY GENERATION FOR IVA CONFIDENTIALITY AND INTEGRITY
................................................................................................................................................................................63
6.1.2.4 FCS_CKM.4 - CRYPTOGRAPHIC KEY DESTRUCTION ...................................................................................64
6.1.2.5 FCS_COP.1/SHA-256 - CRYPTOGRAPHIC OPERATION SHA 256 ................................................................64
6.1.2.6 FCS_COP.1/AES-CBC - CRYPTOGRAPHIC AES CBC OPERATION .............................................................65
6.1.2.7 FCS_COP.1/AES-CMAC - CRYPTOGRAPHIC CMAC OPERATION ..............................................................66
6.1.2.8 FCS_COP.1/RSA - CRYPTOGRAPHIC RSA ENCRYPTION OPERATION..........................................................66
6.1.2.9 FCS_COP.1/SIGN_VER - CRYPTOGRAPHIC SIGNATURE VERIFICATION OPERATION ....................................67
6.1.3 CLASS FIA: IDENTIFICATION AND AUTHENTICATION .....................................................................68
6.1.3.1 FIA_AFL.1 AUTHENTICATION FAILURE HANDLING.....................................................................................68
6.1.3.2 FIA_UID.2 USER IDENTIFICATION BEFORE ANY ACTION.............................................................................68
6.1.3.3 FIA_UAU.2 USER AUTHENTICATION BEFORE ANY ACTION.........................................................................69
6.1.3.4 FIA_UAU.5 MULTIPLE AUTHENTICATION MECHANISMS.............................................................................69
6.1.3.5 FIA_UAU.6 - RE-AUTHENTICATING............................................................................................................71
6.1.3.6 FIA_UAU.7 PROTECTED AUTHENTICATION FEEDBACK...............................................................................72
6.1.4 CLASS FCO: COMMUNICATION ..............................................................................................................72
6.1.4.1 FCO_NRO.2 ENFORCED PROOF OF ORIGIN FOR IDENTITY VERIFICATION ASSERTION ................................72
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 5/101
6.1.5 CLASS FMT: SECURITY MANAGEMENT ...............................................................................................73
6.1.5.1 FMT_MOF.1 /VERIFY- MANAGEMENT OF SECURITY FUNCTIONS BEHAVIOR - VERIFY................................73
6.1.5.2 FMT_MOF.1 /UPGRADE-MANAGEMENT OF SECURITY FUNCTIONS BEHAVIOR - UPGRADE .........................73
6.1.5.3 FMT_MTD.1/SAM-PIN MANAGEMENT OF TSF DATA...............................................................................74
6.1.5.4 FMT_MTD.1/DTN MANAGEMENT OF TSF DATA - DEVICE TRACKING NUMBER.......................................74
6.1.5.5 FMT_MTD.1/TIME MANAGEMENT OF TSF DATA -TIME ............................................................................74
6.1.5.6 FMT_SMF.1 SPECIFICATION OF MANAGEMENT FUNCTIONS ......................................................................75
6.1.5.7 FMT_SMR.1 SECURITY ROLES ...................................................................................................................75
6.1.6 CLASS FPT: PROTECTION OF THE TSF...................................................................................................76
6.1.6.1 FPT_STM.1 RELIABLE TIME STAMPS .........................................................................................................76
6.1.6.2 FPT_IDA.1/CVC â€“ IMPORTED TSF DATA AUTHENTICATION - CARD VERIFIABLE CERTIFICATES..............76
6.1.6.3 FPT_IDA.1/X509 - IMPORTED TSF DATA AUTHENTICATION â€“ X509 CERTIFICATES .................................76
6.1.6.4 FPT_IDA.1/IVP - IMPORTED TSF DATA AUTHENTICATION - IDENTITY VERIFICATION POLICY .................77
6.1.6.5 FPT_IDA.1/OCSP IMPORTED TSF DATA AUTHENTICATION - OCSP .........................................................77
6.1.6.6 FPT_IDA.1/TOE_UPGRADE - IMPORTED TSF DATA AUTHENTICATION - TOE UPGRADE PACKAGE .........77
6.1.6.7 FPT_SSY.1/CERT STATE SYNCHRONIZATION -SECURE MESSAGING AND ROLE CVC................................78
6.1.6.8 FPT_SSY.1/SAM STATE SYNCHRONIZATION -SAM ..................................................................................78
6.1.6.9 FPT_SSY.1/IVC STATE SYNCHRONIZATION -IVC......................................................................................78
6.1.6.10 FPT_SSY.1/RH_AUTH_STATUS STATE SYNCHRONIZATION ROLE HOLDER AUTHENTICATION STATUS..79
6.1.6.11 FPT_TST.1 TSF TESTING ..........................................................................................................................79
6.1.6.12 FPT_FLS.1 FAILURE WITH PRESERVATION OF SECURE STATE ...................................................................80
6.1.7 CLASS FDP: USER DATA PROTECTION..................................................................................................80
6.1.7.1 FDP_IFC.1 SUBSET INFORMATION FLOW CONTROL ...................................................................................80
6.1.7.2 FDP_IFF.1 SIMPLE SECURITY ATTRIBUTES ................................................................................................80
6.1.7.3 FDP_ETC.2 EXPORT OF USER DATA WITH SECURITY ATTRIBUTES............................................................82
6.1.7.4 FDP_RIP.1 SUBSET RESIDUAL INFORMATION PROTECTION .........................................................................82
6.1.8 CLASS FTP: TRUSTED PATH/CHANNELS ..............................................................................................82
6.1.8.1 FTP_ITC.1 INTER-TSF TRUSTED CHANNEL.................................................................................................82
6.2 APPLICATION OF SFRS TO TOE ON DIFFERENT SSR TYPES AND BIOMETRIC SENSOR/EPP
CONFIGURATION................................................................................................................................................83
6.3 SECURITY ASSURANCE REQUIREMENTS ...............................................................................................83
6.4 SECURITY REQUIREMENTS RATIONALE ................................................................................................83
6.4.1 SECURITY FUNCTIONAL REQUIREMENTS RATIONALE...................................................................83
6.4.2 SECURITY FUNCTIONAL REQUIREMENTS RATIONALE TABLES ...................................................90
6.4.3 SECURITY ASSURANCE REQUIREMENTS RATIONALE.....................................................................94
7. TOE SUMMARY SPECIFICATION ............................................................................................................95
7.1 TOE SECURITY FUNCTIONS...............................................................................................................................95
7.1.1 SECURITY AUDIT ............................................................................................................................................95
7.1.2 CRYPTOGRAPHIC SUPPORT .............................................................................................................................95
7.1.3 IDENTIFICATION AND AUTHENTICATION.........................................................................................................96
7.1.4 COMMUNICATION ...........................................................................................................................................96
7.1.5 SECURITY MANAGEMENT ...............................................................................................................................97
7.1.6 PROTECTION OF THE TSF................................................................................................................................97
7.1.7 USER DATA PROTECTION................................................................................................................................98
7.1.8 TRUSTED PATH/CHANNELS.............................................................................................................................98
8. ACRONYMS ..................................................................................................................................................98
9. REFERENCES............................................................................................................................................. 100
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 6/101
LIST OF TABLES
Figure 1.TOE Architecture ............................................................................................................................................9
Figure 2 SSR Hardware...............................................................................................................................................10
Figure 3. TOE Life Cycle ............................................................................................................................................11
Figure 4 Physical Scope of TOE .................................................................................................................................12
Table 1 Primary and Secondary Assets .......................................................................................................................15
Table 2 Legitimate and malicious actors and external systems ...................................................................................17
Table 3. Assumptions ..................................................................................................................................................19
Table 4. Threats...........................................................................................................................................................21
Table 5. Organizational Security Policies....................................................................................................................25
Table 6. Security Objectives of the TOE.....................................................................................................................29
Table 7. Security Objectives for the Operational Environment...................................................................................34
Table 8. Application of Objectives to the TOE on different SSR Types .....................................................................39
Table 9. Application of Environment Objectives to the different SSR Types and User Environments of different SSR
Types ...........................................................................................................................................................................41
Table 10. Security Objectives Rationale Table for TOE on Either SSR Type I,II without Biometric Sensor and
External Pin Pad ..........................................................................................................................................................52
Table 11. Environmental Security Objectives Rationale Table for TOE on Either SSR Type I, II without External
Biometric Sensor and External Pin Pad.......................................................................................................................54
Table 12 Additions to Security Objective Rationale due to differences of SSR Type II from SSR Type I.................55
Table 13 Additions to Security Objective Rationale for TOE on SSR with External/Internal Biometric Sensor and/or
EPP ..............................................................................................................................................................................56
Table 14 SFR Rationale Table for TOE on SSR Type I without Biometric Sensor and External PIN Pad.................90
Table 15 .SFR Rationale for additional objectives of TOE on SSR Type II ...............................................................93
Table 16 SFR rationale additions for TOE on SSR with External/Internal Biometric Sensor and/or EPP..................93
Table 18. Acronyms ....................................................................................................................................................98
LIST OF FIGURES
Figure 1.TOE Architecture............................................................................................................................................9
Figure 2 SSR Hardware...............................................................................................................................................10
Figure 3. TOE Life Cycle ............................................................................................................................................11
Figure 4 Physical Scope of TOE .................................................................................................................................12
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 7/101
1.Introduction
1.1 Security Target and TOE Reference
ST Title Security Target for SSR_Core v1.0
ST Version Lite
TOE Identification SSR_Core v1.0
CC Conformance Common Criteria for Information Technology Security Evaluation,
Version 3.1 (revision 5)
PP Conformance Protection Profile for Application Firmware of Secure Smartcard
Reader (SSR) for National Electronic Identity Verification System,
SSR_PP_2.8
Assurence Level Evaluation Assurance Level 4 augmented with ALC_DVS.2
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 which is run on microcontroller 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 The usage and Major Security Features of TOE
The following security mechanisms are primarily mediated in the TOE:
â€¢ Identification and Authentication,
o Cardholder verification by using PIN and biometrics (fingerprint).
o Authentication of eID Card by the TOE,
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 8/101
o Authentication of Role Holder by eID Card and by the TOE,
o Authentication of SAM by the TOE and by eID Card,
o 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),
â€¢ Secure Communication between the TOE and
o SAM
o eID Card
o Role Holder
o 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.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 9/101
Figure 1.TOE Architecture
1.2.2 TOE Type
The TOE is the SSR Device firmware. The lifecycle of TOE is described in part 1.3.1. The TOE
covers type I, II(with SAS/without SAS) secure smart card reader.
1.2.3 Non TOE Hardware/Software/Firmware
1.2.3.1 Software/Firmware Environment of TOE
â€¢ File System and Software Libraries
â€¢ Embedded Operating System Kernel
â€¢ Smartcard Reader IC Firmware
In a 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
security target.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 10/101
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 SSR
Hardware environment of TOE is shown below
Figure 2 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).
Some hardware components such as biometric sensor, Ethernet port or second smartcard slots are
optional depending on SST type.
RTC Keypad Display
CPU
Smartcard
Controller
I/O
Interface
SAM
Memory:
(TOE)
Sensors
SC
Slot#1
SC
Slot#2
Smartcard
Controller
Smartcard
Controller
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 11/101
1.3 TOE Description
1.3.1 Life Cycle
The Initialization&Configuration and Operation life cycle of Secure Smart Card Reader is given
in Figure 3. During Initialization&Configuration life cycle, SAM Pin with 16 characters is entered.
Also, Device Type and Device Number are entered for forming Device Tracking Number. During
Operation phase, device is ready to operate. After the device enters to Operation Phase, the only
condition for the device to switch to Initialization&Configuration Phase is tampering event. If a
tamper event occurs in Operation Phase, the device switchs back to Initialization&Configuration
Phase by deleting cryptographic keys and other necessary files.
Figure 3. TOE Life Cycle
1.3.2 TOE Physical Scope
The Target of Evaluation provides all functionality(secure messaging, communication with
external device and fingerprint sensors) of secure smart card reader.
The TOE runs at the top of an embedded Linux operating system and 528 MHz , ARM Cortex-
A7 NXP Freescale imx6ul-2 microprocessor.
The physical scope of TOE is like shown below at Figure 4. TOE operates on memory while
running in Operation Phase and cryptographic operations of TOE are performed on memory.
Memory and CPU are combined in a single module. There are 3 card readers on the device, one
for Service Requester, one for Service Attendee and one for SAM. There is an SD Card for
extending memory on device. There is one fingerprint sensor used for biometric validation and
there are several sensors for detecting tamper event. There are two interfaces for communicating
with Application Software, one is via Usb Otg and the other is via Ethernet. There are 2 Usb Hosts
for external devices. There is a touch screen on the device for user interface and there are 16 keys
on a 4x4 keypad. There exists a Real Time Clock for synchronizing time on device.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 12/101
Figure 4 Physical Scope of TOE
TOE will be delivered to customer after being installed on Secure Smart Card Reader produced by
UDEA Elektronik. The label showing that this device is a certified product of UDEA Elektronik
will be attached onto the product. The product will be delivered to the customer in a box that
contains the logo of UDEA Elektronik.
1.3.3 TOE Logical Scope
The primary security features of the TOE are:
â€¢ Security audit : TOE Security Functionality generates an audit record of the auditable
events which will be explained in ST. This feature involves recognising, recording, storing,
and analysing information related to security relevant activities. This feature provides
operation system conjuction protection. To illustrate, user identification results, biometric
verification failures, GEM certificates status check results, cryptographic symmetric key
generation success/fail status are recorded and stored by the TOE.
â€¢ Cryptographic Support : Cryptographic support is essential for high security level for the
TOE. This feature involves Encryption/Decryption, Cryptographic key generation,
distribution, operation ,and destruction is supplied by the TOE. To illustrate, Secure
messaging requires encryption and decryption of trasmitted and received data. The
cryptographic methods which will be explained in 6.1.2 are provided by the TOE.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 13/101
â€¢ Identification and Authentication: This feature contains that the users must be identified
and authenticated before any action which related to security on the TOE. User roles (Role
provider, SAM, eID) are defined on system.Authentication failure handling, user
identification and athentication, Multiple authentication mechanism for different users, re-
authenticating, protected authentication feedback are supplied by the TOE.
â€¢ Communication : This feature contains that evidence generation of origin for transmitted
Identity Verification Assertion Data is supplied by the TOE. Identity Cerification Assertion
is created end of the identification and authentcation steps.After that ,IVA is signified by
SAM and evidence is ensured.
â€¢ Security Management: This feature contains managing security functions (Software
initialization, upgrade) and data for diffirent situations. Security roles, rules and conditions
are identified and management is supplied according to roles,rules and conditions and only
authorized people access the TOE.
â€¢ Protection of the TSF:. The TOE protects the TOE Security Functions and TSF data. This
feature contains protection of cryptographic keys, digital signiture protection/verification,
data authentication, software integrity self-test and other TSF data protection.
â€¢ User Data Protection: This feature incloses monitoring user data stored in containers
controlled by the TSF for any integrity error. Critical data in terms of keys, user passwords
is used by the TOE and it is protected against losing and stoling. Integrity checking method,
subset flow control rules, security attributes are provided by the TOE.
â€¢ Trusted Path/Channels: This feature involves cryptographic communication protocols
between itself and defined trusted products in FTP_ITC.1.1. To illustrate, Trusted path
between SSR Access Server and Application Server is provided by SSL-TLS.
2. Conformance Claim
2.1 CC Conformance Claim
This ST claims conformance to
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 14/101
â€¢ Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and
General Model; CCMB-2017-04-001 Version 3.1 Revision 5, April 2017, (CC Part 1)
â€¢ Common Criteria for Information Technology Security Evaluation, Part 2: Security
Functional Components; CCMB--2017-04-002 Version 3.1 Revision 5, April 2017, (CC Part
2)
â€¢ Common Criteria for Information Technology Security Evaluation, Part 3: Security
Assurance Requirements; CCMB--2017-04-003 Version 3.1 Revision 5, April 2017, (CC
Part 3)
As follows
â€¢ Part 2 extended
â€¢ Part 3 conformant
The common Methodology for Information Technology Security Evaluation , Evaluation
Methodology; CCMB-2017-04-004 Version 3.1 Revision 5, April 2017, [CEM] has to be taken
into account.
2.2 PP Claim
This ST claims conformance to
â€¢ Protection Profile for Application Firmware of Secure Smartcard Reader (SSR) for National
Electronic Identity Verification System, SSR_PP_2.8
2.3 Conformance Rationale
This ST claims conformance to
â€¢ Protection Profile for Application Firmware of Secure Smartcard Reader (SSR) for National
Electronic Identity Verification System, SSR_PP_2.8
2.4 Package Claim
This ST is conforming to assurance package EAL4 augmented with ALC_DVS.2 defined in CC
part 3.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 15/101
3. Security Problem Definition
This part of the ST 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 Introduction
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 brings about additional security needs. Therefore, in this ST document, Security
Problem Definition, Security Objectives and Security Functional Requirements are designed to
cover all the possible alternatives.
3.1.1 Assets
The Secure Smart Card Reader (SSR) and the TOE is a part of e-ID 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 e-ID Card. TOE shall securely forward the user data read out from the e-ID Card;
however, TOE does not store any user data.
The TOE defined in this ST (the Application Firmware of the SSR) does not possess any user data.
Table 1 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
3. Identity Verification
Assertion (IVA)
Generated as the
evidence of the identity
verification operation.
Privacy and authenticity
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 16/101
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
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 17/101
8. Secure Messaging and
Role Card Verifiable
Certificates of SAM (in
CVC Format)
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.1.2 Subjects and External Entities
Table 2 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 2.
Table 2 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
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 18/101
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 Illegimate eID Card
Service Requester(SR) Identity Faker (nor 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 Illegimate SAM
External Biometric Sensor Illegimate External Biometric Sensor
External PIN PAD Illegimate External PIN PAD
Secure Smart Card Reader (SSR) hardware Illegimate SSR Hardware (manipulated and/or
probed)
Role Holder Illegimate Role Holder (Malicious)
The Proxy Entities
PC (on which the SPCA run) See Note 3.
Other Activities
Initialization agent -
Manufacturer service operator Illegimate service operator
Attacker
Attacker (also covers the Identity Faker, SA
Masquerader, Illegimate, Role Holder)
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 19/101
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 ST, 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.
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.2 Assumptions
The assumptions for the operational environment are given in Table 3.
Table 3. 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 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.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 20/101
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_Environ
ment
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.
A.SSR_Platform The SSR platform supports the security functionality of the TOE and does not
undermine the security properties of it. The SSR platform does not provide any
opportunities to the attacker to manipulate or bypass the security functionality
of the TOE. The TSF architecture is resistant against attacks that can be
performed by attackers possessing Enhanced-Basic attack potential
(AVA_VAN.3), it is assumed that SSR Platform does not offer any attack
interface to the attacker with enhanced basic attack potential to break the TSF
architecture. SSR Platform will store TOE encrypted during nonoperation
times. SSR Platform will decrypt and authenticate the TOE during starting up
the TOE.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 21/101
3.3 Threats
The threats that could be met by the TOE and its environment are given in below table.
Table 4. Threats
Threat Definition
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
(valid for Type II TOE)
The attacker may obtain Identity Verification Assertion by
monitoring the communication line between SAS and type II
TOE.
T.Repudiation The Service Requester (or the Service Attendee) may
repudiate the Identification Verification Assertion.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 22/101
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_Entiti
es
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.
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.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 23/101
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 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 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.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 24/101
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.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.
T.Audit_Data_Compromise An attacker may read, change or delete the audit data.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 25/101
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.4 Organizational Security Policies
The OSPs are given in Table 5.
Table 5. 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 and remote upgrade.
P.Re-Authentication Authentication of third party IT components will be renewed after 24
hours.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 26/101
P.Revocation_Control In case SSR Device cannot reach to OCSP Server, downloading the
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.
P.Tamper_Response The SSR platform will be able to detect any tampering attempts and will
notify the TOE. The TOE will respond to this notification by securely
deleting the SAM-PIN and getting into Initialization & Configuration
phase.
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.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 27/101
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.5 Relevance of Threats, OSPs and Assumptions to the three TOE types
Threats, OCPs and assumptions defined in the Security Problem Definition are matched with the
three types of the SSR Device below.
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 TOE on SSR Type II
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
T.SA_Abuse_of_Session Applies to TOE on SSR Type II
T.Fake_Policy Applies to all
T.Fake_OCSP_Response Applies to all
T.RH_Comm Applies to all
T.Counterfeit_eIDC Applies to all
T.RH_Session_Hijack Applies to all
T.Illegitimate_EBS Applies to TOE on SSR with External Biometric
Sensor
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 28/101
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.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
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.IVM_Management Applies to all
P.DPM Applies to all
P.Revocation_Control Applies to TOE on SSR Type I, Type II but
differently.
P.Tamper_Response Applies to all
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
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 29/101
A.SSR_Platform Applies to all
4. Security Objectives
In this section part-wise solutions are given against the security problem defined in Part 3.
4.1 Security Objectives for TOE
Table 6. 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
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 30/101
SRR, then the information that OCSP check 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_Verificati
on
The TOE shall support Biometric Verification defined in TS 13584 [3]
for Identification and Authentication of Service Requester and Service
Attendee if applicable.
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 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_Verifica
tion
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) , EPP if applicable, EBS if applicable)
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 31/101
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.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.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].
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].
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 32/101
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 have TOE update security management function. 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:
(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,
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 13584 [3].
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 33/101
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 SSR hardware.
OT.DTN_Integrity The TOE shall protect the integrity of the Device Tracking Number.
OT.Audit_Data_Protecti
on
The TOE shall control access to the audit data and shall not allow
attackers to read, change or delete.
OT.RIP
[Residual Information
Protection]
PIN, Biometry data, other user data and TSF data shall be copied to only
volatile memory and be deleted in a secure way right after the end of
the usage.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 34/101
OT.Auth_SAM_by_TOE
[Authentication of SAM
by TOE]
The TOE shall authenticate the SAM before doing any operation.
OT.IVA_Signing The created Identity Verification Assertion shall be electronically
signed by the TOE (using SAM). Otherwise the secure channel is
founded in between SPCA and IVS.
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) and update the certificates.
4.2 Security Objectives for the Operational Environment
Table 7. 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).
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),
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 35/101
â€¢ 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, finger vein and palm
vein),
â€¢ 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],
â€¢ 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,
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 36/101
â€¢ 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:
â€¢ Supports the verification of the authenticity of the IVA with the
Authentication Reference Data (Public Key of IVA Signing Certificateâ€™s
integrity is protected)
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 37/101
OE.SSR_Platform The SSR platform will support the security functionality of the TOE and does
not undermine the security properties of it. The SSR platform does not provide
any opportunities to the attacker, who is possessing enhanced basic attack
potential, to manipulate or bypass the security functionality of the TOE. The
TSF architecture will be resistant against attacks that can be performed by
attackers possessing Enhanced-Basic attack potential (AVA_VAN.3), SSR
Platform will not offer any attack interface to the attacker with enhanced basic
attack potential to break the TSF architecture.SSR Platform will store the TOE
encrypted during nonoperation times. SSR Platform will decrypt and
authenticate the TOE during starting up the TOE. SSR Platform will have
tamper detection mechanism and notify the TOE upon detection of a tamper
event. SSR Platform will enable the TOE to securely delete the SAM-PIN and
cryptographic keys when deleted SAM-PIN and cryptographic keys will be
unrecoverable. SSR Platform will provide correct operation of the TOE. SSR
platform will include a Real Time Clock (RTC) Unit with at most 20 seconds
fault within 24 hours.
OE.EBS The EBS shall:
â€¢ will perform biometric verification correctly
â€¢ 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
to requesting biometric input
OE.EPP The EPP shall:
â€¢ support Secure Communication between the EPP and the
TOE 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
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 38/101
â€¢ protect the confidentiality of the PIN
OE.Role_Holder The role holder shall:
â€¢ act responsively
â€¢ have the appropriate role certificate and its Private Key for Role Holder
Authentication
â€¢ protect the private key used within 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_Managemen
t
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_Direct
ory
SPCA (for TOE on SSR type I or II without SAS), SSR Access Server (for TOE
on Type II with SAS) 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 Authentication, Role Holder Device
Authentication, OCSP Response Verification, Identity Verification Policy
Verification, and the TOE Upgrade Package Verification.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 39/101
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 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_En
vironment
The initialization environment of the SSR Device where SAM PIN is defined
to the SSR shall be physically secure.
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 8.
Table 8. 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 configuration
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 40/101
OT.Biometric_Verification
Applies to configurations with external/internal
Biometric Sensor
OT.PM_Verification Applies to all
OT.SA_Identity_Verification Applies to the Type II configuration
OT.Session_Ending Applies to the Type II configuration
OT.Identity_Verificat
ion
Policy_Authentication
Applies to all
OT.OCSP_Query_Verify Applies to all
OT.SAS_DA Applies to TOE on SSR Type II with SAS.
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
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 41/101
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.RIP [Residual Information Protection] Applies to all
OT.Cert_Update Applies to all
OT.Auth_SAM_by_TOE [Authentication
of SAM by TOE]
Applies to all
OT.IVA_Signing Applies to all
OT.Audit_Data_Protection Applies to all
Application of Environment Objectives to the different SSR Types and User
Environments of different SSR Types are given in Table 9.
Table 9. Application of Environment Objectives to the different SSR Types and User Environments of different SSR
Types
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 42/101
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_Attendee Applies to the Type II
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
OE.APS Applies to all
OE.SSR_Initialization_Environment Applies to all
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 43/101
4.4 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
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 44/101
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; 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_Signing 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_Signing, 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_Signing, OE.SAM, OE.IVS, OE.PKI, OE.CM.
T.IVA_Eavesdropping: OT.SAS_SC, and OE.SAS require the secure communication of the
TOE with SAS and APS for SSR Type II. Secure communication prevents the attacker to
obtain IVA by monitoring the communication.
Hence, T.IVA_Eavesdropping is covered by, OT.SAS_SC, OE.APS and OE.SAS
Security Objectives: OT.SAS_SC, OE.APS, OE.SAS
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.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 45/101
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, and EPP are OT.SM_eIDCard, OT.RH_DA, OT.SAS_DA, OT.EBS_DA,
and 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.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
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 46/101
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 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 Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 47/101
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 mechanism 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.
Security Objectives: OT.EPP_DA, OE.SAM, OE.EPP, OE.PKI, OE.CM.
T.EPP_Comm: OT.EPP_SC, OE.EPP and OE.SAM address the secure communication
between the TOE and the EPP therefore cover the threat.
Security Objectives: OT.EPP_SC, 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.DTN_Change: OT.DTN_Mgmt and OE.SSR_Platform addresses the protection against
unauthorized modification to the DTN.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 48/101
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_Protection and OE.SSR_
Platform cover the protection of audit data from unauthorized change.
Security Objective: OT.Security_Failure, OT.Audit_Data_Protection, 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_Protection
protects the audit data from manipulation. OT.RIP provides protection against probing attacks
and de-allocates any resources when they are no longer needed.
Security Objectives: OT.SM_TOE_and_SAM [Security between TOE and SAM], OT.SAM-
PIN_Sec, OT.DTN_Integrity, OT.Audit_Data_Protection, 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
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 49/101
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.OSCPS.
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.
P.Revocation_Control: OT.eIDC_Authentication defines the offline certificate verification together
with OE.CM
Security Objectives: OT.eIDC _Authentication, OE.CM
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.
P.Tamper_Response: OT.Security_Failure and OE.SSR_Platform realize the tamper response
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 50/101
together.
Security Objectives: OT.Security_Failure, OE.SSR_Platform
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_Initialsization_Environment covers the assumption.
Security Objective: OE.SSR_Initialization_Environment.
A.SSR_Platform: OE.SSR_Platform covers the assumption totally.
Security Objective: OE.SSR_Platform
4.5 Coverage of Threats, OSPS and Assumptions by the Security Objectives
Table 10, Table 11, Table 12 and Table 13 give the coverage of threats, OSPs and assumptions by
the security objectives. Table 10 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 11 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
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 51/101
presence of EPP, biometric sensor and optional offline mode features, additions to the rationale
given in Table 12 and Table 13.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 52/101
Table 10. Security Objectives Rationale Table for TOE on Either SSR Type I,II without Biometric Sensor and External Pin Pad
OT.IVM_Management
OT.Security_Failure
OT.
eIDC
_Authentication
OT.PIN_Verification
OT.IVA_Signing
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_DataProtection
OT.RIP
OT.Auth_SAM_by_TOE
OT.Cert_Update
OT.PM_Verification
T.Counterfeit_eIDC x x x
T.Revoked_eIDC x
T.Stolen_eIDC x
T.IVA_Fraud x
T.Repudiation x
T.Fake_TOE_to_SR x
T.Fake_TOE_to_External
Entities
x x
T.Fake_Policy x
T.Fake_OCSP_Response x
T.RH_Comm x
T.RH_Session_Hijack x x
T.eIDC_Comm x
T.DTN_Change x
T.SAM-PIN_Theft x x x
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 53/101
T.Audit_Data_Compromi
se
x x
T.TOE_Manipulation x x x x x
T.Fake_SAM x
T.Stolen_SAM x x x x
T.Revoked_SAM x
P.IVM_Management x
P.TOE_Upgrade x
P.Terminal_Cert_Update x
P.Re-Authentication x
P.Time_Update x
P.Revocation_Control x
P.DPM x x x
P.Tamper_Response x
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 54/101
Table 11. Environmental Security Objectives Rationale Table for TOE on Either SSR Type I, II without External Biometric Sensor and External Pin Pad
T.SAM-PIN_Theft x
T.Audit_Data_Compromise x
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_Environme
nt
T.Counterfeit_eID Card x x x x
T.Revoked_eID Card x x x x
T.Stolen_eID Card x x x x
T.IVA_Fraud x x x x
T.Repudiation x x x x
T.Fake_TOE_to_SR x x x x x
T.Fake_TOE_to_External_Entities x x x x
T.Fake_Policy x x x
T.Fake_OCSP_Response x x x
T.RH_Comm x x
T.RH_Session_Hijack x x x x x
T.eIDC_Comm x x
T.DTN_Change x
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 55/101
T.TOE_Manipulation x
T.Fake_SAM x x x
T.Stolen_SAM x x
T.Revoked_SAM x x
P.TOE_Upgrade x x x x
P.Terminal_Cert_Update x x
P.Revocation_Control x
P.Tamper_Response x
A.SPCA x
A.IVPS x
A.EBS-EPP
A.PC x
A.APS x
A.Management_Environment x
A.SAM_ PIN_Environment x
A.SSR_Platform x
TOE on SSR Type II 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. The additions for the coverage of the threats,
OCPs and assumptions (that are not valid for Type I) is given in Table 12.
Table 12 Additions to Security Objective Rationale due to differences of SSR Type II from SSR Type I
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 56/101
OT.Photo_Verification
OE.Service_Attendee
OT.SA_Identity_Verification
OT.Session_Ending
OT.SAS_DA
OT.SAS_SC
OE.APS
OE.SAS
OE.PKI
OE.CM
OE.SAM
OE.eID_Card
T.Illegitimate_SAS (SSR Type II) x x
T.IVA_Eavesdropping x x x
T.Fake_TOE_to_External_Entities x
T.Stolen_eIDC x x
T.SA_Masquerader x x x x x
T.SA_Abuse_of_Session x x
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 13.
Table 13 Additions to Security Objective Rationale for TOE on SSR with External/Internal Biometric Sensor and/or EPP
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 57/101
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 x
T.Fake_TOE_to_External_Entities x x x x
T.Repudiation x
T.Illegitimate_EPP x x x x x
T.EPP_Comm x x x
T.Illegitimate_EBS x x x x x
T.EBS_Comm x x x
A.EBS-EPP x x
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 58/101
5. Extended Component 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
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].
5.2 FPT_SSY STATE SYNCHRONIZATION
Family Behavior:
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 59/101
This family requires that the TOE has ability to synchronize its internal state with another trusted external
entity.
Component Leveling:
5.2.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
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].
6. Security Requirement
6.1 Security Functional Requirement
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;
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 60/101
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 minimum 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 authentication, external
biometric sensor authentication, external pin pad authentication, SAM authentication,
SAM-PIN verification failure, TOE update, IVP verification, OCSP answer
verification, SAS authentication and tampering of the SSR.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 61/101
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).
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 security upon detection of a potential
security violation.
6.1.1.3 FAU_SAR.1 Audit review
Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
FAU_SAR.1.1 The TSF shall provide the administrator users with the capability to read all of the audit
information from the audit records.
FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the user to interpret the
information.
6.1.1.4 FAU_STG.1 Protected audit trail storage
Hierarchical to: No other components.
Dependencies: [FAU_GEN.1 Audit data generation] fulfilled by FAU_GEN.1
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 62/101
FAU_STG.1.1 The TSF shall protect the stored audit records in the audit trail from unauthorized
deletion.
FAU_STG.1.2 The TSF shall be able to detect unauthorized modifications to the stored audit records in
the audit trail.
6.1.1.5 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 records and none if the audit trail is full.
6.1.1.6 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 SSR known to indicate a potential security violation;
b) none.
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
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 63/101
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm Encryption and CMAC Key
Generation Algorithm for Secure Messaging and specified cryptographic key
sizes 256 bits that meet the following: TS 13584 [3].
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 above and specified
cryptographic key sizes 256 Bits that meet the following: RFC 5246.
Application Note 3: TLS Key Generation is performed 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
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 64/101
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm True Random Number Generation
and specified cryptographic key sizes 256 bits18
that meet the following: none.
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.
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 overwriting key with zeros that meets
the following: none .
Application Note 5: 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 6: FCS_CKM.4 determines the key destruction method for the secure messaging keys,
secure storage keys and the Upgrade Package key (the decrypted key).
6.1.2.5 FCS_COP.1/SHA-256 - Cryptographic operation SHA 256
Hierarchical to: No other components.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 65/101
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 calculation in accordance with a specified
cryptographic algorithm SHA-256 [5] and cryptographic key sizes none that meet the
following: FIPS 180.
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.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 66/101
FCS_COP.1.1 The TSF shall perform encryption and decryption26
in accordance with a specified
cryptographic algorithm AES-256 CBC Mode and cryptographic key sizes 256 bits that
meet the following: FIPS 197 (for AES) [6], NIST Recommendation for Block Cipher
Modes of Operations (for CBC mode)[ 7].
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 authentication in accordance with a specified
cryptographic algorithm AES-CMAC and cryptographic key sizes 256 bits that meet the
following: FIPS 197 (for AES) [6], RFC 4493 (for CMAC operation) [9].
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.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 67/101
FCS_COP.1.1 The TSF shall perform encryption in accordance with a specified cryptographic
algorithm RSA OAEP and cryptographic key sizes 2048 that meet the following: TS
13584 [3], and RSA Cryptography Standard [10].
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 FPT_IDA.1/X509. 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 Validation in accordance with a specified cryptographic algorithm RSA,
PKCS#1 v2.1 with PSS padding method and cryptographic key sizes 2048 that meet the
following: ETSI TS 102 853[12] and TS 13584 [3].
Application Note 7: 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,
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 68/101
â€¢ 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.
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]) times unsuccessful authentication attempts occur related to Biometric
Verification.
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met, the
TSF shall not allow further biometric verification.
Application Note 8: 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.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 69/101
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.
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 the 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.
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,
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 70/101
â€¢ SAS authentication for TOE on SSR Type II,
â€¢ external PIN Pad authentication (if applicable),
â€¢ external biometric sensor authentication (if applicable)
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 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.
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
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 71/101
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 9: Certificates stored in the SAM are used for the SSL/ TLS client authentication.
Application Note 10: eID Card is the smart card with the 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 not revoked 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 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,
â€¢ SAS authentication for TOE on SSR Type II
â€¢ external PIN Pad authentication (if applicable),
â€¢ external biometric sensor authentication (if applicable).
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 72/101
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, 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 to the user Service Requester or Service Attendee while the
authentication is in progress.
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 Data at all times.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 73/101
FCO_NRO.2.2 The TSF shall be able to relate the identity of origin of the originator of the information,
and the Identity Verification Assertion Data of the information to which the evidence
applies.
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 11: 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. 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 of the function Identity
Verification Operation to the Identity Verification Policy Server or Client Application57
.
Application Note 12: 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
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 74/101
FMT_MOF.1.1 The TSF shall restrict the ability to enable the function TOE Upgrade to Client
Application for TOE on Type I and Type II and Manufacturer service operator.
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 write the SAM-PIN62
to Initialization Agent.
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 write the Device Tracking Number to Initialization
Agent.
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 update the Time to OCSP server.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 75/101
Application Note 13: 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.
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
â€¢ Initialization Agent,
â€¢ SSR Access Server for TOE on SSR Type II,
â€¢ Client Application for TOE on Type I and Type II,
â€¢ Identity Verification Policy Server,
â€¢ OCSP Server,
â€¢ Manufacturer service operator
â€¢ Software Publisher.
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 76/101
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.
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
Certificates
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 Certificates originates from Card Publisher using CVC Authentication
Mechanism defined in TS 13584 [3].
6.1.6.3 FPT_IDA.1/X509 - Imported TSF Data Authentication â€“ X509 Certificates
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_IDA.1.1 The TSF shall verify that the Identity Verification Certificate, Identity Verification
Policy Server Certificate, OCSP Server Certificate, Software Publisher Certificate
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 77/101
originates from Card Publisher and Device Manager using X509 Certificate
Authentication Mechanism defined in TS 13584 [3]
6.1.6.4 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 Policy originates from Identity
Verification Policy Server using IVP authentication mechanism defined in TS 13584
[3].
6.1.6.5 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 Response originates from legitimate OCSP Server
using OCSP Response Verification Mechanism defined TS 13584 [3].
6.1.6.6 FPT_IDA.1/TOE_Upgrade - Imported TSF Data Authentication - TOE Upgrade
Package
Hierarchical to: No other components.
Dependencies: No dependencies.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 78/101
FPT_IDA.1.1 The TSF shall verify that the TOE upgrade package originates from legitimate
Software Publisher using TOE Upgrade Authentication mechanism defined in TS
13584 [3].
6.1.6.7 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 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
in times: at each Identity Verification Operation.
6.1.6.8 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 status from the OCSP Server in
times: immediately after opening of the SSR.
6.1.6.9 FPT_SSY.1/IVC State Synchronization -IVC
Hierarchical to: No other components.
Dependencies: No dependencies.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 79/101
FPT_SSY.1.1 The TSF shall check Identity Verification Certificate revocation status from the OCSP
Server or SSR Platform on which up-to-date Revocation List is present in times: during
Identity Verification Operation.
6.1.6.10 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 Card from the eID Card
in times: after the secure communication between Role Holder and the TSF is
terminated.
Application Note 14: 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.11 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-up to demonstrate the correct
operation of the TSF.
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 data.
FPT_TST.1.3 The TSF shall provide authorized users with the capability to verify the integrity of
[selection: [assignment: parts of TSF], TSF].
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 80/101
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
disturbed.
6.1.7 CLASS FDP: USER DATA PROTECTION
6.1.7.1 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 Policy on :
Subjects:
SPCA (subject of TOE on SSR Type I and SSR Type II), SAS (subject for TOE on SSR
Type II with SAS)
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).
6.1.7.2 FDP_IFF.1 Simple Security Attributes
Hierarchical to: No other components.
Dependencies: FDP_IFC.1 Subset information flow control fulfilled by FDP_IFC.1
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 81/101
FMT_MSA.3 Static attribute initialization 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 based on the following
types of subject and information security attributes: Subjects:
SPCA (subject of TOE on SSR Type I and SSR Type II), SAS (subject for TOE on SSR
Type II with SAS)
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
correspondingly.
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 successfully.
FDP_IFF.1.3 The TSF shall enforce the none.
FDP_IFF.1.4 The TSF shall explicitly authorize an information flow based on the following rules:
none.
FDP_IFF.1.5 The TSF shall explicitly deny an information flow based on the following rules: none.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 82/101
6.1.7.3 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.2.1 The TSF shall enforce the Information Flow Control Policy when exporting user data,
controlled under the SFP(s), outside of the TOE.
FDP_ETC.2.2 The TSF shall export the user data with the user data's associated security attributes.
FDP_ETC.2.3 The TSF shall ensure that the security attributes, when exported outside the TOE, are
unambiguously associated with the exported user data.
FDP_ETC.2.4 The TSF shall enforce the following rules when user data is exported from the TOE:
none.
6.1.7.4 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 from the following objects
cryptographic credentials, IVA data fields, PIN, photo and biometric information.
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
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 83/101
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 and SAS for TOE on SSR Type II (with SAS) 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 TSF to initiate communication via the trusted channel.
FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for all functions.
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 CONFIGURATION
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.
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.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 84/101
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. FCS_COP.1/Sign_Ver verifies the authenticity of the certificate and FPT_IDA.1/X509
verifies the authenticity of the certificate. 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.
SFRs: FIA_UAU.5, FAU_GEN.1, FIA_UID.2, FCS_COP.1/Sign_Ver, FPT_IDA.1/X509, 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
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 85/101
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.
OT.IVA_Signing: 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.
SFRs: FCO_NRO.2, FCS_COP.1/SHA-256
OT.PM_Verification: Since only the legitimate TOE could found secure messaging with eID Card and
read personal 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 personal
message.
SFRs: 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.
SFRs: 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: FDP_ETC.2, FDP_IFC.1 and FDP_IFF.1 define
Information Flow Control Policy for verifying the signature of the Identity Verification Policy sent by the
IVPS. FPT_IDA.1/IVP covers the authentication of policy and FPT_IDA.1/X509 covers the authentication
of the certificate of the policy server. The Identity Verification Policy Authentication mechanism addressed
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 86/101
in the FPT_IDA.1/IVP and FPT_IDA.1/X509 require the cryptographic support of FCS_COP.1/ Sign_Ver.
FAU_GEN.1 audits the authentication.
SFRs: FDP_ETC.2, FDP_IFC.1, FDP_IFF.1, FPT_IDA.1/IVP, FPT_IDA.1/X509, FCS_COP.1/ Sign_Ver
and FAU_GEN.1.
OT.OCSP_Query_Verify: FDP_ETC.2, FDP_IFC.1 and FDP_IFF.1 define Information Flow Control
Policy for verifying the signature of the OCSP Query Response sent by the OCSPS. FPT_IDA.1/OCSP
covers the authentication of query response and FPT_IDA.1/X509 covers the authentication of the
certificate of the OCSP server. 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: FDP_ETC.2, FDP_IFC.1, FDP_IFF.1 ,FPT_IDA.1/OCSP, FPT_IDA.1/X509, FCS_COP.1/
Sign_Ver and FAU_GEN.1.
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.
SFRs: 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.
SFRs: FTP_ITC.1, FCS_CKM.1/SM, FCS_CKM.4, FCS_COP.1/AES-CBC, FCS_COP.1/AES-CMAC.
OT.RH_Session_Ending: FPT_SSY.1/RH_Auth_Status covers the objective.
SFRs: FPT_SSY.1/RH_Auth_Status
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 87/101
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.
SFRs: 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.
SFRs: FTP_ITC.1, FCS_CKM.1/SM, FCS_CKM.4, FCS_COP.1/AES-CBC, FCS_COP.1/AES-CMAC.
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.
SFRs: 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.
SFRs: FTP_ITC.1, FCS_CKM.1/SM, FCS_CKM.4, FCS_COP.1/AES-CBC, FCS_COP.1/AES-CMAC.
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 necessary cryptographic support for the secure communication.
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
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 88/101
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. FPT_IDA.1/X509 covers the authentication of the certificate of the software
publisher server. FDP_ETC.2, FDP_IFC.1 and FDP_IFF.1 define Information Flow Control Policy for
verifying the signature of the Upgrade Package sent by the Software Publisher. The authentication before
the upgrade is guaranteed 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, FPT_IDA.1/X509 FCS_COP.1/SHA-256, FCS_COP.1/AES-CBC,
FCS_COP.1/Sign_Ver ,FIA_UAU.2 and FIA_UID.2, FDP_IFC.1, FDP_IFF.1, FDP_ETC.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.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 89/101
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. Providing the real time for IVA data and audit data is fulfilled
by FPT_STM.1.
SFRs: FMT_MTD.1/Time, FMT_SMF.1, FMT_SMR.1, FIA_UAU.2 and FIA_UID.2 and FPT_STM.1.
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.
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.
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.
SFRs: FPT_TST.1 and FPT_FLS.1.
OT.Audit_Data_Protection: FAU_STG1, FAU_SAR.1 and FAU_STG.4 covers the audit data protection.
SFRs: FAU_STG1, FAU_SAR.1 and FAU_STG.4
OT.RIP [Residual Information Protection]: The SFR FDP_RIP.1 provides the protection aimed by
OT.RIP.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 90/101
SFRs: 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.Cert_Update: Validity of certificates needs to be checked by the TOE. This is covered by
FPT_SSY.1/Cert. During certificate update, the integrity and authenticity of the new certificates replacing
the old certificates are ensured. For this, FDP_ETC.2, FDP_IFC.1 and FDP_IFF.1 define Information Flow
Control Policy for verifying eID management CA signature.
SFRs: FPT_SSY.1/Cert, FDP_ETC.2, FDP_IFC.1 and FDP_IFF.1
6.4.2 SECURITY FUNCTIONAL REQUIREMENTS RATIONALE TABLES
The coverage of objectives by the SFRs are given in Table 14, Table 15 and Table 16.
Table 14 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.
Table 14 SFR Rationale Table for TOE on SSR Type I without Biometric Sensor and External PIN Pad
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 91/101
SFR s
OT.IVM_Management
OT.Security_Failure
OT.eIDC_Authentication
OT.PIN_Verification
OT.IVA_Signing
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_Protection
OT.RIP
OT.Auth_SAM_by_TOE
OT.Cert_Update
FAU_GEN.1 X X X X X X X X X
FAU_ARP.1 X
FAU_SAR.1 X
FAU_STG.1 X
FAU_STG.4 X
FAU_SAA.1 X
FCS_CKM.1/SM X X X X
FCS_CKM.1/SM_TL
S
FCS_CKM.1/IVA_Ke
ys
FCS_CKM.4 X X X X
FCS_COP.1/SHA-256 X X
FCS_COP.1/AES-
CBC
X X X X X
FCS_COP.1/AES
CMAC
X X X X
FCS_COP.1/RSA X
FCS_COP.1/
Sign_Ver
X X X X X
FIA_UID.2 X X X X X
FIA_UAU.2 X X X X X
FIA_UAU.5 X X X X X
FIA_UAU.7 X
FCO_NRO.2 X
FMT_MOF.1/Verify X
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 92/101
FMT_MOF.1/Upgrad
eManagement
X
FMT_MTD.1/SAM-
PIN
X
FMT_MTD.1/DTN X
FMT_MTD.1/Time X
FMT_SMF.1 X X X X X X
FMT_SMR.1 X X X X X X
FPT_STM.1 X
FPT_IDA.1/CVC X X
FPT_IDA.1/X509 X X X
FPT_IDA.1/IVP X
FPT_IDA.1/OCSP X
FPT_IDA.1/TOE_Up
grade
X
FPT_SSY.1/IVC X
FPT_SSY.1/SAM X
FPT_SSY.1/RH_Auth
_Status
X
FPT_TST.1 X
FDP_RIP.1 X
FPT_FLS.1 X X X
FTP_ITC.1 X X X
FPT_SSY.1/Cert X
FDP_ETC.2 X X X X
FDP_IFC.1 X X X X
FDP_IFF.1 X X X X
Table 15 gives the SFR Rational for additional objectives of TOE on SSR Type II.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 93/101
Table 15 .SFR Rationale for additional objectives of TOE on SSR Type II
OT.Photo_Verification
OT.SA_Identity_Verification
OT.Session_Ending
OT.SAS_DA
OT.SAS_SC
FAU_GEN.1 X X X X
FCS_CKM.1/SM_TLS X
FCS_COP.1/SHA-256 X
FCS_COP.1/AES-CBC X
FIA_UID.2 X X X
FIA_UAU.2 X X X
FIA_UAU.5 X X X
FIA_UAU.6 X
FTP_ITC.1 X
Table 16 gives the SFR Rational for additional objectives of TOE on SSR with biometric sensor and/or
external PIN PAD.
Table 16 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
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 94/101
FAU_GEN.1 X X X
FIA_AFL.1 X
FAU_UID.2 X X
FIA_UAU.2 X X
FIA_UAU.5 X X X
FIA_UAU.6 X
FIA_UAU.7 X
FCS_CKM.1/SM X X
FCS_CKM.4 X X
FCS_COP.1/AES-CBC X X
FCS_COP.1/AES-CMAC X X
FPT_SSY.1/IVC X X
FTP_ITC.1 X X
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, through 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.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 95/101
7. TOE Summary Specification
7.1 TOE Security Functions
7.1.1 Security Audit
Authenticated service requester and service attendee access the TOE via Secure Smart Card Reader.
Depends on the minimal audit level, the TOE generates event logs whose threshold is determined by TOE.
The TOE apply tampering of the SSR known to indicate a potential security violation. These logs include
date and time, ID (applicable), user ID, object ID, host ID and reliable time stamps. The TOE provides with
the capability to read from the audit records in a manner suitable for the user to interpret the information.
The administrator will have the capability to read from the audit records by using the admin password.
Auditable eventâ€™s identifier and outcome of the event information are stored with logs. The TOE provides
protected audit trail storage against unauthorized deletion. If the audit trail is full, the TOE overwrite the
oldest stored audit records. The TOEâ€™s security alarm mechanism notifies authorized user about security
hole, deletes cryptographic keys and enters offline mode.
Functional Requirement Satisfied: FAU_ARP.1, FAU_GEN.1, FAU_SAA.1, FAU_STG.1,
FAU_STG.4, FPT_STM.1, FAU_SAR.1
7.1.2 Cryptographic Support
The Cryptographic Support function provides encryption/decryption with AES-256 CBC Mode and CMAC
key generation algorithm (256 bits key size) for secure messaging between Identity Verification Assertion,
Secure Access Module, eID, External Biometric Sensor, External PINPAD, and Role Holder. Secure
messaging begins when eID Card is inserted into SSR Card Slot. Key generation, key distribution True
Random Number Generation is used for Identity Verification Assertion integrity and confidentiality. The
TOE generates cryptographic key with TLS v1.2 key generation algorithm 256 Bits key size for secure
messaging between Identity Verification Server, Application Server and SSR Access Server. Generated
keys are distributed and destructed by specified cryptographic support functions. The TSF destroys
cryptographic key with destruction method. Message authentication is provided by AES-CMAC 256 bits
cryptographic key size. RSA encryption operation is performed during the key agreement between the SAM
and the TOE.
SHA-256 algorithm is used for hash value calculation. The Cryptographic Support function supplies
Signature Verification for signature verification operations with RSA,PKCS#1 v2.1 with PSS padding
method in terms of Identity Verification Certificate, OCSP Answer signature, Signature of the Identity
Verification Policy sent by the IVPS, SAM certificate and upgrade package signature.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 96/101
Functional Requirement Satisfied: FCS_CKM.1/IVA_Keys, FCS_CKM.1/SM, FCS_CKM.1/SM_TLS,
FCS_CKM.4, FCS_COP.1/AES-CBC, FCS_COP.1/AES-CMAC, FCS_COP.1/RSA, FCS_COP.1/SHA-
256, FCS_COP.1/Sign_Ver
7.1.3 Identification and Authentication
The Identification and Authentication security function provides the controlled access to the TOE by service
requester and service attendee. The TOE ensures that a user identity established and verified before access
to the TOE is allowed. Prior the allowing access, the TOE requires users to be identified depending on
identity verification method. The TOE verifies that the Identity Verification Certificate,
IdentityVerification Policy Server Certificate, OCSP Server Certificate, Software Publisher Certificate
originates from Card Publisher and Device Manager using X509 Certificate Authentication Mechanism.
When 30 unsuccessful biometric authentication attempts has been met, service requester eID cards
biometric verification feature is restricted up to permission of it is provided again by Civil Data
Registration. The TOE provide multiple authentication mechanism. This mechanism includes Service
Attendee, Service Requester, eID Card, SAM, Role Holder Device, and SAS for TOE on SSR Type II,
external PIN Pad and external biometric sensor authentications. Service requester and service attendee
authentication has special rules. The Identification and Authentication security function provides re-
authentication under the specified conditions. Service Requester, Service Attendee is re-authenticated even
if the card is not removed. After 24 hours are exceeded, SAM authentication, Role Holder Device
Authentication, APS authentication, SAS authentication, external PIN Pad and biometric sensor
authentication keys are renewed. During the authentication, the TOE provides dummy character for each
entered PIN entry and fingerprint representation.
Functional Requirement Satisfied: FIA_AFL.1, FUA_UAU.2, FIA_UAU.5, FIA_UAU.6, FIA_UAU.7,
FIA_UID.2, FPT_IDA.1/X509.
7.1.4 Communication
The Communication security function provides the generation of evidence of origin for transmitted Identity
Verification Assertion Data at all times. Evidence is the signature of the SAM. Identity Verification
Assertion Data is signed by SAM Signature Certificate before sending the Identity Verification Server for
verification. IVA is verified by IVS. SSR Type I and II send IVA to SPCA and SPCA forwards the IVA to
APS. The Identity of the originator of the information, and the Identity Verification Assertion Data of the
information to which evidence applies. The Communication Security functions supply a competence to
verify the evidence of origin of information to Identity Verification Server given immediately in online
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 97/101
mode. The TOE requires each user to be successfully identified before allowing any other TOE-mediated
actions on behalf of that user.
Functional Requirement Satisfied: FCO_NRO.2 , FIA_UID.2
7.1.5 Security Management
The Security Management function provides roles for users and associates such roles with users.
Initialization Agent, SSR Access Server for TOE on SSR Type II, Client Application for TOE on Type I
and Type II, Identity Verification Policy Server, OCSP Server, Manufacturer service operator and Software
Publisher roles are provided by the TOE. According the roles, the function restricts the ability to determine
the behavior of the specified function Identity Verification Operation to the Identity Verification Policy
Server or Client Application. The Security Management function allows only for the higher versions and
SAM associated upgrade packages. The TOE provides SAM-PIN, Device Tracking Number management
and restricts the access of them. SAM-PIN and Device Tracking Number written only in initialization
Agent. OCSP Server has ability to update the TOE time. TOE gets the time information from OCSP Server
and stores in RTC. The TOE affords management for security related functions in terms of TOE
initialization, TOE upgrade, time and date setting, audit generation, and identity verification method
determination.
Functional Requirement Satisfied: FMT_MOF.1/Upgrade, FMT_MOF.1/Verify, FMT_MTD.1/DTN,
FMT_MTD.1/SAM-PIN, FMT_SMF.1, FMT_SMR.1, FMT_MTD.1/Time
7.1.6 Protection of the TSF
The TOE provides security mechanisms for protection of the TSF. The TOE supply reliable time stamps
from OCSP Server and stores in a real time clock on SSR. For imported TSF data authentication, origins
of Card Verifiable Certificates, Identity Verification Policy, OCSP, TOE upgrade packages are verified by
the TOE. For state synchronization, validity of Secure Messaging and Role CVC, SAM Card Certificate
Revocation Status, Identity Verification Certificate revocation status and Role Holder authentication status
in eID card are checked by the TOE. The TOE verifies that the Secure Messaging Card Verifiable
Certificates and Role Card Verifiable Certificates originates from Card Publisher using CVC
Authentication Mechanism.
The TOE runs a suite of self-test during initial start-up to demonstrate the correct operation of the TSF.
Secure state protection is provided by the TOE when tempered event occurs and authentication services for
SAM are disturbed.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 98/101
Functional Requirement Satisfied: FPT_FLS.1, FPT_IDA.1/CVC, FPT_IDA.1/IVP,
FPT_IDA.1/OCSP,FPT_IDA.1/TOE_Upgrade,FPT_SSY.1/IVC,FPT_SSY.1/RH_Auth_Status,FPT_SSY.
1/SAM, FPT_STM.1, FPT_TST.1, FPT_SSY.1/Cert
7.1.7 User Data Protection
Identity Verification Assertion is generated by GEM as a result of identification and authentication
operation.Information flow control policy is provided by the TOE on SPCA, SAS, APS, OCSP Server for
TOE Upgrade Package, IVA, IVM, OCSP Response, SAM Secure Messaging CVC and SAM Role CVC
write and read operations. The TOE permit an information flow between a controlled subject and controlled
information via a controlled operation if the IVA is sent only if communication channel with corresponding
SPCA, SAS or APS is established and other information under the control of Information Flow Control
Policy are accepted and written if signature verification is completed successfully. Information Flow
Control Policy is applied when importing and exporting user data, controlled under the SFP, from outside
of the TOE. Security attributes associated with the user data is ignored when imported from outside of the
TOE. The TOE exports the user data with the user dataâ€™s associated security attributes. The TOE ensures
that the security attributes, when exported outside the TOE, are unambiguously associated with the exported
user data. Previous information content of a resource is made unavailable upon the deallocation of the
resource from the cryptographic credentials, IVA data fields, PIN, photo and biometric information.
Functional Requirement Satisfied: FDP_ETC.2, FDP_IFC.1, FDP_IFF.1, FDP_RIP.1
7.1.8 Trusted Path/Channels
The TOE provides a communication channel between itself and each one of the following trusted products:
Role Holder Device, External Biometric Sensor, External PIN PAD, eID Card, SSR SAM, SAS for TOE
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. Initiate communication via
the trusted channel is permitted by the TSF for all functions. Hardware Security Module is used for
safeguards and manages certificates. SSL-TLS certificates is used for founding trusted paths with SSR
Access Server and Application Server.
Functional Requirement Satisfied: FTP_ITC.1
8. Acronyms
Table 17. Acronyms
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 99/101
Abbreviation Explanation
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
eID Card Electronic Identity Card of National Republic
eIDVS Electronic Identity Verification System
eSign Electronic Signature
KEC Kart EriÅŸim CihazÄ±
IV Identity Verification
IVA Identity Verification Assertion
IVC Identity Verification Certificate
IVP 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 Secure Smart Card Reader
TA Terminal Authentication
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 100/101
9. 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
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.
Security Target
SSR_Core v1.0
Version:
Lite
UDEA Electronics. Page 101/101
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