NCR e10 New Generation FCR Application
Security Target -Lite
Document Attributes
File name: Security Target-Lite NCR e10.pdf
Status: Published
Release Date: 29.04.2015
Version: 1.0
Sensitivity: Public
Author: Saadet Gökçe Ekiz
Approved by Okan Tunçer
Revision Table
Revision
No
Revision Date Explanation Made by
1.0 29.04.2015 First ST Lite Release created by using last
version of ST
Funda Çetintaş
Table of Contents
Revision Table .........................................................................................................................................2
Table of Contents....................................................................................................................................3
1. INTRODUCTION...............................................................................................................................6
1.1. ST Reference ...........................................................................................................................6
1.2. TOE Reference.........................................................................................................................6
1.3. TOE Overview..........................................................................................................................6
1.3.1. General overview of the TOE and related components .................................................6
1.3.2. Required Non-TOE Hardware/Software .........................................................................7
1.3.3. TOE major security features for operational use............................................................9
1.3.4. TOE Type .......................................................................................................................10
1.3.5. Non-TOE hardware/software/firmware .......................................................................10
1.4. TOE Description.....................................................................................................................11
1.4.1. TOE Boundaries.............................................................................................................11
1.4.2. TOE Guidance Documents ............................................................................................12
2. CONFORMANCE CLAIMS...............................................................................................................12
2.1. CC Conformance Claims........................................................................................................12
2.2. PP Conformance Claims........................................................................................................12
2.3. Package Claim .......................................................................................................................12
2.4. Conformance Rationale ........................................................................................................12
3. SECURITY PROBLEM DEFINITION ..................................................................................................14
3.1. Introduction ..........................................................................................................................14
3.1.1. External Entities ............................................................................................................14
3.1.2. Roles..............................................................................................................................15
3.1.3. Modes of FCR................................................................................................................15
3.1.4. Assets ............................................................................................................................16
3.2. Threats ..................................................................................................................................17
3.3. Organizational Security Policies............................................................................................19
3.4. Assumptions..........................................................................................................................20
4. SECURITY OBJECTIVES...................................................................................................................21
4.1. Security Objectives for the TOE ............................................................................................21
4.2. Security Objectives for the Operational Environment..........................................................21
4.3. Security Objective Rationale.................................................................................................23
5. EXTENDED COMPONENTS DEFINITION.........................................................................................27
6. SECURITY REQUIREMENTS............................................................................................................27
6.1. Security Functional Requirements for the TOE.....................................................................27
6.1.1. Class FAU Security Audit ...............................................................................................27
6.1.2. Class FCO Communication ............................................................................................28
6.1.3. Class FCS Cryptographic Support ..................................................................................29
6.1.4. Class FDP User Data Protection ....................................................................................32
6.1.5. Class FIA Identification and Authentication..................................................................37
6.1.6. Class FMT Security Management..................................................................................38
6.1.7. Class FPT Protection of the TS.......................................................................................42
6.1.8. Class FTP Trusted Patch/Channels ................................................................................44
6.2. Security Assurance Requirements for the TOE.....................................................................45
6.3. Security Requirements Rationale..........................................................................................45
6.3.1. Security Functional Requirements Rationale................................................................45
6.3.2. Rationale for SFR’s Dependencies ................................................................................54
6.3.3. Security Assurance Requirements Rationale................................................................58
6.3.4. Security Requirements – Internal Consistency.............................................................58
7. TOE SUMMARY SPECIFICATION ....................................................................................................60
7.1. TOE Security Functions .........................................................................................................60
7.2. Assurance Measure...............................................................................................................61
7.3. TOE Summary Specification Rational....................................................................................61
7.3.1. Security Functions Rational...........................................................................................61
7.3.2. Assurance Measures Rational.......................................................................................63
8. ACRONYMS ...................................................................................................................................65
9. BIBLIOGRAPHY ..............................................................................................................................67
LIST OF FIGURES
Figure 1 TOE and related components ...................................................................................................7
Figure 2 Fiscal Cash Register Component Diagram ..............................................................................11
LIST OF TABLES
Table 1 Typical Software Environment of the TOE .................................................................................7
Table 2 Security Objective Rationale ....................................................................................................24
Table 3 Coverage of security objectives by SFRs for TOE .....................................................................45
Table 4 Suitability of the SFRs...............................................................................................................49
Table 5 Security Functional Requirements dependencies....................................................................54
Table 6 Security Functions Rationale....................................................................................................61
1. INTRODUCTION
1.1. ST Reference
ST Title NCR E10 New Generation FCR Application Security Target Lite
ST Reference NCRE10-ST-Lite v1.0
CC Version Common Criteria for Information Technology Security Evaluation,
Version 3.1 (revision 4)
Version Number 1.0
Status Released
1.2. TOE Reference
TOE Identification NCR E10 New Generation FCR Application Software Version 1.0
CC Conformance Common Criteria for Information Technology Security Evaluation,
Version 3.1 (revision 4)
PP Conformance COMMON CRITERIA PROTECTION PROFILE for NEW GENERATION CASH
REGISTER FISCAL APPLICATION SOFTWARE (NGCRFAS PP), TSE-
CCCS/PP-006 version 1.8, 18 December 2014
Assurance Level Evaluation Assurance Level 2
1.3. TOE Overview
The TOE addressed by this Security Target (ST) is an application software which is the main items of
a Fiscal Cash Register (FCR). TOE is used to process the transaction amount of purchases which can
be viewed by both seller and buyer. Since transaction amount is used to determine tax revenues;
secure processing, storing and transmission of this data is very important.
The FCR is mandatory for first-and second-class traders and is not mandatory for sellers who sell the
goods back to their previous seller as completely the same as the purchased good.
In addition to TOE, which is the main item of FCR, FCR may consist of several other hardware and
software components as described in Section 1.3.2 for full functionality. TOE and related components
are given in Figure 1. Usage and major security features of TOE are described in section 1.3.3.
1.3.1. General overview of the TOE and related components
Figure 1 shows the general overview of the TOE and its related components as regarded in this ST.
The green part of Figure 1 is the TOE. Yellow parts given as Input/output interface, fiscal memory,
daily memory, database, ERU, fiscal certificate memory are non-TOE environments which are crucial
parts of the FCR for functionality and security. Connections between the TOE and its environment
are also subject to evaluation since these connections are made over the interfaces of the TOE.
Figure 1 TOE and related components
1.3.2. Required Non-TOE Hardware/Software
Software, hardware environment of the TOE are described below.
1.3.2.1. Software environment of TOE
TOE runs on an operating system. Operating system’s kernel and its file-system as in a typical software
environment. This structure is shown in Table 1.
Table 1 Typical Software Environment of the TOE
File System
Operating System Kernel
In addition to TOE, following software components are necessary for security and functionality of the
FCR:
 Application runs on an operating system which supports following features
Cash Register
TOE
Input/Output
Interface
Fiscal
Memory
Daily
Memory
Fiscal Certificate
Memory
Electronic
Recording
Unit
Database
Operating
System
Secure TOE Environment
Necessary of functional and/or security reasons
TOE
o at least 32-bit data processing capacity
o multi-processing
o IPv4 and IPv6
o NTP (Network Time Protocol)
 Database which is used to store sales data, has the following features;
I. Database has data recording, organizing, querying, reporting features
II. Database stores sales records for main product groups (food, clothing, electronics,
glassware etc.) and sub-product groups (milk, cigarette, fruit, trousers etc.) in order
to track detailed statistics
III. Database has indexing mechanism
1.3.2.2. Hardware Environment of TOE
In addition to TOE, following hardware components are necessary for security and functionality of the
FCR:
 Fiscal memory
i. Fiscal memory has following features;
a. Fiscal memory has the capacity to store at least 10 years (3650 days) of data,
b. Fiscal memory keeps data at least 5 years after the capacity specified in (a) has been
reached,
c. Fiscal memory has to be fixed within FCR in a way that it cannot be removed without
damaging the chassis.
d. Fiscal memory is protected by mesh cover,
e. Fiscal memory has the ability to be protected against magnetic and electronic threats,
1 When the connection between fiscal memory and main processor is broken, FCR enters
in maintenance mode,
f. The data stored in the fiscal memory is not be lost in case of power off,
g. Fiscal memory accepts only positive amounts from the application and the peripherals,
h. FCR checks "Z" reports from fiscal memory during device start-up. In case where there
are days for which Z report was not generated, FCR will be able to run in normal mode
only after it generates Z reports for the missing days. Seasonal firms can take cumulative
Z report by specifying date and time range.
ii. Fiscal Memory includes following data;
a. Fiscal symbol, company code, identification number of the device,
b. Cumulative sum of the total sales amount and Value Added Tax (VAT) amounts of all sales
receipts, starting from the device activation (i.e. first use),
c. Date and number of daily "Z" reports with total sales and VAT per day,
d. The number of receipts per day.
 Daily memory has following features;
i. Receipt total and total VAT amount for each receipt are to be stored in the daily memory
instantly. This data can be transmitted to PRA information systems (PRA - IS), instantly or
daily depending on demand.
ii. Data in the daily memory which is not already transmitted to fiscal memory, cannot be
modified in an uncontrolled way.
iii. Data transmitted from daily memory to fiscal memory is to be kept in daily memory for at
least 10 days.
iv. Z reports, taken at the end of the day; and X reports, taken within the current day are
produced by using the data in the daily memory.
v. Following values are stored in the daily memory
a. total VAT amount per day,
b. total daily sales values per day grouped by payment type
c. payment type (Cash, credit card etc.)
d. number of receipts.
 FCR supports X.509 formatted digital certificate generated by Authorized Certificate
Authority. This Public Key Infrastructure (PKI) compatible digital certificate is called fiscal
certificate and is used for authentication and secure communication between PRA-IS and FCR
through Trusted Service Manager (TSM). For physical security, FCR is protected by electronic
and mechanic systems called electronic seal. FCR uses cryptographic library for secure
communication with PRA-IS and TSM
 Electronic Record Unit(ERU) is used to keep second copy of the receipt and has following
features;
i. ERU stores information about receipts and reports (X, Z) in a retrievable form.
ii. ERU is included in the sealed part of the FCR. ERU has 140 million row capacity.
iii. Data stored in ERU cannot be modified
iv. ERU also has features specified in “Fiscal Cash Register General Communique Serial Number:
67” part A which is about Law No: 3100 except item (ii) above.
 FCR device has ETHERNET interface for communication with PRA-IS (for data transfer) and
TSM system (for parameter management and software update). External ETHERNET may be
accepted as internal in case the data is encrypted in fiscal unit.
 Incoming and outgoing data traffic for FCR passes over a firewall.
 FCR has a printer to print sales receipt.
 FCR supports the use of EFTPOS.
 FCR needs some input/output devices for functionalities listed below;
i. FCR has money drawer for keeping cash
ii. FCR has internal battery to keep time information, to protect event data and fiscal memory.
iii. FCR has detached PC for running POS application.
a. Separate displays for cashier and buyer are connected to PC POS Application.
b. If used in PC POS application; keyboard, scale unit and barcode reader are connected
to PC POS application.
1.3.3. TOE major security features for operational use
The functional and major security features of the TOE are described below.
1.3.3.1. TOE functional features
The TOE is a part of a FCR which is an electronic device for calculating and recording sales transactions
and for printing receipts. TOE provides the following services;
i. TOE stores sales data in fiscal memory.
ii. TOE stores total receipt and total VAT amount for each receipt in daily memory.
iii. TOE is able to generate reports (X report, Z report etc.).
iv. TOE is able to transmit Z reports, receipt information, sale statistics and other information
determined by PRA to PRA-IS in PRA Messaging Protocol format.
v. TOE is able to start the communication with PRA-IS and instantly respond to requests
originated from PRA-IS.
vi. TOE stores records of important events as stated in PRA Messaging Protocol Document [6]
and transmits to PRA-IS in PRA Messaging Protocol format in a secure way.
vii. TOE is able to be used by users in secure state mode or maintenance mode. Roles and modes
of operation are described in 3.1.2 and 3.1.3 respectively.
1.3.3.2. TOE major security features
The TOE provides following security features;
i. TOE supports access control.
ii. For the cases where the main processor and the fiscal memory are included within the same
electronic seal secure communication is not mandatory. TOE is able to detect disconnection
between main processor and fiscal memory and enter into the maintenance mode.
iii. TOE supports usage of ITU X509 v3 formatted certificate and its protected private key for
authentication and secure communication with PRA- IS and TSM.
iv. TOE supports secure communication between FCR-PRA-IS and FCR–TSM.
v. TOE ensures the integrity of event data, sales data, authentication data, characterization data
and FCR parameters.
vi. TOE records important events defined in PRA Messaging Protocol Document [6] and send
urgent event data immediately to PRA-IS in a secure way.
vii. TOE detects physical attacks to FCR and enters into the maintenance mode in such cases.
1.3.4. TOE Type
TOE is a set of software application embedded within FCR.
1.3.5. Non-TOE hardware/software/firmware
Fiscal Cash Register Component diagram is given in Figure 2 and printer is contains TOE and necessary
environment for operating TOE. Other EFT POS Device, Keyboard, Main unit, Cashier display, Scale,
Customer display and barcode reader are although parts of Fiscal Cash register, they are not part of
Target of evaluation.
Figure 2 Fiscal Cash Register Component Diagram
1.4. TOE Description
The target of evaluation (TOE) is the NCR E10 New Generation FCR Application software version 1.0 as
developed by Encore Bilişim Sistemleri Limited Şirketi.
1.4.1. TOE Boundaries
1.4.1.1. TOE Physical Boundaries
TOE is implemented in Printer shown in Figure 2 in a plastic case protected by tampering switches.
TOE is a firmware and stored in a non-volatile memory.
1.4.1.2. TOE Logical Boundaries
The logical boundaries of the TOE include those security functions implemented exclusively by the
TOE. These security functions includes accurate fiscal operation, generation security related and fiscal
log information and storing in dedicated memories (daily memory, fiscal memory and Electronic
Recording Unit), access control for sales data, event data, time information and authentication data,
authentication for FCR Authorised User, Authorised Manufacturer User, communication security
function (Secure Transfer) with TSM, PRA-IS, EFT-POS Device and Main Unit A more detailed
description of the implementation of these security functions is provided in Section 7 “TOE SUMMARY
SPECIFICATION”
1.4.2. TOE Guidance Documents
The TOE guidance documents (NCR e10 Kullanıcı Kılavuzu and NCR e10 Kurulum Prosedürü) are
delivered as evidence of CC evaluation.
2. CONFORMANCE CLAIMS
2.1. CC Conformance Claims
This protection profile claims conformance to:
- Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and
General Model; CCMB-2012-09-001, Version 3.1, Revision 4, September 2012 [1]
- Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional
Components; CCMB-2012-09-002, Version 3.1, Revision 4, September 2012 [2]
- Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance
Requirements; CCMB-2012-09-003, Version 3.1, Revision 4, September 2012 [3]
As follows
- Part 2 conformant,
- Part 3 conformant.
The
- Common Methodology for Information Technology Security Evaluation, Evaluation
Methodology; CCMB-2012-09-004, Version 3.1, Revision 4, September 2012 [4]
has to be taken into account.
2.2. PP Conformance Claims
This security target claims demonstrable conformance to the protection profile “Common criteria
protection profile for new generation cash register fiscal application software (NGCRFAS PP), TSE-
CCCS/PP-006, version 1.8, 18 December 2014.
2.3. Package Claim
The current Security Target is conformant to the following security requirements package:
- Assurance package EAL2 conformant to CC, part 3.
2.4. Conformance Rationale
Since this security target (ST) claims demonstrable conformance with the protection profile (PP) TSE-
CCCS/PP-006 referenced in 2.2 PP Conformance Claims. TOE type is a set of software application run
by microprocessor depicted in Figure 1 and it is consistent with the TOE type explained in PP document
in chapter 1.2.4 and depicted in Figure 1 in PP document.
Security problem definition and security objectives contained in this ST are consistent with those in
the PP.
3. SECURITY PROBLEM DEFINITION
3.1. Introduction
3.1.1. External Entities
PRA-IS
PRA-IS takes sales data and event data from FCR by sending query with parameters to FCR through
TSM.
Trusted Service Manager
TSM is the system which is used to load parameters, update software and manage FCR.
Attacker
Attacker tries to manipulate the TOE in order to change its expected behaviour and functionality.
Attacker tries to breach confidentiality, integrity and availability on the FCR.
PRA On-site Auditor
PRA On-site Auditor is an employee of PRA who performs audits onsite to control the existence of
expected FCR functionalities by using the rights of FCR Authorised User.
Certificate storage
The certificate storage holds certificates and private key used for authentication and secure
communication. Certificate storage is protected inside physical and logical tampering system.
Time Information
FCR gets time information from trusted server. Time information is used during receipt, event, fiscal
memory record, daily memory record and ERU record creation and is also used to send information
to PRA-IS according to FCR Parameters.
Audit storage
Audit storage can be any appropriate memory unit in FCR. Audit storage stores important events
according to their critical level (urgent, high, warning, information). List of events can be found in PRA
messaging protocol document [6].
Storage unit
Storage units of FCR are database, fiscal memory, daily memory and ERU.
Input interface
Input interfaces provide necessary input data from input devices to the TOE. Input devices for FCR
may be keyboard, barcode reader, QR code (matrix barcode) reader, order tracking device or global
positioning devices.
External Device
 External device is the device which is used to communicate with FCR by using secure channel
according to External Device Communication Protocol Document [8]
Main Unit
Main Unit is an external device which is used for doing following actions;
 Provides visual interface for fiscal transaction,
 Provides input interface for fiscal transaction,
 Provides secure communication with TOE according to External Device Communication
Protocol Document [8]
Output interface
Output interfaces deliver outputs of the TOE to the output devices. Output devices for FCR may be
printer, display etc.
3.1.2. Roles
FCR Authorised User
FCR authorised user is the user who uses the functions of FCR and operates FCR by using
authentication mechanism.
Authorised Manufacturer User
Authorised Manufacturer User works for FCR manufacturer and conducts maintenance works on FCR.
3.1.3. Modes of FCR
Secure State Mode: Secure State Mode is the mode that allow
 FCR Authorised User;
o to configure FCR,
o to take fiscal and FCR reports
Maintenance Mode
Maintenance Mode is the mode that allow only Authorised Manufacturer User to fix FCR in case of
any technical problem, to change time information and to review event data. FCR does not allow any
fiscal transaction in maintenance mode. FCR enters this mode when the following occur;
- FCR Certificate check fails,
- Mesh cover monitoring check fails,
- A disconnection between fiscal memory and main processor occurs,
- Electronic seal is opened, or forced by unauthorised persons
- NCR E10 Application integrity error occurs,
- Event log data and sales data integrity error occurs,
- The state of unable to write to fiscal memory, daily memory and ERU
- First initialisation phase successfully passed
Maintenance mode is the mode that allows
 Authorised Manufacturer User;
o To fix the FCR software and hardware problems
o To update NCR E10 Application
o To change FCR Authorised User credentials to default values
3.1.4. Assets
Sensitive data
Sensitive data is used for secure communication with PRA-IS and TSM. Confidentiality and integrity of
this asset needs to be protected.
Event data
Event data is used to obtain information about important events contained in audit storage. The
integrity of this asset is crucial while stored in FCR and both integrity and confidentiality of this asset
are important while it is transferred from TOE to PRA-IS. Event data is categorized in PRA Messaging
Protocol Document [6].
Sales data
Sales data is stored in storage unit. Sales data is required for PRA-IS to calculate tax amount and to
provide detailed statistics about sales. The integrity of this asset has to be protected while stored in
FCR; and both integrity and confidentiality have to be protected while it is transferred from TOE to
PRA-IS.
Characterization data (Identification data for devices)
Characterization data is a unique number assigned to each FCR given by the manufacturer. PRA-IS uses
characterization data for system calls to acquire sales data or event data of an FCR. Integrity of this
asset has to be protected.
Authentication data
Authentication data contains authentication information which is required for FCR Authorised Users
and Authorised Manufacturer User to gain access to FCR functionalities. Both integrity and
confidentiality of this asset has to be protected.
Application Note 1: TOE does not use Authentication Data (password) to authenticate Authorised
Manufacturer User. A challenge-response application is implemented in TOE and a secondary system
which is run in manufacturer premises is used to create a response to authenticate authorised
manufacturer user.
Time Information
Time information is stored in FCR and synchronized with trusted server. Time information is important
when logging important events and sending reports to the PRA-IS. The integrity of this asset has to be
protected.
FCR Parameters
FCR parameters stored in FCR are updated by TSM after Z report is printed.
FCR parameters set;
 Sales and event data transferring time
 Critical level of event data sent to the PRA-IS
 Maximum number of days that FCR will work without communicating with PRA-IS
3.2. Threats
Threats averted by TOE and its environment are described in this section. Threats described below
results from assets which are protected or stored by TOE or from usage of TOE with its environment.
T.AccessControl
Adverse action: Authenticated users could try to use functions which are not allowed. (e.g. FCR Users
gaining access to FCR Authorised User management functions)
Threat agent: An attacker who has basic attack potential and has logical access to FCR.
Asset: Event data, sales data, time information.
T. Authentication
Adverse action: Unauthorized users could try to use FCR functions.
Threat agent: An attacker who has basic attack potential, has logical and physical access to the FCR.
Asset: Sales data, event data, time information.
T.MDData - Manipulation and disclosure of data
Adverse action: This threat deals with four types of data: event data, sales data, characterization data
and FCR parameters.
- An attacker could try to manipulate the event data to hide its actions and unauthorised access
to the FCR, failure reports, and deletion of logs. An attacker also could try to disclose
important events while transmitted between PRA-IS and FCR.
- An attacker could try to manipulate or delete the sales data generated by TOE which may
result in tax fraud. In addition, an attacker also could try to disclose sales data while
transmitted between PRA-IS and FCR. Manipulation and deletion of sales data may be caused
by magnetic and electronic reasons.
- An attacker could try to manipulate the characterization data to cover information about
tax fraud; to masquerade the user identity.
- An attacker could try to manipulate the FCR parameters to use FCR in undesired condition.
Threat agent: An attacker who has basic attack potential, has physical and logical access to the FCR.
Asset: Event data, sales data, characterization data, FCR parameters.
T.Eavesdrop - Eavesdropping on event data, sales data and characterization data
Adverse action: An attacker could try to eavesdrop event data, sales data and characterization data
transmitted between the TOE and the PRA-IS and also between the TOE and the distributed memory
units (Fiscal memory, Database, Daily memory, ERU).
Threat agent: An attacker who has basic attack potential, has physical access to the FCR and physical
access to the FCR communication channel.
Asset: Characterization data, sales data, and event data.
T.Skimming - Skimming the event data, sales data and characterization data
Adverse action: An attacker could try to imitate PRA-IS to receive information from FCR and to imitate
TSM to set parameters to FCR via the communication channel.
Threat agent: An attacker who has basic attack potential and logical access to the
FCR.
Asset: Sales data, event data and FCR parameters.
T.Counterfeit - FCR counterfeiting
Adverse action: An attacker could try to imitate FCR by using sensitive (session keys) data while
communicating with PRA-IS and TSM to cover information about tax fraud.
Threat agent: An attacker who has basic attack potential and has physical and logical access to the
FCR.
Asset: Sensitive data (session keys).
T.Malfunction - Cause malfunction in FCR
Adverse action: An attacker may try to use FCR out of its normal operational conditions to cause
malfunction without the knowledge of TOE.
Threat agent: An attacker who has basic attack potential, has physical access to the FCR.
Asset: Sales data, event data.
T.ChangingTime
Adverse action: An attacker may try to change time to invalidate the information about logged events
and reports in FCR.
Threat agent: An attacker who has basic attack potential, has physical and logical access to the FCR.
Asset: Time Information.
3.3. Organizational Security Policies
This section describes organizational security policies that must be satisfied.
P.Certificate
It has to be assured that certificate which is installed at initialization step is compatible with ITU X.509
v3 format. FCR contains FCR certificate, Certification Authority root certificate, Certification Authority
sub-root (subordinate) certificate and UpdateControl certificate is used to verify the signature of the
TOE.
P.Comm_EXT - Communication between TOE and External Device
It has to be assured that communication between TOE and external devices is used to encrypt using
AES algorithm with 256 bits according to External Device Communication Protocol Document [8]
P.InformationLeakage - Information leakage from FCR
It has to be assured that TOE’s environment provides a secure mechanism which prevents attacker to
obtain sensitive information (secret key) when FCR performs encryption operation; i.e by side channel
attacks like SPA (Simple power analysis), SEMA (Simple Electromagnetic Analysis), DPA (Differential
power analysis), DEMA (Differential electromagnetic analysis).
P.SecureEnvironment
It has to be assured that environment of TOE senses disconnection between fiscal memory and main
processor. Then TOE enters into the maintenance mode and logs urgent event. Moreover, it has to be
assured that fiscal memory doesn't accept transactions with negative amounts which results in a
decrease of total tax value. Also it has to be assured that environment of TOE provides a mechanism
that sales data in daily memory which is not reflected to the fiscal memory cannot be deleted and
modified in an uncontrolled way. In addition to this, it has to be assured that sales data in ERU cannot
be deleted and modified.
P.PhysicalTamper
It has to be assured that TOE environment and TOE provide a tamper respondent system which is
formed by electromechanical seals. It has to be assured that physical tampering protection system
protects the keys (asymmetric key, symmetric key), the certificates, event data, characterization data,
FCR parameters and sales data. It has to be assured that TOE logs this type of events and enters into
the maintenance mode when physical tampering protection system detect unauthorised access. On
the other hand it has to be assured that authorised access such as maintenance work or service works
are logged. It has to be assured that physical tampering protection system (mesh cover) protects fiscal
memory.
P.PKI - Public key infrastructure
It has to be assured that IT environment for the TOE provides public key infrastructure for encryption,
signing and key agreement.
P.UpdateControl
TOE is allowed to be updated by TSM or Authorised Manufacturer User to avoid possible threats
during this operation, FCR shall verify the signature of the new version of TOE to ensure that the TOE
to be updated is signed by the correct organisation. Thus, the TOE to be updated is ensured to be the
correct certified version because only the certified versions will be signed. In addition, FCR shall check
version of TOE to ensure that it is in latest version.
3.4. Assumptions
This section describes assumptions that must be satisfied by the TOE's operational environment.
A.TrustedManufacturer
It is assumed that manufacturing is done by trusted manufacturers. They process manufacturing step
in a manner which maintains IT security.
A.Control
It is assumed that PRA-IS personnel performs random controls on FCR. During control PRA-IS should
check if tax amount, total amount printed on receipt and sent to PRA-IS is the same. In addition to
this, a similar check should be processed for events as well.
A.Initialisation
It is assumed that environment of TOE provides secure initialization steps. Initialization step consists
of secure boot of operating systems, and integrity check for TSF data. Moreover, it is assumed that
environment of TOE provides secure installation of certificate to the FCR in initialization phase. Before
certificate installation it is assumed that asymmetric key pair generated in a manner which maintains
security posture.
A.TrustedUser
User is assumed to be trusted. It is assumed that for each sale a sales receipt is provided to the buyer.
A.Activation
It is assumed that environment of TOE provides secure activation steps at the beginning of the TOE
operation phase and after each maintenance process.
A.AuthorisedService
It is assumed that repairing is done by trusted authorised services. The repairing step is processed in
a manner which maintains legal limits.
A.Ext_Key
It is assumed that External Device (EFT-POS, Main Unit) generates strong key for communicating with
TOE.
4. SECURITY OBJECTIVES
This chapter describes security objectives for the TOE and its operational environment.
4.1. Security Objectives for the TOE
This part describes security objectives provided by the TOE.
O.AccessControl
TOE must control authenticated user’s access to functions and data by using authorization
mechanism.
O.Event
TOE must record important events stated as in PRA Messaging Protocol Document [6].
O.Integrity
TOE must provide integrity for sales data and event data, characterization data, authentication data,
sensitive data (session keys) and FCR parameters.
O.Authentication
TOE must run authentication mechanism for users and systems.
O.Function
TOE must ensure that processing of inputs to derive sales data and event data is accurate.
TOE must ensure that time information is accurate by doing anomaly detection.
TOE must enter a maintenance mode when maintenance mode events occur in section 3.1.3
O.Transfer
TOE must provide confidentiality, integrity and authenticity for sales data, event data, characterization
data transferred to the PRA-IS and FCR parameters transferred from TSM. TOE also provide integrity
for sales data and event data transferred from memories to other memories. TOE must provide
confidentiality, integrity and authenticity for information send/received during external device
communication.
4.2. Security Objectives for the Operational Environment
This part describes security objectives provided by the operational environment.
OE.Manufacturing
Manufacturer should ensure that FCR is protected against physical attacks during manufacturing.
OE.Delivery
Authorised Manufacturer User must ensure that delivery and activation of the TOE done by a secure
way.
OE.KeyGeneration
Asymmetric key generation mechanism shall be accessible only by trusted persons.
OE.SecureStorage
Asymmetric private key shall be stored within smartcard or Secure-IC’s.
Keys (asymmetric key, symmetric key), certificates, event data, characterization data and sales data
shall be stored within secure environment protected by electronic seal.
OE.KeyTransportation
Transportation and installation of asymmetric key private and certificates to the FCR must be done by
protecting its confidentiality and integrity.
OE.TestEnvironment
Before FCR activation; test interfaces (functions, parameters) inserted in TOE should be disabled or
removed.
OE.StrongAlgorithm
Environment of TOE shall use asymmetric private keys for signature operation by using libraries of
smartcard and Secure-IC’s. These libraries used in FCR shall be strong. Also they should have
protection against side channel analysis (SPA, DPA, SEMA, DEMA, DFA).
OE.UpgradeSoftware
FCR software Updates should be get pass verdict from Common Criteria maintenance or reevaluation
procedures (according to update type) before installed to the FCR. This will be validated by the FCR,
using the cryptographic signature control methods.
OE.TrustedUser
Users shall act responsibly.
OE.Control
PRA Onsite Auditor must check FCR functionality by controlling tax amount on the receipt and tax
amount sent to the PRA-IS.
OE.External Device
External Device should generate strong key for communicating with TOE.
OE.SecureEnvironment
Fiscal memory shall not accept transactions with negative amounts which results in a decrease of total
tax value.
Tampering protection system shall protect fiscal memory with mesh cover.
Environment of TOE provides secure initialization steps. Initialization step is consist of secure boot of
operating system, and integrity check for TSF data.
4.3. Security Objective Rationale
Table 2 provides security problem definition covered by security objectives. Threats and OSPs are
addressed by security objectives for the TOE and its operational environment. Assumptions are
addressed by only security objectives for the operational environment.
Table 2 Security Objective Rationale
Threats OSPs Assumptions
T.AccessControl
T.
Authentication
T.MDData
T.Eavesdropping
T.Skimming
T.Counterfeit
T.Malfunction
T.ChangingTime
P.Certificate
P.SecureEnvironment
P.PhysicalTamper
P.PKI
P.InformationLeakage
P.Comm_EXT
P.UpdateControl
A.Ext_Key
A.TrustedManufacturer
A.Control
A.
AuthorisedService
A.Initialisation
A.Activation
A.TrustedUser
O.AccessControl X X X
O.Event X X X X X X X X X
O.Integrity X X X X X
O.Authentication X X X X
O.Function X X X
O.Transfer X X X
OE.External Device X
OE.Manufacturing X
OE.Delivery X X
OE.KeyGeneration X X
OE.SecureStorage X
OE.KeyTransportation X X
OE.TestEnvironment X
OE.StrongAlgorithm X
OE.UpgradeSoftware X
OE.TrustedUser X X
OE.Control X
OE.SecureEnvironment X X X X X X
Justification about Table 2 is given below;
T.AccessControl is addressed by O.AccessControl to control user access to functions and data;
O.Authentication to provide authentication mechanism for users; O.Event to log all access attempts.
T.Authentication is addressed by O.Authentication to ensure if user authenticated to the FCR or not;
O.Event to log successful/unsuccessful authentication attempts.
T.MDData is addressed by O.Integrity to ensure integrity of sales data, event data, characterization
data and FCR parameters in FCR with logical and physical security features; O.Transfer to ensure
integrity, confidentiality and authenticity of sales data, event data and characterization data during
transferring to PRA-IS and parameters during transferring from TSM to FCR ; O.Event to log
unexpected behavior of these memories and unexpected behavior in transferring data;
OE.SecureEnvironment to provide electronic seal.
T.Eavesdropping is addressed by O.Transfer to ensure confidentiality of sales data, event data and
characterization data during communication with PRA-IS; O.Integrity to ensure the integrity of event
data, sales data and characterization data. O.Event to log physical tamper; by OE.SecureEnvironment
to provide electronic seal.
T.Skimming is addressed by O.Authentication to establish communication only w i t h permitted
systems.
T.Counterfeit is addressed by O.Integrity to ensure the integrity of sensitive data (session keys);
O.Event to log physical tamper; OE.SecureEnvironment to provide electronic seal.
T.Malfunction is addressed by O.Function to ensure functions processing accurately; O.Event to log
unexpected behavior of functions.
T.ChangingTime is addressed by O.Event to log unexpected changes in time information; by O.Access
Control to control user access to time information; by O.Function to ensure accuracy of time
information.
P.Certificate is fulfilled by OE.KeyGeneration.
P.SecureEnvironment is fulfilled by OE.SecureEnvironment, O.Event and O.Integrity and O.Function.
P.PhysicalTamper is fulfilled by OE.SecureEnvironment, O.AccessControl, O.Event, O.Integrity and
OE.SecureStorage
P.PKI is fulfilled by OE.Delivery and OE.KeyTransportation
P.InformationLeakage is fulfilled by OE.StrongAlgorithm to ensure that cryptographic algorithms used
by FCR have side channel protection.
P.Comm_EXT is fulfilled by O.Transfer.
P. UpdateControl is upheld by OE.UpgradeSoftware and O.Authentication.
A.Ext_Key is upheld OE.External Device.
A. TrustedManufacturer is upheld by OE.Manufacturing and OE.TestEnvironment.
A.Control is upheld by OE.Control.
A. AuthorisedService is upheld by OE.TrustedUser.
A.Initialisation is upheld by OE.KeyGeneration, OE.SecureEnvironment and OE.KeyTransportation.
A.Activation is upheld by OE.Delivery.
A. TrustedUser is upheld by OE.TrustedUser.
5. EXTENDED COMPONENTS DEFINITION
This protection profile does not use any components defined as extensions to CC part 2.
6. SECURITY REQUIREMENTS
This chapter describes the security functional and the assurance requirements which have to be
fulfilled by the TOE. Those requirements comprise functional components from CC part 2 and the
assurance components as defined for the Evaluation Assurance Level 2 from CC part 3.
The following notations are used:
Refinement operation (denoted in such a way that added words are in bold text and changed words
are crossed out): is used to add details to a requirement, and thus further restricts a requirement.
Selection operation (denoted by italicised bold text and placed in square bracket): is used to select
one or more options provided by the [CC] in stating a requirement.
Assignment operation (denoted by underlined text and placed in square bracket): is used to assign a
specific value to an unspecified parameter, such as the length of a password. Showing the value in
square brackets indicates assignment.
Iteration operation are identified with a slash (e.g. “(/)”)
6.1. Security Functional Requirements for the TOE
This chapter defines the security functional requirements for the TOE according to the functional
requirements components drawn from the CC part 2 version 3.1 revision 4.
6.1.1. Class FAU Security Audit
6.1.1.1. FAU_GEN Security audit data generation
FAU_GEN.1 Audit data generation
Hierarchical to:
Dependencies: FPT_STM.1 Reliable time stamps: is 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 [not specified] level of audit; and
c) [the auditable events specified in PRA Messaging Protocol Document [6] ]
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, 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, [none]
6.1.1.2. FAU_SAR Security audit review
FAU_SAR.1 Audit review
Hierarchical to:
Dependencies: FAU_GEN.1 Audit data generation.
FAU_SAR.1.1 The TSF shall provide [Authorised Manufacturer User] with the capability to read
[all event data] 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.3. FAU_STG Security audit event storage
FAU_STG.1 Protected audit trail storage
Hierarchical to: -
Dependencies: FAU_GEN.1 Audit data generation
FAU_STG.1.1 The TSF shall protect the stored audit records in the audit trail from unauthorised
deletion.
FAU_STG.1.2 The TSF shall be able to [prevent] unauthorised modifications to the stored audit
records in the audit trail.
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 trail storage
FAU_STG.4.1 The TSF shall [overwrite the oldest stored audit records] and [none] if the audit
trail is full.
6.1.2. Class FCO Communication
6.1.2.1. FCO_NRO Non-repudiation of origin
FCO_NRO.2 Enforced proof of origin
Hierarchical to: FCO_NRO.1 Selective proof of origin
Dependencies: FIA_UID.1 Timing of identification
FCO_NRO.2.1 The TSF shall enforce the generation of evidence of origin for transmitted [sales
data and event data] at all times.
FCO_NRO.2.2 The TSF shall be able to relate the [originator identity, time of origin] of the
originator of the information, and the [body of the message] of the information to
which the evidence applies.
FCO_NRO.2.3 The TSF shall provide a capability to verify the evidence of origin of information to
[recipient] given [immediately].
6.1.3. Class FCS Cryptographic Support
6.1.3.1. FCS_CKM Cryptographic key management
FCS_CKM.1/TLS_AES Cryptographic key generation
Hierarchical to: -
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm [PRF] and specified cryptographic key
sizes [AES:128 bits and/or AES:256 bits] that meet the following: [RFC 5246].
FCS_CKM.1/TLS_HMAC Cryptographic key generation
Hierarchical to: -
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm [PRF] and specified cryptographic key sizes
[256 bit] that meet the following: [RFC 5246].
FCS_CKM.1/ DHE-KEY Cryptographic key generation
Hierarchical to: -
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm [RNG] and specified cryptographic key
sizes [2048 bits] that meet the following: [IEEE 1363, ANSI X9.31].
FCS_CKM.1/ EXT-DEV KHMAC Cryptographic key generation
Hierarchical to: -
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm [PRF] and specified cryptographic key sizes
[256 bits] that meet the following: [RFC 5246].
FCS_CKM.1/ EXT-DEV KENC Cryptographic key generation
Hierarchical to: -
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm [PRF] and specified cryptographic key sizes
[AES:256 bits] that meet the following: [RFC 5246].
FCS_CKM.4 Cryptographic key destruction
Hierarchical to: -
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]
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method [as specified below] that meets the
following: [none].
a) Deletion after use of AES key for PRA and TSM communication and RSA
pairing keys
b) New Pairing AES key is overwritten when new pairing needed, otherwise
it is not deleted
c) Other certificates are not necessary to delete because no confidentiality
needs for the public keys
6.1.3.2. FCS_COP Cryptographic operation
FCS_COP.1/ENC-DEC Cryptographic operation
Hierarchical to: -
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]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1 The TSF shall perform [encryption, decryption] in accordance with a specified
cryptographic algorithm [AES] and cryptographic key sizes [AES:128 bits and
AES:256 bits] that meet the following: [NIST SP800-38A].
FCS_COP.1/INT-AUTH Cryptographic operation
Hierarchical to: -
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]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1 The TSF shall perform [authentication and integrity protection] in accordance with
a specified cryptographic algorithm [HMAC-SHA256] and cryptographic key sizes
[256 bits] that meet the following: [FIPS 198-1 and NIST FIPS PUB 180-2].
FCS_COP.1/HASHING Cryptographic operation
Hierarchical to: -
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]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1 The TSF shall perform [hashing] in accordance with a specified cryptographic
algorithm [SHA2] and cryptographic key sizes [none] that meet the following: [NIST
FIPS PUB 180-2].
Application Note 2: No need to include any dependencies because there is no need to use any key for
HASHING
FCS_COP.1/EXT-DEV KEYEXCHANGE Cryptographic operation
Hierarchical to: -
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]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1 The TSF shall perform [key exchange] in accordance with a specified cryptographic
algorithm [DHE] and cryptographic key sizes [2048 bits] that meet the following:
[NIST SP 800-56A].
FCS_COP.1/ EXT-DEV KENC Cryptographic operation
Hierarchical to: -
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]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1 The TSF shall perform [encryption and decryption] in accordance with a specified
cryptographic algorithm [AES with CBC] and cryptographic key sizes [256 bits] that
meet the following: [NIST SP800-38A (CBC.AES256)].
FCS_COP.1/ EXT-DEV KHMAC Cryptographic operation
Hierarchical to: -
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]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1 The TSF shall perform [encryption and decryption for integrity protection] in
accordance with a specified cryptographic algorithm [HMAC-SHA256] and
cryptographic key sizes [256 bits] that meet the following: [FIPS 198-1 and NIST
FIPS PUB 180-2].
6.1.4. Class FDP User Data Protection
6.1.4.1. FDP_ACC Access control policy
FDP_ACC.1 Subset access control
Hierarchical to: -
Dependencies: FDP_ACF.1 Security attribute based access control
FDP_ACC.1.1 The TSF shall enforce the [Administrative Access Control SFP ] on [Subjects: FCR
Authorised User and Authorised Manufacturer User
Objects: Sales and event data, exchange rates, time information.
Operations: Secure state mode and maintenance mode actions]
6.1.4.2. FDP_ACF Access control functions
FDP_ACF.1 Security attribute based access control
Hierarchical to: -
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
FDP_ACF.1.1 The TSF shall enforce the [Administrative Access Control SFP] to objects based on
the following:
[Subjects: FCR Authorised User and Authorised Manufacturer User
Subject Attributes: User Identity, Privileges
Objects: Sales and event data, exchange rates, time information.
Object Attributes: Access Control List (secure state mode and maintenance mode
access rights).
Operations: Secure state mode and maintenance mode actions describe in 3.1.3
FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed: [verify the operator’s user
identity, privileges].
FDP_ACF.1.3 The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules: [none].
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the following
additional rules: [none].
6.1.4.3. FDP_ETC Export from the TOE
FDP_ETC.2/TSM Export of user data with security attributes
Hierarchical to: -
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FDP_ETC.2.1 The TSF shall enforce the [Information Flow Control SFP with TSM and PRA-IS]
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:
[secure communication with SSL CA].
FDP_ETC.2/EFTPOS Export of user data with security attributes
Hierarchical to: -
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FDP_ETC.2.1 The TSF shall enforce the [Information Flow Control SFP with EFT-POS Device]
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:
[Communication with secure messaging according to External Device
Communication Protocol Document [8]].
FDP_ETC.2/MAIN UNIT Export of user data with security attributes
Hierarchical to: -
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FDP_ETC.2.1 The TSF shall enforce the [Information Flow Control SFP with Main Unit] 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:
[Communication with secure messaging according to External Device
Communication Protocol Document [8]].
6.1.4.4. FDP_IFC Information flow control policy
FDP_IFC.1/TSMCOMMUNICATION Subset information flow control
Hierarchical to: -
Dependencies: FDP_IFF.1 Simple security attributes
FDP_IFC.1.1 The TSF shall enforce the [Information Flow Control SFP with TSM and PRA- IS] on
[subjects (TSM and PRA-IS) and objects (sales data ,event data reports, FCR
parameters) as specified in PRA Messaging Protocol Document [6]]
FDP_IFC.1/EFTPOSCOMMUNICATION Subset information flow control
Hierarchical to: -
Dependencies: FDP_IFF.1 Simple security attributes
FDP_IFC.1.1 The TSF shall enforce the [Information Flow Control SFP with EFT-POS Device] on
[subjects (EFT-POS) and objects (amount information in sales data, slip data
request, EOD requests, loyalty card operation commands, bank selection
command, other banking operational commands, EFT-POS status commands, etc)
as specified in External Device Communication Protocol Document [8] ]
FDP_IFC.1/MAIN UNIT Subset information flow control
Hierarchical to: -
Dependencies: FDP_IFF.1 Simple security attributes
FDP_IFC.1.1 The TSF shall enforce the [Information Flow Control SFP with Main Unit] on
[subjects (Main Unit) and objects (department information of purchased good,
amount of purchased good, unit price of purchased good, discounts, raises and
non-financial informative data, payment information, sub-total request, printing
commands, service mode commands, system requests ( get time, printer status,
health check request, integrity check request, user operations commands, etc), )
as specified in External Device Communication Protocol Document [8] ]
6.1.4.5. FDP_IFF Information flow control functions
FDP_IFF.1/TSMCOMMUNICATION Simple security attributes
Hierarchical to: -
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
FDP_IFF.1.1 The TSF shall enforce the [Information Flow Control SFP with TSM and PRA-IS]
based on the following types of subject and information security attributes: [TOE
has ability to send reports related to sales data and event data reports to PRA-IS
by using subject identifier(IP/Port information) and object identifier (file name(s)
for sales data, event object name for event data); TOE has ability to receive FCR
parameters from TSM by using subject identifier (IP/Port information) and object
identifier (information label) according to PRA Messaging Protocol Document [6]].
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:
[secure communication with SSL CA].
FDP_IFF.1.3 The TSF shall enforce the [none].
FDP_IFF.1.4 The TSF shall explicitly authorise 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].
FDP_IFF.1/EFT-POSCOMMUNICATION Simple security attributes
Hierarchical to: -
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
FDP_IFF.1.1 The TSF shall enforce the [Information Flow Control SFP with EFT-POS Device]
based on the following types of subject and information security attributes: [TOE
has ability to send amount information to EFT-POS Device by using subject
identifier (EFT-POS label and source port).TOE has ability to receive outcome of
the operation conducted by the EFT-POS Device by using subject identifier (source
port)].
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:
[Communication with secure messaging according to External Device
Communication Protocol Document [8]].
FDP_IFF.1.3 The TSF shall enforce the [none].
FDP_IFF.1.4 The TSF shall explicitly authorise 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].
FDP_IFF.1/MAIN UNIT Simple security attributes
Hierarchical to: -
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
FDP_IFF.1.1 The TSF shall enforce the [Information Flow Control SFP with Main Unit] based on
the following types of subject and information security attributes: [TOE has ability
to receive department information of purchased good, amount of purchased good
and unit price of purchased good by using subject identifier (source port) and
object identifier (information label)].
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:
[Communication with secure messaging according to External Device
Communication Protocol Document [8]].
FDP_IFF.1.3 The TSF shall enforce the [none].
FDP_IFF.1.4 The TSF shall explicitly authorise 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].
6.1.4.6. FDP_ITC Import from the outside of the TOE
FDP_ITC.2/TSM Import of user data with security attributes
Hierarchical to: -
Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control]
[FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path]
FPT_TDC.1 Inter-TSF basic TSF data consistency
FDP_ITC.2.1 The TSF shall enforce the [Information Flow Control SFP with TSM and PRA-IS]
when importing user data, controlled under the SFP, from outside of the TOE.
FDP_ITC.2.2 The TSF shall use the security attributes associated with the imported user data.
FDP_ITC.2.3 The TSF shall ensure that the protocol used provides for the unambiguous
association between the security attributes and the user data received.
FDP_ITC.2.4 The TSF shall ensure that interpretation of the security attributes of the imported
user data is as intended by the source of the user data.
FDP_ITC.2.5 The TSF shall enforce the following rules when importing user data controlled
under the SFP from outside the TOE: [secure communication with SSL CA].
FDP_ITC.2/EFTPOS Import of user data with security attributes
Hierarchical to: -
Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control]
[FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path]
FPT_TDC.1 Inter-TSF basic TSF data consistency
FDP_ITC.2.1 The TSF shall enforce the [Information Flow Control SFP with EFT-POS Device]
when importing user data, controlled under the SFP, from outside of the TOE.
FDP_ITC.2.2 The TSF shall use the security attributes associated with the imported user data.
FDP_ITC.2.3 The TSF shall ensure that the protocol used provides for the unambiguous
association between the security attributes and the user data received.
FDP_ITC.2.4 The TSF shall ensure that interpretation of the security attributes of the imported
user data is as intended by the source of the user data.
FDP_ITC.2.5 The TSF shall enforce the following rules when importing user data controlled
under the SFP from outside the TOE: [Communication with secure messaging
according to External Device Communication Protocol Document [8]].
FDP_ITC.2/MAIN UNIT Import of user data with security attributes
Hierarchical to: -
Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control]
[FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path]
FPT_TDC.1 Inter-TSF basic TSF data consistency
FDP_ITC.2.1 The TSF shall enforce the [Information Flow Control SFP with Main Unit] when
importing user data, controlled under the SFP, from outside of the TOE.
FDP_ITC.2.2 The TSF shall use the security attributes associated with the imported user data.
FDP_ITC.2.3 The TSF shall ensure that the protocol used provides for the unambiguous
association between the security attributes and the user data received.
FDP_ITC.2.4 The TSF shall ensure that interpretation of the security attributes of the imported
user data is as intended by the source of the user data.
FDP_ITC.2.5 The TSF shall enforce the following rules when importing user data controlled
under the SFP from outside the TOE: [Communication with secure messaging
according to External Device Communication Protocol Document [8]].
6.1.4.7. FDP_SDI Stored data integrity
FDP_SDI.2/MEMORY Stored data integrity monitoring and action
Hierarchical to: FDP_SDI.1 Stored data integrity monitoring
Dependencies: -
FDP_SDI.2.1 The TSF shall monitor user data sales data stored in fiscal memory and ERU, event
data, authentication data and characterization data stored in containers
controlled by the TSF for [integrity errors] on all objects, based on the following
attributes: [assignment: user data attributes].
FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall [as described below]
a) Generate an audit event and transmit it to the PRA-IS according to PRA
Messaging Protocol Document [6].
b) Block FCR and enter maintenance node for critical events
FDP_SDI.2/ DAILY and PRMTR Stored data integrity monitoring and action
Hierarchical to: FDP_SDI.1 Stored data integrity monitoring
Dependencies: -
FDP_SDI.2.1 The TSF shall monitor user data sales data stored in daily memory and FCR
Parameters stored in containers controlled by the TSF for [integrity errors] on all
objects, based on the following attributes: [assignment: user data attributes].
FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall [as described below]
a) generate an audit event and transmit it to the PRA-IS according to PRA
messaging protocol document [6].
b) Print Z report automatically
6.1.5. Class FIA Identification and Authentication
6.1.5.1. FIA_AFL Authentication failures
FIA_AFL.1/MANUFACTURER Authentication failure handling
Hierarchical to: -
Dependencies: FIA_UAU.1 Timing of authentication
FIA_AFL.1.1 The TSF shall detect when [three] unsuccessful authentication attempts occur
related to [Authorised Manufacturer User authentication].
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been
[met], the TSF shall [warn the user and make user wait for a new authentication
attempt for 15 minutes].
FIA_AFL.1/AUTHORISED Authentication failure handling
Hierarchical to: -
Dependencies: FIA_UAU.1 Timing of authentication
FIA_AFL.1.1 The TSF shall detect when [ten] unsuccessful authentication attempts occur
related to [FCR Authorised User].
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been
[met], the TSF shall [warn the user and make user wait for a new authentication
attempt for 15 minutes].
6.1.5.2. FIA_UAU User authentication
FIA_UAU.1 Timing of authentication
Hierarchical to: -
Dependencies: FIA_UID.1 Timing of identification
FIA_UAU.1.1 The TSF shall allow [to do fiscal sales, to get X report] on behalf of the user to be
performed before the user is authenticated.
FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing
any other TSF-mediated actions on behalf of that user
Application Note 3 : ”To do fiscal sales” function can be performed by FCR User (Cashier) by design.
“To get X report” function can be performed by FCR User (Cashier), FCR Authorized User and FCR
Manufacturer User. FCR User’ s identity is verified by Main Unit.
FIA_UAU.4 Single-use authentication mechanisms
Hierarchical to: -
Dependencies: -
FIA_UAU.4.1 The TSF shall prevent reuse of authentication data related to [the authentication
mechanism employed to authenticate Authorised Manufacturer User].
6.1.6. Class FMT Security Management
6.1.6.1. FIA_UID User Identification
FIA_UID.1 Timing of identification
Hierarchical to: -
Dependencies: -
FIA_UID.1.1 The TSF shall allow [to do fiscal sales, to get X report] on behalf of the user to be
performed before the user is identified.
FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing any
other TSF-mediated actions on behalf of that user.
Application Note 4 :”To do fiscal sales” function can be performed by FCR User (Cashier) by design. “To
get X report” function can be performed by FCR User (Cashier), FCR Authorized User and FCR
Manufacturer User. FCR User’ s identity is verified by Main Unit. Class FMT Security Management
6.1.6.2. FMT_MOF Management of security functions behaviour
FMT_MOF.1 Management of security functions behaviour
Hierarchical to: -
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MOF.1.1 The TSF shall restrict the ability to [modify the behaviour of] the functions [new
generation cash register fiscal application software normal operation functions] to
nobody.
6.1.6.3. FMT_MSA Management of security attributes
FMT_MSA.1/USER IDENTITY Management of security attributes
Hierarchical to: -
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MSA.1.1 The TSF shall enforce the [Administrative Access Control SFP] to restrict the ability
to [modify] the security attributes [User Identity] to [FCR Authorised User].
FMT_MSA.1/PRIVILEGES Management of security attributes
Hierarchical to: -
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MSA.1.1 The TSF shall enforce the [Administrative Access Control SFP] to restrict
the ability to [modify] the security attributes [Privileges] to [none].
FMT_MSA.1/IP:PORT INFO Management of security attributes
Hierarchical to: -
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MSA.1.1 The TSF shall enforce the [Information Flow Control SFP with TSM and
PRA-IS] to restrict the ability to [modify] the security attributes [IP:Port
Information] to [Authorised Manufacturer User].
FMT_MSA.1/FILE NAME and INFO-LABEL Management of security attributes
Hierarchical to: -
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MSA.1.1 The TSF shall enforce the [Information Flow Control SFP with TSM and
PRA-IS] to restrict the ability to [modify] the security attributes [file name
and information label] to [none].
FMT_MSA.1/INFO-LABEL Management of security attributes
Hierarchical to: -
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MSA.1.1 The TSF shall enforce the [Information Flow Control SFP with Main Unit]
to restrict the ability to [modify] the security attributes [information label]
to [none].
FMT_MSA.1/MAIN UNIT SOURCE PORT INFO Management of security attributes
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MSA.1.1 The TSF shall enforce the [Information Flow Control SFP with Main Unit] to
restrict the ability to [modify] the security attributes [Source Port] to [none].
FMT_MSA.1/EFTPOS SOURCE PORT INFO Management of security attributes
Hierarchical to: -
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MSA.1.1 The TSF shall enforce the [Information Flow Control SFP with EFT-POS
Devices] to restrict the ability to [modify] the security attributes [Source
Port] to [none].
FMT_MSA.1/EFT-POS LABEL INFO Management of security attributes
Hierarchical to: -
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MSA.1.1 The TSF shall enforce the [Information Flow Control SFP with EFT_POS
Device] to restrict the ability to [modify] the security attributes [EFT-POS
Label] to [none].
FMT_MSA.3/USERS and SYSTEMS Static attribute initialisation
Hierarchical to: -
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_MSA.3.1 The TSF shall enforce the [Administrative Access Control SFP, Information Flow
Control SFP with TSM and PRA-IS] to provide [restrictive] default values for
security attributes that are used to enforce the SFP.
FMT_MSA.3.2 The TSF shall allow the [none] to specify alternative initial values to override the
default values when an object or information is created.
FMT_MSA.3/EFTPOS Static attribute initialisation
Hierarchical to: -
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_MSA.3.1 The TSF shall enforce the [Information Flow Control SFP with EFT-POS Device]
to provide [permissive] default values for security attributes that are used to
enforce the SFP.
FMT_MSA.3.2 The TSF shall allow the [none] to specify alternative initial values to override the
default values when an object or information is created.
FMT_MSA.3/MAIN UNIT Static attribute initialisation
Hierarchical to: -
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_MSA.3.1 The TSF shall enforce the [[Information Flow Control SFP with Main Unit]to
provide [permissive] default values for security attributes that are used to
enforce the SFP.
FMT_MSA.3.2 The TSF shall allow the [none] to specify alternative initial values to override the
default values when an object or information is created.
6.1.6.4. FMT_MTD Management of TSF data
FMT_MTD.1/FCR AUTHORISED USER Management of TSF data
Hierarchical to: -
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MTD.1.1 The TSF shall restrict the ability to [modify] the [FCR Authorised User’s
authentication data] to [FCR Authorised Manufacturer User] and [create, modify,
delete] the [FCR Authorised User’s authentication data] to [FCR Authorised User]
FMT_MTD.1/AUTHORISED MANUFACTURER USER Management of TSF data
Hierarchical to: -
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MTD.1.1 The TSF shall restrict the ability to [create] the [Authorised Manufacturer User’s
authentication data] to [assignment: the authorised identified roles] [nobody].
Application Note 5: No authorised identified roles make the changes on Authorised Manufacturer
User’s authentication data but manufacturer trusted server creates it.
6.1.6.5. FMT_SMF Specification of Management Functions
FMT_SMF.1 Specification of Management Functions
Hierarchical to: -
Dependencies: -
FMT_SMF.1.1 The TSF shall be capable of performing the following management functions:
[Authorised Manufacturer User modifies IP: Port Information, FCR Authorised User
add and delete other FCR Authorised User Identity, FCR Authorised User modifies
FCR Authorised User’s authentication data, Authorised Manufacturer User
changes to default FCR Authorised User’s User Identity and FCR Authorised User’s
authentication data]
6.1.6.6. FMT_SMR Security management roles
FMT_SMR.2 Restrictions on security roles
Hierarchical to: FMT_SMR.1 Security roles
Dependencies: FIA_UID.1 Timing of identification
FMT_SMR.2.1 The TSF shall maintain the roles: [FCR Authorised User, Authorised Manufacturer
User].
FMT_SMR.2.2 The TSF shall be able to associate users with roles.
FMT_SMR.2.3 The TSF shall ensure that the conditions [Authorised Manufacturer User shall take
action in maintenance works and FCR authorised user take action in secure state
works] are satisfied.
6.1.7. Class FPT Protection of the TS
6.1.7.1. FPT_FLS Fail secure
FPT_FLS.1 Failure with preservation of secure state
Hierarchical to: -
Dependencies: -
FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of failures
occur:[except maintenance mode events that specified in section 3.1.3]
6.1.7.2. FPT_PHP TSF physical protection
FPT_PHP.2 Notification of physical attack
Hierarchical to: FPT_PHP.1 Passive detection of physical attack
Dependencies: FMT_MOF.1 Management of security functions behaviour
FPT_PHP.2.1 The TSF shall provide unambiguous detection of physical tampering that might
compromise the TSF.
FPT_PHP.2.2 The TSF shall provide the capability to determine whether physical tampering with
the TSF's devices or TSF's elements has occurred.
FPT_PHP.2.3 For [the devices/elements for which active detection is required in Technical
Guidance Document [5]], and elements and notify [FCR Authorised user] when
physical tampering with the TSF's devices or TSF's elements has occurred.
6.1.7.3. FPT_RCV Trusted recovery
FPT_RCV.1 Manual recovery
Hierarchical to: -
Dependencies: AGD_OPE.1 Operational user guidance
FPT_RCV.1.1 After [maintenance mode events which expressed in section 3.1.3 occur] the TSF
shall enter a maintenance mode where the ability to return to a secure state is
provided.
FPT_RCV.4 Function recovery
Hierarchical to: -
Dependencies: -
FPT_RCV.4.1 The TSF shall ensure that [except maintenance mode events that specified in
section 3.1.3] have the property that the function either completes successfully,
or for the indicated failure scenarios, recovers to a consistent and secure state.
6.1.7.4. FPT_STM Time stamps
FPT_STM.1 Reliable time stamps
Hierarchical to: -
Dependencies: -
FPT_STM.1.1 The TSF shall be able to provide reliable time stamps.
6.1.7.5. FPT_TDC Inter-TSF TSF data consistency
FPT_TDC.1 Inter-TSF basic TSF data consistency
Hierarchical to: -
Dependencies: -
FPT_TDC.1.1 The TSF shall provide the capability to consistently interpret [CheckSum] when
shared between the TSF and another trusted IT product.
FPT_TDC.1.2 The TSF shall use [SSL client authentication] when interpreting the TSF data from
another trusted IT product.
6.1.7.6. FPT_TEE Testing of external entities
FPT_TEE.1/EXT Testing of external entities
Hierarchical to: -
Dependencies: -
FPT_TEE.1.1 The TSF shall run a suite of tests [during initial start-up and during fiscal
transactions] to check the fulfilment of [proper working of external entities].
FPT_TEE.1.2 If the test fails, the TSF shall [generate an audit event according to Technical
Guidance Document [5] ]
Application Note 6: External entities are ERU, fiscal memory, daily memory, mesh cover and electronic
seal.
FPT_TEE.1/TIME Testing of external entities
Hierarchical to: -
Dependencies: -
FPT_TEE.1.1 The TSF shall run a suite of tests [during time synchronization with NTP] to check
the fulfilment of [accuracy of time information].
FPT_TEE.1.2 If the test fails, the TSF shall [overwrite time information received from trusted
server, generate an audit event according to Technical Guidance Document [5] ]
6.1.7.7. FPT_TST TSF self test
FPT_TST.1 TSF testing
Hierarchical to: -
Dependencies: -
FPT_TST.1.1 The TSF shall run a suite of self tests [during initial start-up and periodically during
normal operation] to demonstrate the correct operation of [parts of TSF (as
specified below)].
a. All Security functions integrity check is done during start-up to
demonstrate the correct operation of TSF
b. Integrity security function is tested by checking known output test once
per hour,
FPT_TST.1.2 The TSF shall provide authorised users with the capability to verify the integrity of
[parts of TSF data].
FPT_TST.1.3 The TSF shall provide authorised users with the capability to verify the integrity of
[parts of TSF].
Application Note 7: TOE gives opportunity to verify integrity of following TSF data and TSF to
Authorised Users.
 Parts of TSF data: Sales data, event data, characterisation data.
 Parts of TSF: Integrity security function
6.1.8. Class FTP Trusted Patch/Channels
6.1.8.1. FTP_ITC Inter-TSF trusted channel
FTP_ITC.1 Inter-TSF trusted channel
Hierarchical to: -
Dependencies: -
FTP_ITC.1.1 The TSF shall provide a communication channel between itself and another trusted
IT product that is logically distinct from other communication channels and
provides assured identification of its end points 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 [sending user data
(sales and event data) to PRA-IS and receiving user data (FCR parameters and
exchange rates) from TSM].
6.2. Security Assurance Requirements for the TOE
The assurance requirements for the evaluation of the TOE and for its development and operating
environment are chosen as the predefined assurance package EAL2.
6.3. Security Requirements Rationale
6.3.1. Security Functional Requirements Rationale
Table 3 provides an overview for security functional requirements coverage and also giving an
evidence for sufficiency and necessity of the SFRs chosen.
Table 3 Coverage of security objectives by SFRs for TOE
O.AccessControl
O.Event
O.Integrity
O.Authentication
O.Function
O.Transfer
FAU_GEN.1 Audit data generation X
FAU_SAR.1 Audit review X
FAU_STG.1 Protected audit trail storage X
FAU_STG.4 Prevention of audit data loss X
FCO_NRO.2 Enforced proof of origin X
FCS_CKM.1/TLS_AES Cryptographic key generation X
FCS_CKM.1/TLS_HMAC Cryptographic key generation X
FCS_CKM.1/ DHE-KEY Cryptographic key generation X
FCS_CKM.1/ EXT-DEV KENC Cryptographic key generation X
FCS_CKM.1/ EXT-DEV Khmac Cryptographic key generation X
O.AccessControl
O.Event
O.Integrity
O.Authentication
O.Function
O.Transfer
FCS_CKM.4 Cryptographic key destruction X
FCS_COP.1/ ENC-DEC Cryptographic operation X
FCS_COP.1/INT-AUTH Cryptographic operation X
FCS_COP.1/HASHING Cryptographic operation X
FCS_COP.1/EXT-DEV KENC Cryptographic operation X
FCS_COP.1/EXT-DEV KHMAC Cryptographic operation X
FCS_COP.1/EXT-DEV
KEYEXCHANGE
Cryptographic operation X
FDP_ACC.1 Subset access control X
FDP_ACF.1 Security attribute based access control X
FDP_ETC.2/TSM Export of user data with security
attributes
X
FDP_ETC.2/EFTPOS Export of user data with security
attributes
X
FDP_ETC.2/MAIN UNIT Export of user data with security
attributes
X
FDP_IFC.1/TSMCOMMUNICA
TION
Subset information flow control X
FDP_IFC.1/EFTPOSCOMMUN
ICATION
Subset information flow control X
FDP_IFC.1/MAIN UNIT Subset information flow control X
FDP_IFF.1/TSMCOMMUNICA
TION
Simple security attributes X
FDP_IFF.1/EFT-
POSCOMMUNICATION
Simple security attributes X
FDP_IFF.1/MAIN UNIT Simple security attributes X
O.AccessControl
O.Event
O.Integrity
O.Authentication
O.Function
O.Transfer
FDP_ITC.2/TSM Import of user data with security
attributes
X
FDP_ITC.2/EFTPOS Import of user data with security
attributes
X
FDP_ITC.2/MAIN UNIT Import of user data with security
attributes
X
FDP_SDI.2 /MEMORY Stored data integrity monitoring and
action
X
FDP_SDI.2/DAILY and PRMTR Stored data integrity monitoring and
action
X
FIA_AFL.1/MANUFACTURER Authentication failure handling X
FIA_AFL.1/AUTHORISED Authentication failure handling X
FIA_UAU.1 Timing of authentication X
FIA_UAU.4 Single-use authentication mechanisms X
FIA_UID.1 Timing of identification X
FMT_MOF.1 Management of security functions
behaviour
X
FMT_MSA.1/USER IDENTITY Management of security attributes X
FMT_MSA.1/PRIVILEGES Management of security attributes X
FMT_MSA.1/IP:PORT INFO Management of security attributes X
FMT_MSA.1/FILE NAME and
INFO-LABEL
Management of security attributes X
FMT_MSA.1/INFO-LABEL Management of security attributes X
FMT_MSA.1/MAIN UNIT
SOURCE PORT INFO
Management of security attributes X
O.AccessControl
O.Event
O.Integrity
O.Authentication
O.Function
O.Transfer
FMT_MSA.1/EFTPOS
SOURCE PORT INFO
Management of security attributes X
FMT_MSA.1/EFT-POS LABEL
INFO
Management of security attributes X
FMT_MSA.3/USERS and
SYSTEMS
Static attribute initialisation X X
FMT_MSA.3/EFTPOS Static attribute initialisation X
FMT_MSA.3/MAIN UNIT Static attribute initialisation X
FMT_MTD.1/FCR
AUTHORISED USER
Management of TSF data X X
FMT_MTD.1/ AUTHORISED
MANUFACTURER USER
Management of TSF data X
FMT_SMF.1 Specification of Management Functions X
FMT_SMR.2 Restrictions on security roles X
FPT_FLS.1 Failure with preservation of secure state X
FPT_PHP.2 Notification of physical attack X X
FPT_RCV.1 Manual recovery X
FPT_RCV.4 Function recovery X
FPT_STM.1 Reliable time stamps X
FPT_TDC.1 Inter-TSF basic TSF data consistency X
FPT_TEE.1/EXT Testing of external entities X
FPT_TEE.1/TIME Testing of external entities X
FPT_TST.1 TSF testing X X
O.AccessControl
O.Event
O.Integrity
O.Authentication
O.Function
O.Transfer
FTP_ITC.1 Inter-TSF trusted channel X
A detailed justification of required for suitability of the security functional requirements to achieve
the security objectives is given in Table 4.
Table 4 Suitability of the SFRs
Security Objective Security Functional Requirement
O.AccessControl
FDP_ACC.1
Provides security functional policy for functions and
data
FDP_ACF.1 Defines security attributes for functions and data
FAU_SAR.1 Allows users to read audit records
FMT_MSA.1/USER
IDENTITY
Provides the functions to restrict the ability to
modify the security attribute (User Identity) to
FCR Authorised User
FMT_MSA.1/PRIVILEG
ES
Provides the functions to restrict the ability to
modify the security attributes (privileges) to
nobody.
FMT_MSA.3/USERS
and SYSTEMS
Provides the functions to provide restrictive default
values for security attributes that are used to
enforce the SFP and allows nobody to specify
alternative initial values to override the default
values when an object or information is created.
FMT_SMF.1
Describe the specification of management
functions being allowed to use in maintenance
mode and secure state mode.
FMT_SMR.2 Maintains the roles with restrictions
FMT_MTD.1/
AUTHORISED
MANUFACTURER
USER
Provides authorised processing of FCR
Manufacturer User’s authentication data
FMT_MTD.1/FCR
AUTHORISED USER
Provides authorised modification of FCR Authorised
User’s authentication data
O.Event
FAU_GEN.1 Generates correct audit events
FPT_STM.1 Provides accurate time for logging events
O.Integrity
FAU_STG.1
Protects stored audit data integrity from
unauthorised deletion
FAU_STG.4 Prevents loss of audit data loss
FPT_PHP.2
Generation of audit event detection of physical
tampering
FDP_SDI.2/MEMORY Monitors user data stored for integrity errors
FDP_SDI.2/DAILY and
PRMTR
Monitors user data stored for integrity errors
FPT_TST.1
Ensures accuracy of its functions working by
conducting self-test
FPT_TDC.1
Provides the capability to consistently interpret TSF
data (checksum)
O.Authentication
FIA_AFL.1/MANUFAC
TURER
Detects and records authentication failure events
for Authorised Manufacturer User
FIA_AFL.1/
AUTHORISED
Detects and records authentication failure events
for FCR Authorised User
FIA_UAU.1
Defines user authentication before allowing to do
fiscal sales
FIA_UAU.4
Provides single use authentication mechanism for
Authorised Manufacturer User
FIA_UID.1
Defines user identification before allowing to do
fiscal sales
FMT_MTD.1/ FCR
AUTHORISED USER
Provides authorised processing of FCR Authorised
User’s authentication data
FCS_COP.1/HASHING
Provides authentication operation for PRA-IS and
TSM
O.Function
FMT_MOF.1
Restricts the ability to enable the functions to
nobody and, thus, prevents an unintended access to
data in the operational phase.
FPT_FLS.1
Failure types which makes new generation cash
register fiscal application software continue working
in secure state
FPT_RCV.1
Provides new generation cash register fiscal
application software start working in maintenance
mode in failure. (has ability to switch to the secure
state manually)
FPT_RCV.4
Provides new generation cash register fiscal
application software start working in maintenance
mode in failure. (has ability to switch to the secure
state automatically with functions)
FPT_TEE.1/EXT
Provides test for IT environment for functioning
accurately
FPT_TEE.1/TIME Provides test for time information for accuracy
FPT_TST.1
Ensures accuracy of its functions working by
conducting self-test
O.Transfer
FCS_CKM.1/TLS_AES
Generates session keys for communication
between FCR-PRA-IS and FCR–TSM
FCS_CKM.1/TLS_HMA
C
Generates session keys for communication
between FCR-PRA-IS and FCR–TSM
FMT_MSA.1/ EFT-
POS LABEL INFO
Provides the functions to restrict the ability to
modify the security attribute(EFT-POS label) to
nobody
FMT_MSA.1/FILE
NAME and INFO-
LABEL
Provides the functions to restrict the ability to
modify the security attribute (file name) to
nobody
FMT_MSA.1/ IP:PORT
Provides the functions to restrict the ability to
modify the security attribute(IP/Port)to Authorised
Manufacturer User
FMT_MSA.1/EFTPOS
SOURCE PORT INFO
Provides the functions to restrict the ability to
modify the security attribute (EFT-POS source port)
to nobody
FMT_MSA.1/ INFO-
LABEL
Provides the functions to restrict the ability to
modify the security attribute (Main Unit
İnformation Label) to nobody
FMT_MSA.1/MAIN
UNIT SOURCE PORT
INFO
Provides the functions to restrict the ability to
modify the security attribute (Main Unit source
port) to nobody
FMT_MSA.3/USERS
and SYSTEMS
Provides the functions to provide restrictive default
values for security attributes that are used to
enforce the SFP and allows nobody to specify
alternative initial values to override the default
values when an object or information is created
FMT_MSA.3/EFTPOS
Provides the functions to provide permissive default
values for security attributes that are used to
enforce the SFP and allows nobody to specify
alternative initial values to override the default
values when an object or information is created
FMT_MSA.3/MAIN
UNIT
Provides the functions to provide permissive default
values for security attributes that are used to
enforce the SFP and allows nobody to specify
alternative initial values to override the default
values when an object or information is created
FCS_CKM.4 Destroys cryptographic keys in the TOE
FCS_COP.1/ENC-DEC
Provides the cryptographic operation for secure
communication between PRA-IS and new
generation cash register fiscal application software,
and between TSM and new generation cash register
fiscal application software
FCS_COP.1/INT-AUTH
Provides authentication and integrity protection for
communication between FCR-PRA-IS and FCR–TSM
FPT_PHP.2
Generation of audit event detection of physical
tampering
FCO_NRO.2
Generates evidence of origin of the data to be
transferred to the PRA-IS
FCS_CKM.1/ DHE-KEY Generates private key for DHE key agreement
FCS_COP.1/EXT-DEV
KENC
Provides symmetric encryption in order to establish
secure communication with External Devices.
FCS_COP.1/EXT-DEV
KHMAC
Provides authentication and integrity protection for
communication with External Devices.
FCS_CKM.1/ EXT-DEV
KENC
Generates keys for communication between TOE
and External Devices
FCS_CKM.1/ EXT-DEV
KHMAC
Generates keys for communication between TOE
and External Devices
FCS_COP.1/EXT-DEV
KEYEXCHANGE
Provides asymmetric agreement operation with
External Devices decryption for secure exchange of
the symmetric key with EFT-POS
FDP_ETC.2/TSM
Provides export of sales data and event data from
the TOE to the PRA-IS using the information flow
control SFP with TSM and PRA-IS
FDP_ETC.2/EFTPOS
Provides export of amount information in sales data
from the TOE to the EFT-POS using the information
flow control SFP with EFT-POS Devices
FDP_ETC.2/MAIN
UNIT
Provides export of amount information in sales data
from the TOE to the EFT-POS using the information
flow control SFP with EFT-POS Devices
FDP_IFC.1/TSMCOM
MUNICATION
Provides information flow control policy for TSM
and PRA-IS communication
FDP_IFC.1/EFTPOSCO
MMUNICATION
Provides information flow control policy for EFT-POS
communication
FDP_IFC.1/MAIN
UNIT
Provides information flow control policy for Main
Unit communication
FDP_IFF.1/TSMCOM
MUNICATION
Provides information flow control policy rules for
TSM and PRA-IS communication
FDP_IFF.1/EFTPOSCO
MMUNICATION
Provides information flow control policy rules for
EFT-POS communication
FDP_IFF.1/MAIN
UNIT
Provides information flow control policy rules for
Main Unit communication
FDT_ITC.2/TSM
Provides protection of FCR Parameters
confidentiality and integrity during import from
TSM
FDT_ITC.2/EFTPOS
Provides protection of confidentiality and integrity
of outcome of the operation conducted by the EFT-
POS device and 3DES key during import from EFT-
POS device
FDP_ITC.2/MAIN
UNIT
Provides protection of confidentiality and integrity
of 3DES key during import from Main Unit
FTP_ITC.1
Provides protection of sales data and event data
(confidentiality+integrity) during communication
with PRA-IS by the help of secure channel
6.3.2. Rationale for SFR’s Dependencies
Selected security functional requirements include related dependencies. Table 5 below provides a
summary of the security functional requirements dependency analysis.
Table 5 Security Functional Requirements dependencies
Component Dependencies Included / not included
FAU_GEN.1 FPT_STM.1 included
FAU_SAR.1 FAU_GEN.1 included
FAU_STG.1 FAU_GEN.1 included
FAU_STG.4 FAU_STG.1 included
FCO_NRO.2 FIA_UID.1 included
FCS_CKM.1/TLS_AES FCS_CKM.2 or FCS_COP.1;
FCS_CKM.4
FCS_COP.1/ENC-DEC and FCS_CKM.4
included
FCS_CKM.1/TLS_HMAC FCS_CKM.2 or FCS_COP.1;
FCS_CKM.4
FCS_COP.1/INT-AUTH and FCS_CKM.4
included
FCS_CKM.1/EXT-DEV KENC FCS_CKM.2 or FCS_COP.1;
FCS_CKM.4
FCS_COP.1/EXT-DEV KENC
FCS_CKM.4 included
FCS_CKM.1/EXT-DEV KHMAC FCS_CKM.2 or FCS_COP.1;
FCS_CKM.4
FCS_COP.1/EXT-DEV KHMAC
FCS_CKM.4 included
FCS_CKM.4 FDP_ITC.1 or FDP_ITC.2 or
FCS_CKM.1
FCS_CKM.1(FCS_CKM.1/ EXT-DEV KENC,
FCS_CKM.1/ EXT-DEV
KHMAC,
FCS_CKM.1/TLS_HMAC,
FCS_CKM.1/TLS_AES and
FCS_COP.1/ EXT-DEV
KEYEXCHANGE) included
FCS_COP.1/ENC-DEC FDP_ITC.1 or FDP_ITC.2 or
FCS_CKM.1; FCS_CKM.4
FCS_CKM.1/TLS_AES and FCS_CKM.4
included
FCS_COP.1/INT-AUTH FDP_ITC.1 or FDP_ITC.2 or
FCS_CKM.1; FCS_CKM.4
FCS_CKM.1/TLS_HMAC and
FCS_CKM.4 included
FCS_COP.1/HASHING FDP_ITC.1 or FDP_ITC.2 or
FCS_CKM.1; FCS_CKM.4
No need to include any dependencies
because there is no need to use any
key for HASHING
FCS_COP.1/DHE-KEY FDP_ITC.1 or FDP_ITC.2 or
FCS_CKM.1; FCS_CKM.4
FCS_COP.1/ EXT-DEV KEYEXCHANGE
and FCS_CKM.4 included.
FCS_COP.1/EXT-DEV KENC FDP_ITC.1 or FDP_ITC.2 or
FCS_CKM.1; FCS_CKM.4
FCS_CKM.1/ EXT-DEV KENC, FCS_CKM.4
included
FCS_COP.1/EXT-DEV KHMAC FDP_ITC.1 or FDP_ITC.2 or
FCS_CKM.1; FCS_CKM.4
FCS_CKM.1/ EXT-DEV KHMAC,
FCS_CKM.4 included
FCS_COP.1/ EXT-DEV
KEYEXCHANGE
FDP_ITC.1 or FDP_ITC.2 or
FCS_CKM.1; FCS_CKM.4
FCS_CKM.1/ DHE-KEY and FCS_CKM.4
included
FDP_ACC.1 FDP_ACF.1 included
FDP_ACF.1 FDP_ACC.1; FMT_MSA.3 FDP_ACC.1; FMT_MSA.3/USERS and
SYSTEMS included
FDP_ETC.2/TSM FDP_ACC.1 or FDP_IFC.1 FDP_ACC.1;
FDP_IFC.1/TSMCOMMUNICATION
included
FDP_ETC.2/EFTPOS FDP_ACC.1 or FDP_IFC.1 FDP_ACC.1;
FDP_IFC.1/EFTPOSCOMMUNICATION
included
FDP_ETC.2/MAIN UNIT FDP_ACC.1 or FDP_IFC.1 FDP_ACC.1; FDP_IFC.1/MAIN UNIT
FDP_IFC.1/TSMCOMMUNICATI
ON
FDP_IFF.1 FDP_IFF.1/TSMCOMMUNICATION
included
FDP_IFC.1/EFTPOSCOMMUNICA
TION
FDP_IFF.1 FDP_IFF.1/EFT-POSCOMMUNICATION
included
FDP_IFC.1/MAIN UNIT FDP_IFF.1 FDP_IFF.1/MAIN UNIT included
FDP_IFF.1/TSMCOMMUNICATIO
N
FDP_IFC.1;
FMT_MSA.3
FDP_IFC.1/TSMCOMMUNICATION;
FMT_MSA.3/USERS and SYSTEMS
included
FDP_IFF.1/EFT-
POSCOMMUNICATION
FDP_IFC.1; FMT_MSA.3 FDP_IFC.1/EFTPOSCOMMUNICATION;
FMT_MSA.3/EFTPOS included
FDP_IFF.1/MAIN UNIT FDP_IFC.1; FMT_MSA.3 FDP_IFC.1/MAIN UNIT;
FMT_MSA.3/MAIN UNIT
FDP_ITC.2/TSM FDP_ACC.1 or FDP_IFC.1 ;
FTP_ITC.1 or FTP_TRP.1 ;
FPT_TDC.1
FDP_IFC.1/TSMCOMMUNICATION;
FTP_ITC.1; FPT_TDC.1 included
FDP_ITC.2/EFTPOS FDP_ACC.1 or FDP_IFC.1 ;
FTP_ITC.1 or FTP_TRP.1 ;
FPT_TDC.1
FDP_IFC.1/EFTPOSCOMMUNICATION;
FTP_ITC.1; FPT_TDC.1 included
FDP_ITC.2/MAIN UNIT FDP_ACC.1 or FDP_IFC.1 ;
FTP_ITC.1 or FTP_TRP.1 ;
FPT_TDC.1
FDP_IFC.1/MAIN UNIT; FTP_ITC.1;
FPT_TDC.1 included
FDP_SDI.2/MEMORY No dependencies. -
FDP_SDI.2/DAILY and PRMTR No dependencies. -
FIA_AFL.1/MANUFACTURER FIA_UAU.1 included
FIA_AFL.1/AUTHORISED FIA_UAU.1 included
FIA_UAU.1 FIA_UID.1 included
FIA_UAU.4 No dependencies -
FIA_UID.1 No dependencies -
FMT_MOF.1 FMT_SMR.1; FMT_SMF.1 FMT_SMR.2 is hierarchical to
FMT_SMR.1;
FMT_SMF.1
FMT_MSA.1/USER IDENTITY FDP_ACC.1 or
FDP_IFC.1
FDP_ACC.1 included
FMT_MSA.1/PRIVILEGES FDP_ACC.1 or
FDP_IFC.1
FDP_ACC.1 included
FMT_MSA.1/ IP:PORT INFO FDP_ACC.1 or
FDP_IFC.1
FDP_IFC.1/TSMCOMMUNICATION
included
FMT_MSA.1/FILE NAME and
INFO-LABEL
FDP_ACC.1 or
FDP_IFC.1
FDP_IFC.1/TSMCOMMUNICATION
included
FMT_MSA.1/ INFO-LABEL FDP_ACC.1 or FDP_IFC.1 FDP_IFC.1/MAIN UNIT included
FMT_MSA.1/MAIN UNIT
SOURCE PORT INFO
FDP_ACC.1 or FDP_IFC.1 FDP_IFC.1/MAIN UNIT included
FMT_MSA.1/EFTPOS SOURCE
PORT INFO
FDP_ACC.1 or FDP_IFC.1 FDP_IFC.1/EFTPOSCOMMUNICATION
included
FMT_MSA.1/ EFT-POS LABEL
INFO
FDP_ACC.1 or FDP_IFC.1 FDP_IFC.1/EFTPOSCOMMUNICATION
included
FMT_MSA.3/USERS and
SYSTEMS
FMT_MSA.1; FMT_SMR.1 FMT_MSA.1
( FMT_MSA.1/USER IDENTITY,
FMT_MSA.1/PRIVILEGES,
FMT_MSA.1/IP:PORT INFO,
FMT_MSA.1/FILE NAME and INFO-
LABEL) ;
FMT_SMR.2 is hierarchical to
FMT_SMR.1 included
FMT_MSA.3/EFTPOS FMT_MSA.1 ;
FMT_SMR.1
FMT_MSA.1(FMT_MSA.1/ EFT-POS
LABEL INFO ) ;
FMT_SMR.2 is hierarchical to
FMT_SMR.1 included
FMT_MSA.3/MAIN UNIT FMT_MSA.1 ; FMT_SMR.1 FMT_MSA.1(FMT_MSA.1/ INFO-
LABEL,) ;
FMT_SMR.2 is hierarchical to
FMT_SMR.1 included
FMT_MTD.1/FCR AUTHORISED
USER
FMT_SMR.1 ;
FMT_SMF.1
FMT_SMR.2 is hierarchical to
FMT_SMR.1 ; FMT_SMF.1 included
FMT_MTD.1/AUTHORISED
MANUFACTURER USER
FMT_SMR.1 ;
FMT_SMF.1
FMT_SMR.2 is hierarchical to
FMT_SMR.1 ; FMT_SMF.1 included
FMT_SMF.1 No dependencies. -
FMT_SMR.2 FIA_UID.1 FIA_UID.2 is hierarchical to FIA_UID.1
included
FPT_FLS.1 No dependencies -
FPT_PHP.2 FMT_MOF.1 included
FPT_RCV.1 AGD_OPE.1 included (assurance component)
FPT_RCV.4 No dependencies -
FPT_STM.1 No dependencies -
FPT_TDC.1 No dependencies -
FPT_TEE.1/EXT No dependencies -
FPT_TEE.1/TIME No dependencies -
FPT_TST.1 No dependencies -
FTP_ITC.1 No dependencies -
6.3.3. Security Assurance Requirements Rationale
The current assurance package was chosen based on the pre-defined assurance packet EAL2. EAL2 is
chosen because the threats that were chosen are consistent with an attacker of basic attack potential.
6.3.4. Security Requirements – Internal Consistency
Set of security requirements for the TOE consisting of the security functional requirements (SFRs) and
the security assurance requirements (SARs) together forms an internally consistent whole.
The dependency analysis in section 6.3.2 Rationale for SFR’s Dependencies for the security functional
requirements shows that the basis for internal consistency between all defined functional
requirements is satisfied.
The assurance package EAL2 is a pre-defined set of internally consistent assurance requirements. The
dependency analysis for the sensitive assurance components in section 6.3.3 Security Assurance
Requirements Rationale shows that the assurance requirements are internally consistent, because all
(additional) dependencies are satisfied and no inconsistency appears.
Inconsistency between functional and assurance requirements could only arise, if there are functional-
assurance dependencies being not met – an opportunity having been shown not to arise in sections
6.3.2 Rationale for SFR’s Dependencies and 6.3.3 Security Assurance Requirements Rationale.
Furthermore, as also discussed in section 6.3.3 Security Assurance Requirements Rationale, the
chosen assurance components are adequate for the functionality of the TOE. So, there are no
inconsistencies between the goals of these two groups of security requirements
7. TOE SUMMARY SPECIFICATION
7.1. TOE Security Functions
The TOE security functions are briefly described below.
Access Control: TOE controls user (FCR Authorised User, Authorised Manufacturer User) access to
functions and data by following subjects,
 Sales data
 Event data
 Exchange rates
 Authentication Data
 Time information
Accuracy: TOE ensures that processing of inputs to derive sales data and event data is accurate. TOE
security functionality cannot be changed by any user. Sales data and event data is processed only if
FCR is used by authorised user.
If TOE enters in maintenance mode, it can be switched to the secure state manually. If any situation
except following, it can be switched to the secure state automatically.
 FCR Certificate check fails,
 Mesh cover monitoring check fails,
 A disconnection between fiscal memory and main processor occurs,
 Electronic seal is opened, or forced by unauthorised persons
 NCR E10 Application integrity error occurs,
 Event log data and sales data integrity error occurs,
 The state of unable to write to fiscal memory, daily memory and ERU
 First initialisation phase fails
Authentication: TOE authenticates FRC Authorised User by controlling username and password match.
If FCR Authorised User enters wrong password for defined amount, TOE does not accept its
authentication attempt and it warns the user make user wait for a new authentication attempt for
defined time period.
TOE authenticates Authorised Manufacturer User by challenge response authentication mechanism.
TOE generates a randomized challenge code to Authorised Manufacturer user for authentication.
Authorised Manufacturer User uses this code information to generate the response code. If user
enters the required response code then TOE authenticates authorised manufacturer user.
Event Recording: TOE records important events stated as in PRA Messaging Protocol document [6]
and start-up shutdown actions with reliable time stamps. All events contains following information
date and time of the event, type of event, subject identity, and the outcome (success or failure) of the
event.
For reliable time information TOE uses Trusted Server to synchronise its time with trusted server
meanwhile every Z report sending actions.
Integrity: TOE provides integrity for sales data and event data while storing these data and for the
daily memory stored data integrity is controlled. TOE has limited capacity for audit records. When limit
is reached TOE overwrite the oldest stored audit records.
If any integrity error occurs in sales data stored in fiscal memory and ERU, event data, authentication
data and characterization data, TOE generates an audit event and send this event to PRA-IS according
to PRA messaging protocol [6] then TOE blocks FCR and enters maintenance node for critical events .
If any integrity error occurs in sales data stored in daily memory and FCR Parameters TOE generates
an audit event and send this event to PRA-IS according to PRA messaging protocol [6] then TOE prints
Z report automatically.
Secure Transfer: TOE communicates external systems TSM, PRA-IS and external device Main Unit and
EFT-POS Device securely. For secure communication with these entities TOE uses well known
cryptographic algorithms such as TLS, AES and RSA. TOE uses TLS and AES algorithms for
communication with TSM and PRA-IS and TOE uses DHE for AES key agreement with Main Unit and
EFT-POS and also it uses AES to communicate securely with Main Unit and EFT-POS.
7.2. Assurance Measure
The section providing a general mapping from the documentation or evidence the developer intends
to provide to the appropriate assurance measures is not available in the public version of the
document.
7.3. TOE Summary Specification Rational
7.3.1. Security Functions Rational
Table 6 Security Functions Rationale
Access
Control
Accuracy
Authentication
Event
Recording
Integrity
Secure
Transfer
FAU_GEN.1 Audit data generation X
FAU_SAR.1 Audit review X
FAU_STG.1 Protected audit trail storage X
FAU_STG.4 Prevention of audit data loss X
FCO_NRO.2 Enforced proof of origin X
FCS_CKM.1/TLS_AES Cryptographic key generation X
FCS_CKM.1/TLS_HMAC Cryptographic key generation X
FCS_CKM.1/ DHE-KEY Cryptographic key generation X
FCS_CKM.1/ EXT-DEV KENC Cryptographic key generation X
FCS_CKM.1/ EXT-DEV KHMAC Cryptographic key generation X
FCS_CKM.4 Cryptographic key destruction X
Access
Control
Accuracy
Authentication
Event
Recording
Integrity
Secure
Transfer
FCS_COP.1/ ENC-DEC Cryptographic operation X
FCS_COP.1/INT-AUTH Cryptographic operation X
FCS_COP.1/ EXT-DEV KENC Cryptographic operation X
FCS_COP.1/ EXT-DEV KHMAC Cryptographic operation X
FCS_COP.1/HASHING Cryptographic operation X
FCS_COP.1/EXT-DEV
KEYEXCHANGE
Cryptographic operation X
FDP_ACC.1 Subset access control X
FDP_ACF.1 Security attribute based access control X
FDP_ETC.2/TSM Export of user data with security attributes X
FDP_ETC.2/EFTPOS Export of user data with security attributes X
FDP_ETC.2/MAIN UNIT Export of user data with security attributes X
FDP_IFC.1/TSMCOMMUNICA
TION
Subset information flow control X
FDP_IFC.1/EFTPOSCOMMUNI
CATION
Subset information flow control X
FDP_IFC.1/MAIN UNIT Subset information flow control X
FDP_IFF.1/TSMCOMMUNICA
TION
Simple security attributes X
FDP_IFF.1/EFT-
POSCOMMUNICATION
Simple security attributes X
FDP_IFF.1/MAIN UNIT Simple security attributes X
FDP_ITC.2/TSM Import of user data with security attributes X
FDP_ITC.2/EFTPOS Import of user data with security attributes X
FDP_ITC.2/MAIN UNIT Import of user data with security attributes X
FDP_SDI.2 /MEMORY Stored data integrity monitoring and action X
FDP_SDI.2/DAILY and PRMTR Stored data integrity monitoring and action X
FIA_AFL.1/MANUFACTURER Authentication failure handling X
FIA_AFL.1/AUTHORISED Authentication failure handling X
FIA_UAU.1 Timing of authentication X
FIA_UAU.4 Single-use authentication mechanisms X
FIA_UID.1 Timing of identification X
FMT_MOF.1 Management of security functions behaviour X X
Access
Control
Accuracy
Authentication
Event
Recording
Integrity
Secure
Transfer
FMT_MSA.1/USER IDENTITY Management of security attributes X
FMT_MSA.1/PRIVILEGES Management of security attributes X
FMT_MSA.1/IP:PORT INFO Management of security attributes X X
FMT_MSA.1/FILE NAME and
INFO-LABEL
Management of security attributes X
FMT_MSA.1/INFO-LABEL Management of security attributes X
FMT_MSA.1/EFTPOS SOURCE
PORT INFO
Management of security attributes X
FMT_MSA.1/ MAIN UNIT
SOURCE PORT INFO
Management of security attributes X
FMT_MSA.1/EFT-POS LABEL
INFO
Management of security attributes X
FMT_MSA.3/USERS and
SYSTEMS
Static attribute initialisation X X
FMT_MSA.3/EFTPOS Static attribute initialisation X
FMT_MSA.3/MAIN UNIT Static attribute initialisation X
FMT_MTD.1/FCR
AUTHORISED USER
Management of TSF data X X
FMT_MTD.1/ AUTHORISED
MANUFACTURER USER
Management of TSF data X
FMT_SMF.1 Specification of Management Functions X
FMT_SMR.2 Restrictions on security roles X
FPT_FLS.1 Failure with preservation of secure state X
FPT_PHP.2 Notification of physical attack X X
FPT_RCV.1 Manual recovery X
FPT_RCV.4 Function recovery X
FPT_STM.1 Reliable time stamps X
FPT_TDC.1 Inter-TSF basic TSF data consistency X
FPT_TEE.1/EXT Testing of external entities X
FPT_TEE.1/TIME Testing of external entities X
FPT_TST TSF self Test X X
FTP_ITC Inter-TSF trusted channel X
7.3.2. Assurance Measures Rational
The assurance measures of the developer as referred in section 7.2 are suitable and sufficient to
meet the CC assurance level EAL2 as claimed in section 6.2. In particular, the deliverables listed in
chapter 7.2 are suitable and sufficient to document that the assurance requirements are met.
8. ACRONYMS
AES : Advanced Encryption Standard
CC : Common Criteria
CCMB : Common Criteria Management Board
DEMA : Differential Electromagnetic Analysis
DES : Data Encryption Standard
DFA : Differential Fault Analysis
DPA : Differential Power Analysis
EAL : Evaluation Assurance Level (defined in CC)
EFTPOS : Electronic Funds Transfer at Point of Sale
EMV : Europay, MasterCard and Visa
ERU : Electronic Recording Unit
FCR : Fiscal Cash Register
GPRS : General Packet Radio Service
GPS : Global Positioning System
IT : Information Technology
ITU : International Telecommunication Union
OSP : Organisational Security Policy
PP : Protection Profile
PKI : Public Key Infrastructure
PRA : Presidency of Revenue Administration
PRA-IS : Presidency of Revenue Administration Information Systems
SAR : Security Assurance Requirements
SEMA : Simple Electromagnetic Analysis
SFR : Security Functional Requirements
SHA : Secure Hash Algorithm
SPA : Simple Power Analysis
SSL - CA : Secure Sockets Layer - Client Authentication
TOE : Target of Evaluation
TLS 1.2 : Transport Layer Security version 1.2
TSF : TOE Security Functionality (defined in CC)
TSE : Turkish Standards Institute
TSM : Trusted Service Manager
VAT : Value Added Tax
9. BIBLIOGRAPHY
Common Criteria
[1] Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and General
Model; CCMB-2012-09-001, Version 3.1, Revision 4, September 2012
[2] Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional
Components; CCMB-2012-09-002, Version 3.1, Revision 4, September 2012
[3] Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance
Requirements; CCMB-2012-09-003, Version 3.1, Revision 4, September 2012
[4] Common Methodology for Information Technology Security Evaluation, Evaluation Methodology;
CCMB-2012-09-004, Version 3.1, Revision 4, September 2012
New Generation Cash Register Directives
[5] Technical Guidance Document, version 2.0 , March 2013
[6] PRA Messaging Protocol Document, version 2.02 , April 2013
[7] COMMON CRITERIA PROTECTION PROFILE for NEW GENERATION CASH REGISTER FISCAL
APPLICATION SOFTWARE (NGCRFAS PP), TSE-CCCS/PP-006, version 1.8, 18 December 2014
[8] External Device Communication Protocol (GMP3), Revision 1.0, January 2015