Common Criteria Protection
Profile
Electronic Health Card Terminal
(eHCT)
BSI-CC-PP-0032-V2-2015
Federal Office for Information Security
Postfach 20 03 63
D-53133 Bonn
Phone: +49 22899 9582-0
E-Mail: bsi@bsi.bund.de
Internet: https://www.bsi.bund.de
© Bundesamt für Sicherheit in der Informationstechnik 2015
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 3 of 74
Foreword
This ‘Protection Profile - Protection Profile – electronic Health Card Terminal - is issued by
Bundesamt für Sicherheit in der Informationstechnik, Germany.
The document has been prepared as a Protection Profile (PP) following the rules and formats
of Common Criteria version 3.1 [1], [2], [3].
Correspondence and comments to this Protection Profile should be referred to:
CONTACT ADDRESS
Bundesamt für Sicherheit in der Informationstechnik
Godesberger Allee 185-189
D-53175 Bonn, Germany
Phone +49 228 9582-0
Fax +49 228 9582-400
Email bsi@bsi.bund.de
Table of Content
Page 4 of 74 Federal Office for Information Security
Change history
Version Date Reason Remarks
3.4 10th
December 2014 Clarifications and corrections after feedback
from stakeholder comments
3.5 16th
January 2015 Minor changes
3.5.1 24th
June 2015 Editorial changes due to certification comments
3.5.2 20th
August 2015 Further editorial changes due to cert-comments
3.5.3 25th
August 2015 Further editorial changes due to cert-comments
3.6 10th
September 2015 Certified version for publication
Last Version: (3.6., 10th September 2015)
Name Value Display
File name and sizes Set automatically PP_0032-V2_v3_6.doc
Last Version 3.6. 3.6.
Date 10th September 2015 10th
September 2015
Classification Unclassified Unclassified
Table of Content
Federal Office for Information Security Page 5 of 74
Table of Content
1 PP Introduction 7
1.1 PP reference 7
1.2 PP Overview 7
1.2.1 TOE definition and operational usage 7
1.2.2 TOE major security features for operational use 9
1.2.3 TOE Type 10
1.2.4 Required non-TOE hardware/software/firmware 12
2 Conformance Claim 13
2.1 PP Claim 13
2.2 Package Claim 13
2.3 Conformance Claim Rationale 13
2.4 Conformance statement 13
3 Security Problem Definition 14
3.1 Assets 14
3.2 Subjects 15
3.3 Threats 16
3.4 Organizational Security Policies 17
3.5 Assumptions 18
4 Security Objectives 21
4.1 Security Objectives for the TOE 21
4.2 Security Objectives for the Operational Environment 25
4.3 Security Objectives Rationale 27
4.3.1 Countering the Threats 27
4.3.2 Covering the OSPs 29
4.3.3 Covering the Assumptions 29
5 Extended Components Definition 30
6 Security Requirements 31
6.1 Security Functional Requirements for the TOE 31
6.1.1 Cryptographic Support (FCS) 33
6.1.2 User data protection (FDP) 37
6.1.3 Identification and Authentication (FIA) 48
6.1.4 Security Management (FMT) 52
6.1.5 Protection of the TSF (FPT) 57
6.1.6 TOE Access (FTA) 59
6.1.7 Trusted path/channels (FTP) 59
6.2 Security Assurance Requirements for the TOE 61
Table of Content
Page 6 of 74 Federal Office for Information Security
6.3 Security Requirements Rationale 62
6.3.1 Security Functional Requirements Rationale 62
6.3.2 SFR Dependency Rationale 65
6.3.3 Security Assurance Requirements Rationale 69
6.3.4 Security Requirements – Mutual Support and Internal Consistency 69
6.4 Extended Functionality 69
7 Glossary and Acronyms 71
8 Literature 72
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 7 of 74
1 PP Introduction
1.1 PP reference
Title: Protection Profile – Electronic Health Card Terminal (eHCT)
Sponsor: Bundesamt für Sicherheit in der Informationstechnik (BSI)
Editor(s): TÜV Informationstechnik GmbH et al.
CC Version: 3.1
Assurance Level: The assurance level for this PP is EAL 3 augmented by ADV_FSP.4,
ADV_IMP.1, ADV_TDS.3, ALC_TAT.1 and AVA_VAN.5.
General Status: final
Version Number: 3.6.
Date: 10th September 2015
Registration: BSI-CC-PP-0032-V2-2105
Keywords: Protection Profile, Electronic health card terminal
1.2 PP Overview
This protection profile defines the security objectives and requirements for the Electronic
Health Card Terminal based on the regulations for the German healthcare system. It
addresses the security services provided by this terminal, mainly:
The access to one or more slots for smart cards,
Secure network connectivity,
Secure PIN entry functionality,
Encryption of communication,
User authentication,
Management functionality including update and downgrade of Firmware, and
Passive physical protection.
1.2.1 TOE definition and operational usage
The Target of Evaluation (TOE) described in this Protection Profile is a smart card terminal
which fulfils the requirements to be used with the German electronic Health Card (eHC) and
the German Health Professional Card (HPC) based on the regulations of the German
healthcare system. Please refer to [19] for further information about card compatibility.
The TOE fulfils the requirements to be used as a secure PIN pad entry device for applications
according to [6] and [7], which specifically means that a PIN, which has been entered by a
user at the TOE, never leaves the TOE in clear text, except to smart cards in local card slots.
For the case that a terminal implements an insecure mode (e.g. a mode, in which it cannot be
guaranteed that the PIN will not leave the TOE or a mode in which not trustworthy entities are
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 8 of 74 Federal Office for Information Security
allowed to communicate with the TOE) the TOE is able to inform the user whether it is
currently in a secure state or not.
This terminal bases on the specification for a “Secure Interoperable ChipCard terminal” ([20])
extended and limited by the specifications for the e-health terminal itself (see [19]).
In its core functionality the TOE is not different from any other smart card terminal which
provides an interface to one or more smart cards including a mean to securely enter a PIN.
Additionally the TOE provides a network interface which allows routing the communication
of a smart card to a remote IT product outside the TOE.
The TOE provides the following main functions:
Access to one or more slots for smart cards,
Secure network connectivity,
Secure PIN entry functionality,
Enforcement of the encryption of communication,
User authentication,
Management functionality including update and downgrade of Firmware, and
Passive physical protection.
The TOE for use in the German health care is based on the specification SICCT, which is
adapted for operation by profiling as eHealth card terminal (see [20]).
The derivatives of the physical characteristics of each card terminal types are presented in
Figure 1 which is based on the architecture of the model specification SICCT [20].
A PIN pad and a display are mandatory for the TOE (see [20]). Also required are at least one
ID-1 and one ID-000 contact unit.
The TOE must work with a cryptographic key for i.e. authentication, integrity assurance and
to ensure the confidentiality of data transmitted over the LAN interface. Due to the very high
protection requirements of the information objects transmitted over the LAN interface, a
secure key store (SM-KT) is required for the key. As physical characteristics of the SM-KT
the TOE has to support gSMC-KT cards. IPv4 has to be supported mandatory. To ensure the
sustainability of the TOE, it should be able to support IPv6 in addition to IPv4 only with a
firmware update1.
In its environment, the TOE communicates with a so called connector. This connector is the
secure connection between the local network of the medical supplier and the remote network
of the telematic infrastructure. It provides the medical supplier with secure access to the
services of the telematic infrastructure.
For the connection of the TOE to a connector via the LAN interface, the protocol with the
SICCT commands is mandatory. The interfaces of the TOE and communication partners
using them are provided in Figure 1.
1Please note that firmware update could also mean a firmware downgrade. Both actions are possible. The
developer of the TOE shall ensure that in case of a downgrade of the firmware the TOE must warn the
Administrator (e.g. within the Guidance) before the installation that the action to be performed is not an
upgrade. The TOE must offer a chance to cancel the installation.
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 9 of 74
1.2.2 TOE major security features for operational use
To protect the communication between the connector and the TOE the TOE has to possess a
cryptographic identity (in form of a X.509 certificate) and functionality for
encryption/decryption as well as signature creation based on RSA (see also [19]).
For its cryptographic functionality the TOE relies on the services of the so called SM-KT2.
The SM-KT (Secure Module Kartenterminal) is a secure module that represents the
cryptographic identity of the TOE in form of a X.509 certificate.
This module - in form of an ID-000 smart card - provides:
Protection of the private key,
Cryptographic functions based on RSA for encryption/decryption and signature
creation,
A random number generator, and
A function to read out the public key
Though this SM-KT will usually be physically within the cage of the TOE it does not belong
to the logical and physical scope of the TOE as to see in Figure 1. More information about the
SM-KT can be found in the Protection Profile Card Operating System 2 (PP COS G2) [17]
and the gematik specification on the gSMC-KT object system [21].
For the case the TOE uses a DF.KT of a gSMC-KT as SM-KT, which is addressable via the
connector, the TOE shall access this DF.KT via the base-channel 0. During use of the SM-KT
by the TOE the terminal card commands of the TOE have to be priorized and the processing
of possibly existing client SICCT commands have to be interrupted and continued only after
completion of the internal command sequence. The connector has to make sure that a DF.KT
of a gSMC-KT as SM-KT which is addressable via the connector shall only be accessed by
the TOE and not be used by any other system than the TOE.
The TOE provides functionality to update and downgrade its firmware. This includes both the
change to a newer firmware as a downgrade to a firmware which is approved with the concept
of firmware-group. The configuration, such as terminal type, IP address or pairing-
information shall be preserved and indicated after a firmware update or a downgrade (see [19]
for further information). The developer of the TOE shall ensure that in case of a downgrade of
the firmware of the TOE the Administrator shall be warned (e.g. within the Guidance) before
the installation that the action to be performed is not an upgrade. The TOE must offer a
chance to cancel the installation. The developer- specific update component shall warn the
administrator about taking the responsibility in case of performing a downgrade.
Firmware update can also be triggered remotely from a trusted Push Server in the internal
network of the medical supplier. The TOE allows initiating batch signatures for the creation
of more than one signature at a time without providing the PIN for each signature process.
Batch signature is a functionality of the signing card.
In addition to the cryptographic identity of the TOE, the TOE stores a shared secret which is
generated by the connector and transferred to the TOE during the pairing process of TOE and
2 Please note that the SM-KT is only responsible for the core functions of the asymmetric cryptography (RSA)
and for random number generation. The TOE will be responsible for negotiating the session with the connector
and for encryption/decryption using a symmetric AES key. More details can be found in [19] and the following
chapters.
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 10 of 74 Federal Office for Information Security
connector. This shared secret is not stored in the SM-KT, but in a separate storage area of the
TOE. As the SM-KT might be removed and placed into another card terminal, the shared
secret is necessary to ensure that communication to the connector is performed using the
already paired card terminal (the TOE). The whole identity of the TOE is therefore
represented by the SM-KT certificate AND the shared secret. Please note that as part of the
pairing process, there are three processes:
Initial pairing:
This provides a logical connection from the perspective of the connector by using
shared secret between card terminal and SM-KT
Review of pairing- information:
The connector checks as a second step of authentication, if the card terminal is in the
possession of the shared secret after establishing the TLS connection.
Maintenance-pairing:
Announcement of a new connector certificate on the card terminal by using a known
shared secret. Please see [19] for further information on the pairing process.
The TOE is also able to send/receive a PIN to/from a remote card terminal. This
communication is routed via the connector. The connector never sees the PIN in clear text, as
the authorized cards (SMC-B, HPC) in the local and the remote card terminal are used to
encrypt/decrypt the PIN.
1.2.3 TOE Type
The TOE is an Electronic Health Card Terminal based on the regulations for the German
healthcare system. It is a smart card terminal with secure PIN entry functionality and fulfils
the requirements for the use within the German telematics infrastructure. Further the TOE is
compliant with the requirements of the German Digital Signature Act concerning the secure
PIN entry for applications.
In case of a stand-alone card terminal the physical scope of the TOE comprises
The hardware and sealed cage of the smart card terminal,
The firmware of the smart card terminal and
The related guidance documents
Please note that though – depending on a concrete realization – the SM-KT may be physically
within the cage of the terminal this module does not belong into the scope of the TOE as
described in this PP.
One or more seals are attached to the cage of the terminal allowing the user of the TOE to
detect whether the TOE has been tampered with. The description on how to check the sealing
shall be part of the TOE guidance documentation.
Further note, that the SM-KT is a necessary requirement in the operational environment of the
TOE. During the delivery and setup phase the SM-KT may have to be installed into the card
terminal. Functionality that is relying on the SM-KT for secure operation may not work as
intended before the SM-KT is installed. Therefore, the developer shall describe - as part of the
evidence for assurance requirements in ALC_DEL - how such functionality can be securely
used. An example for this would be a remote management function that relies on the secure
random number generator of the SM-KT. During setup the TOE administrator might want to
use the remote management interface. However, in this case the developer would have to
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 11 of 74
describe how the environment (or additional TOE mechanism) ensures that the connection
between the management client and the TOE is secured.
The logical scope of the TOE is represented by its core security features:
Access to one or more slots for smart cards,
Secure network connectivity,
Secure PIN entry functionality,
Enforcement of the encryption of communication,
User authentication,
Management including update of Firmware, and
Passive physical protection.
And is limited by the functionality for which the TOE relies on the services of the SM-KT,
which is not part of the TOE.
Figure 1: TOE architecture (logical perspective)
According to [19] compliance with this PP does only represent a part of the registration
process for an Electronic Health Card Terminal. Additionally [19] requires:
That the terminal has to be compliant to the requirements in [19] and [20] and
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 12 of 74 Federal Office for Information Security
That the terminal has to undergo a registration process of the gematik.
It should be mentioned that according to [19] it would be allowed that a terminal, claiming
compliance to this PP, implements more functionality than defined in this PP and that a
terminal temporarily operates in an insecure state. In such a state parts of the security
functionality as required by this PP may not be available. However for these cases the
terminal has to indicate to the user, whether it is currently working in a secure state or not.
1.2.4 Required non-TOE hardware/software/firmware
The TOE is intended to be used as a smart card terminal which fulfils the requirements to be
used with the German electronic Health Card (eHC) and the German Health Professional Card
(HPC) based on the regulations of the German healthcare system.
The following non-TOE hardware is required for the use the TOE:
An ID-000 smart card as a secure module representing the cryptographic identity of
the TOE in form of an X.509 certificate. The secure module can be a DF.KT of a
gSMC-KT as SM-KT. Although this secure module is usually physically placed
within the cage of the TOE it does not belong to the logical and physical scope of the
TOE.
A connector as a secure connection between the local network of the medical supplier
and the remote network of the telematic infrastructure. The connector further observes
the TOE and is the only entity which can interact with a DF.KT of a gSMC-KT as
SM-KT as mentioned above.
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 13 of 74
2 Conformance Claim
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
Common Criteria for Information Technology Security Evaluation, Part 2:
Security functional components; CCMB-2012-09-002, Version 3.1, Revision 4,
September 2012
Common Criteria for Information Technology Security Evaluation, Part 3:
Security assurance components; CCMB-2012-09-003, Version 3.1, Revision 4,
September 2012
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
has to be taken into account.
2.1 PP Claim
This PP does not claim any conformance to further Protection Profiles.
2.2 Package Claim
The current PP is conformant to the following security requirements package:
Assurance package EAL3 augmented by ADV_FSP.4, ADV_IMP.1, ADV_TDS.3,
ALC_TAT.1 and AVA_VAN.5.
2.3 Conformance Claim Rationale
The current Protection Profile does not claim any conformance with other PPs.
Therefore, no conformance claim rationale needs to be given here.
2.4 Conformance statement
This PP requires strict conformance of any ST or PP claiming conformance to this PP.
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 14 of 74 Federal Office for Information Security
3 Security Problem Definition
This chapter describes
the assets that need to be protected by the TOE,
the subjects that are interacting with the TOE,
the threats that have to be countered by the TOE,
the organizational security policy that TOE shall comply with, and
the assumptions that need to be ensured for the environment of the TOE.
3.1 Assets
The following assets need to be protected by the TOE as long as they are in the scope of the
TOE:
Asset Description
Card PIN (short PIN) The TOE interacts with the user to acquire a PIN and sends this PIN
to one of the cards in a slot of the TOE. The TOE has to ensure the
confidentiality of the PIN. For remote-PIN verification the TOE
sends/receives the PIN to/from another card terminal via the
connector. This asset is user data.
Management
credentials
The TOE stores credentials (e.g. passwords) to authenticate TOE
administrators for management activities. The TOE has to ensure the
confidentiality and integrity of these credentials. This asset is user
data.
Shared secret The TOE stores a shared secret which is generated by the connector
during the initial pairing process. The shared secret and the SM-KT
represent the identity of the card terminal. This identity is used for
secure identification and authentication of the card terminal by the
connector. The TOE has to ensure the confidentiality and integrity of
the shared secret. This asset is TSF data.
Patient Data This data comprises health information and billing data that is related
to patients. The TOE gets patient data from the cards in its slots,
encrypts this data and sends it to the connector. Further the TOE
accepts patient data from the connector, decrypts it, and sends it to the
corresponding eHC in its slot. The TOE has to ensure the
confidentiality and authenticity of this data. This asset is user data.
Communication data Confidential data that is transmitted between the TOE and the
connector. This data comprises at least patient data and PINs for
remote-PIN verification. The TOE has to ensure the confidentiality
and authenticity of this data. This asset is user data. Further data may
be identified by the ST author.
Configuration data Data on which the TOE relies on for its secure operation. This data
comprises at least the management credentials for local and remote
management and the list of TSP CAs. The TOE has to ensure the
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 15 of 74
integrity, confidentiality, and authenticity of the management
credentials. It has to ensure integrity and authenticity of the list of TSP
CAs. This asset is user data. Further data may be identified by the ST
author.
TSF Data The TOE stores TSF data which is necessary for its own operation.
The TOE has to ensure the confidentiality and authenticity of this
data. This asset is TSF data. Additional TSF data may be specified by
the ST author.
Table 1: Assets
3.2 Subjects
The following subjects are interacting with the TOE:
Subject Description
TOE Administrator The TOE administrator is in charge of managing the security
functions of the TOE.
Attacker A human, or a process acting on his behalf, located outside the TOE.
The main goal of the attacker is to access or modify application
sensitive information. The attacker has a high level attack potential.
Authorized card Authorized cards (HPC, SMC-B) are able to perform card-to-card
authentication which is used for remote-PIN verification.
Card The TOE is handling the communication for one or more smart cards
in its card slots.
Connector The connector is the only entity in the environment of the TOE
(except for users of the management interface) which is foreseen to
communicate with the TOE. It is the interface for the TOE to secure
communicate with the telematic infrastructure of the German
healthcare system.
Medical supplier The medical supplier (e.g. a physician) uses the TOE together with his
HPC (or SMC-B). With the HPC it is also possible for medical
suppliers to generate qualified digital signatures. Other than the
patient the medical supplier can be held responsible for the secure
operation of the TOE.
Patient The patient uses the TOE together with his eHC. The patient uses the
TOE for other services of the eHC. A patient will never use the
services of the TOE alone but will always be guided by the medical
supplier.
Push Server The Push Server is a trusted entity in the internal network of the
medical supplier which updates firmware on card terminals that are
connected to that network. The Push Server uses the SICCT interface
or another network interface of the card terminal for remote update.
See A.PUSH_SERVER for assumptions on the Push Server.
SM-KT The SM-KT represents the cryptographic identity of the TOE. It is a
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 16 of 74 Federal Office for Information Security
Subject Description
secure module that carries a X509 certificate and provides :
Protection of the private key
Cryptographic functions based on RSA for
encryption/decryption and signature creation
A random number generator
A function to read out the public key
TOE Reset
Administrator
The TOE Reset Administrator is the only user role that is able to
perform a reset of the TOE settings when management credentials are
lost. The type of authentication for this role depends on the particular
implementation. The TOE Reset Administrator could be the developer
himself.
User A user is communicating with the TOE in order to use its primary
services, i.e. to access a smart card which has been put into one of the
slots of the TOE before. The TOE is used by different kinds of users
including medical suppliers, patients and administrators.
Table 2: Subjects
3.3 Threats
This chapter describes the threats that have to be countered by the TOE.
The attack potential of the attacker behind those threats is in general characterized in terms of
their motivation, expertise and the available resources.
As the TOE handles and stores information with a very high need for protection with respect
to their authenticity, integrity and confidentiality it has to be assumed that an attacker will
have a high motivation for their attacks.
Further it has to be assumed that an attacker has deep knowledge over the internals of the
TOE and nearly unlimited resources to perform their attacks. In this way the possibilities for
an attacker are only limited by the characteristics of the environment (specifically addressed
by A.ENV).
Summarizing this means that an attacker with a high attack potential has to be assumed.
The assets that are threatened and the paths for each threat are defined in the following table:
Threat Description
T.COM An attacker may try to intercept the communication between the TOE
and the connector in order to gain knowledge about communication
data which is transmitted between the TOE and the connector or in
order to manipulate this communication. As part of this threat an
authorized user, who is communicating with the TOE (via a
connector) could try to influence communications of other users with
the TOE in order to manipulate this communication or to gain
knowledge about the transmitted data.
T.PIN An attacker may try to release the PIN which has been entered by a
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 17 of 74
user from the TOE in clear text. As part of this attack the attacker
may try to route a PIN, which has been entered by a user, to a wrong
card slot.
T.DATA An attacker may try to release or modify protected data from the
TOE.
This data may comprise:
Configuration data the TOE relies on for its secure operation
The shared secret of TOE and connector
Communication data that is received from a card and stored
within the terminal before it is submitted to the connector
An attack path for this threat cannot be limited to any specific
scenario but includes any scenario that is possible in the assumed
environment of the TOE.
Specifically an attacker may
use any interface that is provided by the TOE
physically probe or manipulate the TOE
T.F-CONNECTOR Unauthorized personnel may try to initiate a pairing process with a
fake connector after an unauthorized reset to factory defaults, e.g. to
initiate an unauthorized firmware update or to receive confidential
(patient) data .
Table 3: Threats
3.4 Organizational Security Policies
The TOE shall be implemented according to the following specifications:
Policy Description
OSP.SIGG The TOE shall fulfil the requirements to be used as a secure PIN pad
entry device for applications according to [6] and [7].
This specifically means that a PIN, which has been entered by a user
at the TOE, must never leave the TOE in clear text, except to smart
cards in local card slots.
For the case that a terminal implements an insecure mode (e.g. a
mode, in which it cannot be guaranteed that the PIN will not leave the
TOE or a mode in which not trustworthy entities are allowed to
communicate with the TOE) the TOE has to be able to inform the
medical supplier whether it is currently in a secure state or not.
Table 4: Organisational Security Policies
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 18 of 74 Federal Office for Information Security
3.5 Assumptions
The following assumptions need to be made about the environment of the TOE to allow the
secure operation of the TOE.
Assumption Description
A.ENV It is assumed that the TOE is used in a controlled environment.
Specifically it is assumed:
The card terminal prevents (not visible) physical
manipulations for at least 30 minutes. The environment
ensures beyond these 30 minutes that the card terminal is
protected against unauthorized physical access or such is
perceptible,
That the user handles his PIN with care; specifically that the
user will keep their PIN secret,
That the user can enter the PIN in a way that nobody else can
read it,
That the user only enters the card PIN when the TOE
indicates a secure state,
That the medical supplier checks the sealing and the physical
integrity of the TOE regularly before it is used,
That the network of the medical supplier is appropriately
secured so that it cannot be accessed by unauthorized
entities.
A.ADMIN The administrator of the TOE and the medical supplier shall be non-
hostile, well trained and have to know the existing guidance
documentation of the TOE.
The administrator and the medical supplier shall be responsible for
the secure operation of the TOE. Specifically it shall be ensured:
That they enforce the requirements on the environment (see
A.ENV),
That the administrator ensures that the medical supplier
received the necessary guidance documents (especially for
firmware updates),
That the physical examination of the TOE is performed
according to the process described by the manufacturer in the
evaluation process (e.g. seal checking),
That the administrator checks the integrity of the terminal
before the initial start-up procedure (every new pairing
process) and the medical supplier checks the integrity of the
terminal before every start-up procedure,
That they react to breaches of environmental requirements
according to the process described by the manufacturer in the
evaluation process (e.g. reshipment to the manufacturer).
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 19 of 74
Assumption Description
A.CONNECTOR The connector in the environment is assumed to be trustworthy and
provides the possibility to establish a Trusted Channel with the TOE
including a mean for a mutual authentication. It is assumed that the
connector has undergone an evaluation and certification process in
compliance with the corresponding Protection Profiles [18]. Further
it is assumed that for the case the TOE uses a DF.KT of a gSMC-KT
as SM-KT which are addressable via the connector, the TOE
accesses this DF.KT via the base-channel 0. During use of the SM-
KT by the TOE the terminal card commands of the TOE have to be
given precedence and the processing of possibly existing client
SICCT commands have to be interrupted and continued only after
completion of the internal command sequence. The developer may
queue the interrupts internally or implement error messages as
answers to the commands.
It is also assumed that the connector makes sure that a DF.KT of a
gSMC-KT as SM-KT which is addressable via the connector can
only be accessed by the TOE and not be used by any other system
than the TOE.
Further, it is assumed that the connector periodically monitors the
pairing state with the TOE and provides warning mechanisms to
indicate unexpected results like paired terminals which lack the
shared secret..
A.SM The TOE will use a secure module (SM-KT) that represents the
cryptographic identity of the TOE in form of an X.509 certificate.
It is assumed that the cryptographic keys in this module are of
sufficient quality and the process of key generation and certificate
generation is appropriately secured to ensure the confidentiality,
authenticity and integrity of the private key and the authenticity and
integrity of the public key/certificate.
The random number generator of the SM-KT is assumed to provide
entropy of at least 100 bit for key generation.
It is further assumed that the secure module is secured in a way that
protects the communication between the TOE and the module from
eavesdropping and manipulation and that the SM-KT is securely
connected with the TOE (according to TR-03120 [9] and its
appendix [10]). The secure module has undergone an evaluation and
certification process in compliance with the corresponding
Protection Profile [17] and complies with the specification [21].
A.PUSH_SERVER It is assumed that the internal network of the medical supplier is
equipped with a so called Push Server for automatic firmware
updates according to the push update mechanism described in [19].
The TOE administrator is assumed to be responsible for the
operation of the Push Server and able to select the particular
firmware version that the server is allowed to install on the card
terminals.
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 20 of 74 Federal Office for Information Security
Assumption Description
It is further assumed that every time an update process is performed
for a card terminal the Push Server logs the following information:
identifier of involved card terminal, version of firmware to install,
result of the update process.
A.ID000_CARDS It is assumed that all smartcards of form factor ID000 are properly
sealed after they are brought into the TOE.
Further, the developer is assumed to provide guidance
documentation on how a TOE administrator could renew a sealing
after an ID000 card is replaced by another one.
Table 5: Assumptions
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 21 of 74
4 Security Objectives
This chapter describes the security objectives for the TOE and the security objectives for the
environment of the TOE.
4.1 Security Objectives for the TOE
The following security objectives have to be met by the TOE:
Objective Description
O.ACCESS_CONTROL To protect the configuration of the TOE against unauthorized
modifications only an authorized user shall be able to read out
information about the current configuration of the TOE and
only the administrator shall be able to modify the settings of
the TOE.
Therefore the TOE shall provide an access control function
based on the identity of the current user.
Further the access control mechanism of the TOE has to ensure
that the PIN cannot be read from the TOE.
The TOE shall also ensure that the TOE administrator’s
credentials for local management are set before access to other
TOE functionality is possible.
O.PIN_ENTRY The TOE shall serve as a secure pin entry device for the user
and the administrator.
Thus the TOE has to provide the user and administrator with
the functionality to enter a PIN and ensure that the PIN is never
released from the TOE in clear text, except to smart cards in
each addressed local card slot.
For remote-PIN verification the PIN shall be encrypted, by a
local gSMC-KT, controlled by the Connector, so that it can
only be decrypted by the receiving smart card (HPC or SMC-
B).
O.I&A For its access control policy and for parts of the management
functionality the TOE has to be aware of the identity of the
current user.
Thus the TOE has to provide a mean to identify and
authenticate the current user. The TOE shall maintain at least
three distinct roles: administrators, the TOE Reset
Administrator, and users3.
3 It should be noted that the scope of the identification and authentication of the user is only to determine the role
the current user belongs to.
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 22 of 74 Federal Office for Information Security
Objective Description
O.MANAGEMENT In order to protect its configuration the TOE shall provide only an
authenticated and authorized administrator with the necessary
management functions.
The TOE shall enforce an access control policy for management
functions, as some functions shall only be accessible by
administrators authenticated by the local management interface.
Further, the following management functions can be used by
unauthenticated users
Display the product version number of the TOE
View card terminal name for card terminal
The TOE shall provide a local management interface, and
management over SICCT interface.
A firmware consists of two parts: firstly the so-called “firmware list”
and secondly the “firmware core” which includes the whole firmware
except the firmware list. Firmware lists and cores have to versioned
independently.
The firmware list states all firmware core versions to which a change
is allowed: An update of the firmware core is only allowed if the core
version is included in the firmware list.
A firmware update of the TOE shall only be possible after the
integrity and authenticity of the firmware has been verified and the
following holds:
The TOE provides functionality to update and downgrade its
firmware. This includes both the change to a newer firmware
as a downgrade to a firmware which is approved with the
concept of firmware-group.
The configuration, such as terminal type, IP address or
pairing- information shall be preserved and indicated after a
firmware update or a downgrade (see [19] for further
information).
The developer of the TOE shall ensure that in case of a
downgrade of the firmware the TOE must warn the
Administrator (e.g. within the Guidance) before the
installation that the action to be performed is not an upgrade.
The TOE must offer a chance to cancel the installation. The
developer- specific update component shall warn the
administrator about taking the responsibility in case of
performing a downgrade.
The administrator shall be able to manage the list of TSP CAs which
is used to verify the authenticity of connectors. An update of the TSP
CA list shall only be possible after the integrity and authenticity of
the list has been verified.
The TOE shall ensure that for all security attributes, which can be
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 23 of 74
Objective Description
changed by an administrator or the user, only secure values are
accepted. This includes the enforcement of a password policy for the
management interfaces.
In addition to the developer-specific update component the TOE
supports update features of the SICCT specification, whereby a
trigger component is able to update the TOE (e.g. the Configuration
and Software Repository- Service (KSR) of the telematics
infrastructure).
O.SECURE_CHANNEL When establishing a connection between the TOE and the connector
both parties shall be aware of the identity of their communication
partner. Thus the TOE has to provide a mean to authenticate the
connector and to authenticate itself against the connector in
accordance with [19]. The TOE in each security context shall only
have one connection to one connector at a time.
For all communications which fall into the context of the electronic
health card application the TOE shall only accept communication via
this secure channel to ensure the integrity, authenticity and
confidentiality of the transmitted data.
Only functions to identify the TOE in the network (service
discovery) may be available without a secure channel.
O.STATE In principle it would be possible that a card terminal compliant to
this Protection Profile realises more than just the necessary set of
functionality as required by this PP.
However, additional functionality that is not security functionality
(e.g. value-added modules) may lead to an insecure state of the TOE
as the user may be not aware of the fact that they are using a
functionality, which doesn’t fall into the scope of the certified TOE
or because a part of the security functionality as required by this PP
is not working during its use.
Thus the TOE shall be able to indicate whether it is currently in a
secure state, i.e. whether all TSF as required by this PP are actually
enforced.
O.PROTECTION The TOE shall be able to verify the correct operation of the TSF. To
ensure the correct operation of the TSF the TOE shall verify the
correct operation of all security functions at start-up and specifically
verify the correct operation of the secure module (see A.SM).
The TOE shall provide an adequate level of physical protection to
protect the stored assets and the SM-KT4. It has to be ensured that
any kind of physical tampering that might compromise the TOE
Security Policy within 30 minutes can be afterwards detected by the
medical supplier.
4 Please note that the SM-KT provides its own physical protection for the stored keys. However according to
[19] it has to be ensured that the SM-KT is securely connected with the TOE. Thus the physical protection
provided by the TOE has to cover the SM-KT.
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 24 of 74 Federal Office for Information Security
Objective Description
To avoid interference the TOE has to ensure that each connection is
held in its own security context where more than one connection of a
TOE to a connector is established.
Also if more than one smart card in the slots of the TOE is in use the
TOE has to ensure that each connection is held in its own security
context.
The TOE shall delete
PINs,
cryptographic keys, and
all information that is received by a card in a slot of the TOE
or by the connector (except the shared secret)
in a secure way when it is no longer used.
In case a TOE comprises physically separated parts, the TOE shall
prevent the disclosure and modification of data when it is transmitted
between physically separated parts of the TOE.
Table 6: Security Objectives for the TOE
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 25 of 74
4.2 Security Objectives for the Operational Environment
The following security objectives have to be met by the environment of the TOE:
Objective Description
OE.ENV It is assumed that the TOE is used in a controlled environment.
Specifically it is assumed:
The card terminal prevents (not visible) physical
manipulations for at least 30 minutes. The environment
ensures beyond these 30 minutes that the card terminal is
protected against unauthorized physical access or such is
perceptible,
That the user handles his PIN with care; specifically that the
user will keep their PIN secret,
That the user can enter the PIN in a way that nobody else can
read it,
That the user only enters the card PIN when the TOE
indicates a secure state,
That the medical supplier checks the sealing and the physical
integrity of the TOE regularly before it is used,
The medical supplier sends the TOE back to the manufacturer
in case he suspects an unauthorized reset to factory defaults
has been performed by unauthorized personnel, and
That the network of the medical supplier is appropriately
secured so that it cannot be accessed by unauthorized entities.
OE.ADMIN The administrator of the TOE and the medical supplier shall be non-
hostile, well trained and have to know the existing guidance
documentation of the TOE.
The administrator and the medical supplier shall be responsible for
the secure operation of the TOE. Specifically it shall be ensured:
That they enforce the requirements on the environment (see
A.ENV),
That the administrator ensures that the medical supplier
received the necessary guidance documents (especially for
firmware updates),
That the physical examination of the TOE is performed
according to the process described by the manufacturer in the
evaluation process (e.g. seal checking),
That the administrator checks the integrity of the terminal
before the initial start-up procedure (every new pairing
process) and the medical supplier checks the integrity of the
terminal before every start-up procedure,
That they react to breaches of environmental requirements
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 26 of 74 Federal Office for Information Security
Objective Description
according to the process described by the manufacturer (e.g.
reshipment to the manufacturer), and
That the administrator checks the secure state of the TOE
regularly5.
OE.CONNECTOR The connector in the environment has to be trustworthy and provides
the possibility to establish a Trusted Channel with the TOE including
a mean for mutual authentication. The connector has to undergo an
evaluation and certification process in compliance with the
corresponding Protection Profiles [18].
Further the connector has to periodically check the pairing state with
the TOE and warn the administrator accordingly.
OE.SM The TOE will use a secure module (SM-KT) that represents the
cryptographic identity of the TOE in form of an X.509 certificate.
It is assumed that the cryptographic keys in this module are of
sufficient quality and the process of key generation and certificate
generation is appropriately secured to ensure the confidentiality,
authenticity and integrity of the private key and the authenticity and
integrity of the public key/certificate.
The random number generator of the SM-KT shall provide entropy
of at least 100 bit for key generation.
It is further assumed that the secure module is secured in a way that
protects the communication between the TOE and the module from
eavesdropping and manipulation and that the SM-KT is securely
connected with the TOE (according to TR-03120 [9] and its appendix
[10]). The secure module has undergone an evaluation and
certification process in compliance with the corresponding Protection
Profile [17] and complies with the specification [21].
OE.PUSH_SERVER The internal network of the medical supplier is equipped with a so
called Push Server for automatic firmware updates according to the
push update mechanism described in [19].
The TOE administrator is responsible for the operation of the Push
Server and able to select the particular firmware version that the
server is allowed to install on the card terminals.
Every time an update process is performed for a card terminal the
push server logs the following information: identifier of involved
card terminal, version of firmware to install, result of the update
process.
5 The secure state can be indicated by e.g. the pairing information with the connector, the firmware version or
other security events which the developer has to define within the Guidance documentation.
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 27 of 74
Objective Description
OE.ID000_CARDS All smartcards of form factor ID000 shall be properly sealed after
they are brought into the TOE.6
Further, the developer shall provide guidance documentation on how
a TOE administrator could renew a sealing after an ID000 card is
replaced by another one.
Table 7: Security Objectives for the environment of the TOE
4.3 Security Objectives Rationale
The following table provides an overview for security objectives coverage. The following
chapters provide a more detailed explanation of this mapping:
O.ACCESS_CONTROL
O.PIN_ENTRY
O.I&A
O.MANAGEMENT
O.SECURE_CHANNEL
O.STATE
O.PROTECTION
OE.ENV
OE.ADMIN
OE.CONNECTOR
OE.SM
OE.PUSH_SERVER
OE.ID000_CARDS
T.COM X X X X
T.PIN X X X X
T.DATA X X X X X
T.F-CONNECTOR X X X
OSP.SIGG X X X
A.ENV X
A.ADMIN X
A.CONNECTOR X
A.SM X
A.PUSH_SERVER X
A.ID000_CARDS X
Table 8: Security Objective Rationale
4.3.1 Countering the Threats
The threat T.COM, which describes that an attacker may try to intercept the communication
between the TOE and the connector, is countered by a combination of the objectives O.I&A,
O.SECURE_CHANNEL and O.PROTECTION. O.SECURE_CHANNEL describes the secure
6 Please see TIP1-A_3192 in [19].
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 28 of 74 Federal Office for Information Security
channel, which is used to protect the communication between the TOE and the connector.
This objective basically ensures that an attacker is not able to intercept the communication
between the TOE and the connector and removes this threat since both parties have to be
aware of the identity of their communication partner. O.I&A requires that the TOE has to be
able to authenticate the connector. This authentication is part of the establishment of the
secure communication between the TOE and the connector and contributes to removing the
threat. O.PROTECTION ensures that each communication of the TOE with a connector or
cards in its slots is held in a separate security context so that authorized users of the TOE
can’t influence the communication of other users. It further protects the TOE against physical
tampering for 30 minutes. OE.ENV finally ensures that the network of the medical supplier is
appropriately secured so that it cannot be accessed by unauthorized entities and that the TOE
is protected against physical tampering if the TOE is unobserved for more than 30 minutes.
Furthermore OE.ENV assures that the medical supplier checks the sealing and the physical
integrity of the TOE regularly before it is used.
The threat T.PIN, which describes that an attacker may try to release the PIN from the TOE,
is countered by a combination of the objectives O.ACCESS_CONTROL, O.PIN_ENTRY and
O.PROTECTION. O.ACCESS_CONTROL defines that according to the access control policy
of the TOE nobody must be allowed to read out the PIN. In this way it can be ensured that an
attacker cannot read out the PIN via one of the logical interfaces of the TOE O.PIN_ENTRY
defines that the TOE shall serve as a secure pin entry device for the user and the TOE
administrator and contributes to countering T.PIN as it ensures that the PIN cannot be
released from the TOE in clear text. This is the main objective that serves to remove the
threat. O.PROTECTION contributes to countering T.PIN as it ensures that the TOE provides
an adequate level of physical protection for the PIN for 30 minutes. It further protects the PIN
when it is transmitted between physically separated parts, ensures that the PIN is securely
deleted when it is no longer used and ensures that the PIN is sent to the correct card as the
communication to every card slot is held in a separate context. OE.ENV finally ensures that
that the network of the medical supplier is appropriately secured so that it cannot be accessed
by unauthorized entities. The TOE is protected against physical tampering if it is unobserved
for more than 30 minutes and that the medical supplier checks the sealing and the physical
integrity of the TOE regularly before it is used. Furthermore OE.ENV contributes to
countering T.PIN by ascertaining that the user enters the PIN in a way that nobody else can
read it and that this can only be done when the TOE indicates a secure state.
The threat T.DATA, which describes that an attacker may try to release or change protected
data of the TOE, is countered by a combination of O.ACCESS_CONTROL, O.I&A,
O.MANAGEMENT and O.PROTECTION. O.ACCESS_CONTROL ensures that only
authorized users are able to access the data stored in the TOE. O.I&A authenticates the user as
the access control mechanism will need to know about the role of the user for every decision
in the context of access control. O.MANAGEMENT ensures that only the TOE administrator
is able to manage the TSF data and removes the aspect of the threat where an attacker could
try to access sensitive data of the TOE via its management interface. O.PROTECTION
provides the necessary physical protection for the data stored in the TOE for 30 minutes and
defines additional mechanisms to ensure that secret data cannot be released from the TOE
(delete secret data in a secure way keep communication channels separate and protect data
when transmitted between physically separated parts of the TOE). OE.ENV finally ensures
that the network of the medical supplier is appropriately secured so that it cannot be accessed
by unauthorized entities and that the TOE is protected against physical tampering if the TOE
is unobserved for more than 30 minutes. Furthermore OE.ENV assures that the medical
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 29 of 74
supplier checks the sealing and the physical integrity of the TOE regularly before it is used
and that the user only enters the card PIN when the TOE indicates a secure state.
The threat T.F-CONNECTOR, which describes that unauthorized personnel may try to
initiate a pairing process with a fake connector after an unauthorized reset to factory defaults,
is countered by a combination of OE.ENV, OE.ADMIN and OE.CONNECTOR. OE.ENV
ensures that the medical supplier sends the TOE back to the developer in case he suspects an
unauthorized reset to factory defaults has been performed by unauthorized personnel.
OE.ADMIN ensures that the administrator checks the secure state of the TOE regularly before
it is used. OE.CONNECTOR ensures that the connector in the environment is trustworthy and
provides the possibility to establish a Trusted Channel with the TOE including a mean for
mutual authentication. It further ensures that the connector has to undergo an evaluation and
certification process in compliance with the corresponding Protection Profiles.
OE.CONNECTOR further ensures that the connector periodically checks the pairing state with
the TOE and warns the administrator accordingly.
4.3.2 Covering the OSPs
The organizational security policy OSP.SIGG requires that the TOE has to fulfil the
requirements to be used as a secure PIN entry device for applications according to [6] and [7].
From a functional perspective this means that the TOE has to serve as a secure pin entry
device (i.e. that the PIN can never be released from the TOE) and that the TOE has to be able
to indicate whether it is working in a secure state or not.
The secure pin entry device is specified in O.PIN_ENTRY. This objective defines that the
TOE has to provide a function for secure PIN entry and in case of a card PIN that the TOE
will inform the user to which card slot the PIN will be sent. O.STATE ensures that the TOE is
able to indicate to the medical supplier, whether it is currently working in a secure state as
required by OSP.SIGG. Such a secure state includes (but is not limited to) that the secure PIN
entry can be guaranteed. Finally O.PROTECTION ensures that the TOE is able to verify the
correct operation of the TSF and that an adequate level of physical protection is provided.
Further the fact that the TOE shall be compliant to [6] and [7] is the major reason for the
chosen assurance level as the use of EAL 3 + AVA_VAN.5 is required by [6] and [7].
4.3.3 Covering the Assumptions
The assumption A.ENV is covered by OE.ENV as directly follows.
The assumption A.ADMIN is covered by OE.ADMIN as directly follows.
The assumption A.CONNECTOR is covered by OE.CONNECTOR as directly follows.
The assumption A.SM is covered by OE.SM as directly follows.
The assumption A.PUSH_SERVER is covered by OE.PUSH_SERVER as directly follows.
The assumption A.ID000_CARDS is covered by OE.ID000_CARDS as directly follows.
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 30 of 74 Federal Office for Information Security
5 Extended Components Definition
This protection profile uses no components which are not defined in CC part 2.
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 31 of 74
6 Security Requirements
This chapter defines the functional requirements and the security assurance requirements for
the TOE and its environment.
Operations for assignment, selection, refinement and iteration have been made. Operations
not performed in this PP are identified in order to enable instantiation of the PP to a Security
Target (ST).
All operations which have been performed from the original text of [2] are written in italics
for assignments, underlined for selections and bold text for refinements. Furthermore the
[brackets] from [2] are kept in the text.
All operations which have to be completed by the ST author are marked with the words:
"assignment" or "selection" respectively.
The operation “selection, if applicable:” is used in the remainder of this document as
abbreviation for a requirement that must be selected by the ST author if it is applicable for the
respective TOE implementation. If it is not applicable, none can be selected.
6.1 Security Functional Requirements for the TOE
The TOE has to satisfy the SFRs delineated in the following table. The rest of this chapter
contains a description of each component and any related dependencies.
Cryptographic Support (FCS)
FCS_CKM.1/Connector
Cryptographic key generation for connector
communication
FCS_CKM.1/Management Cryptographic key generation for remote management
FCS_CKM.4 Cryptographic key destruction for communication
FCS_COP.1/Con_Sym
Cryptographic operation for connector communication
(symmetric algorithm)
FCS_COP.1/SIG
Cryptographic operation for signature
generation/verification
FCS_COP.1/Management Cryptographic operation for remote management
FCS_COP.1/SIG_FW
Cryptographic operation for firmware signature
verification
FCS_COP.1/SIG_TSP
Cryptographic operation for signature verification of TSP
CA lists
User data protection (FDP)
FDP_ACC.1/Terminal Subset access control for terminal functions
FDP_ACC.1/Management Subset access control for management
FDP_ACF.1/Terminal
Security attribute based access control for terminal
functions
FDP_ACF.1/Management Security attribute based access control for management
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 32 of 74 Federal Office for Information Security
FDP_IFC.1/PIN Subset information flow control for PIN
FDP_IFF.1/PIN Simple security attributes for PIN
FDP_IFC.1/NET Subset information flow control for network connections
FDP_IFF.1/NET Simple security attributes for network connections
FDP_RIP.1 Subset residual information protection
Identification and Authentication (FIA)
FIA_AFL.1 Authentication failure handling
FIA_ATD.1 User attribute definition
FIA_SOS.1 Verification of secrets
FIA_UAU.1 Timing of authentication
FIA_UAU.5 Multiple authentication mechanisms
FIA_UAU.7 Protected authentication feedback
FIA_UID.1 Timing of identification
Security Management (FMT)
FMT_MSA.1/Terminal Management of security attributes for Terminal SFP
FMT_MSA.1/Management Management of security attributes for management SFP
FMT_MSA.2 Secure security attributes
FMT_MSA.3/Terminal Static attribute initialisation for Terminal SFP
FMT_MSA.3/Management Static attribute initialisation for management SFP
FMT_SMF.1 Specification of Management Functions
FMT_SMR.1 Security roles
Protection of the TSF (FPT)
FPT_FLS.1 Failure with preservation of secure state
FPT_ITT.1 Basic internal TSF data transfer protection
FPT_PHP.1 Passive detection of physical attack
FPT_TST.1 TSF testing
TOE Access (FTA)
FTA_TAB.1/SEC_STATE Default TOE access banners for secure state
Trusted path/channels (FTP)
FTP_ITC.1/Connector Inter-TSF trusted channel for connector communication
FTP_TRP.1/Management Trusted path for remote management
Table 9: Security Functional Requirements for the TOE
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 33 of 74
6.1.1 Cryptographic Support (FCS)
6.1.1.1FCS_CKM.1/Connector Cryptographic key generation for connector
communication
FCS_CKM.1.1/Conne
ctor
The TSF shall generate cryptographic keys in accordance with a
specified cryptographic key generation algorithm [assignment:
cryptographic key generation algorithm] and specified cryptographic
key sizes [assignment: cryptographic key sizes] that meet the
following: [[19]].
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
Application Note 1: The cryptographic session keys, generated by FCS_CKM.1/Connector
shall be used for the TLS encryption/decryption between the TOE and
the connector (for further information see [19] also chapter 6.1.1.4).
The generation (actually negotiation) of this key shall be done in
accordance with the Diffie-Hellman protocol.
It should be noted that this negotiation includes a mutual authentication
of the TOE and the connector based on certificate validation (see [19])
and validation of a shared secret. The TOE shall determine the role
from the connector certificate presented during the buildup of the TLS
connection. The Toe shall check that the determined role corresponds
with the role "Signature Application Component (SAC)" (see [19]).
The TOE shall use the SM-KT for Random Number generation,
Signature generation and Signature Verification (see also A.SM) or its
own functionality required by FCS_COP.1/SIG.
The connection to network based management interfaces shall always
be secured with TLS Version 1.1. To ensure future competitiveness the
connection shall also be able to be secured with TLS Version 1.2.
6.1.1.2FCS_CKM.1/Management Cryptographic key generation for remote
Management
FCS_CKM.1.1/Manag
ement
The TSF shall generate cryptographic keys in accordance with a
specified cryptographic key generation algorithm [assignment:
cryptographic key generation algorithm] and specified cryptographic
key sizes [assignment: cryptographic key sizes] that meet the
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 34 of 74 Federal Office for Information Security
following: [[19]].
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
Application Note 2: The cryptographic session keys, generated by
FCS_CKM.1/Management shall be used for the TLS
encryption/decryption for remote management (for further information
see [19] (see also chapter 6.1.1.6). The generation (actually
negotiation) of this key shall be done in accordance with the TLS
handshake protocol (for further information see [12]), extended and
limited by [19].
The TOE should use the functionality of the SM-KT for random
number generation. Note, that the SM-KT is physically integrated into
the TOE in the evaluated TOE configuration.
The connection to network based management interfaces shall always
be secured with TLS Version 1.1. To ensure future competitiveness the
connection shall also be able to be secured with TLS Version 1.2.
This SFR can implicitly be fulfilled by the mechanisms for
cryptographically secured communication with the connector.
6.1.1.3FCS_CKM.4 Cryptographic key destruction for communication
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a
specified cryptographic key destruction method [assignment:
cryptographic key destruction method] that meets the following:
[assignment: list of standards].
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 35 of 74
6.1.1.4FCS_COP.1/Con_Sym Cryptographic operation for connector communication
(symmetric algorithm)
FCS_COP.1.1/Con_Sy
m
The TSF shall perform [assignment: list of cryptographic operations]
in accordance with a specified cryptographic algorithm [assignment:
symmetric cryptographic algorithm] and cryptographic key sizes
[assignment: cryptographic key sizes] that meet the following: [[19]].
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
Application Note 3: The symmetric cryptographic algorithm in FCS_COP.1/Con_Sym shall
be used to set up the trusted channel with a connector (see also chapter
6.1.7.1 for the definition of the trusted channel itself).
6.1.1.5FCS_COP.1/SIG Cryptographic operation for signature generation/verification
FCS_COP.1.1/SIG The TSF shall perform [signature generation/verification] in accordance
with a specified cryptographic algorithm [assignment: cryptographic
algorithm] and cryptographic key sizes [assignment: cryptographic key
sizes] that meet the following: [[19]].
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
Application Note 4: The algorithm for signature generation/verification in
FCS_COP.1/SIG shall be used to establish the trusted channel with the
connector (see also chapter 6.1.7.1 for the definition of the trusted
channel itself). Serving this purpose, the TOE shall use the support of
the SM-KT for signature generation (see also A.SM). Further the TOE
also shall verify that the connector certificate is trusted by the TSP CA
using signature verification of FCS_COP.1/SIG.
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 36 of 74 Federal Office for Information Security
6.1.1.6FCS_COP.1/Management Cryptographic operation for remote management
FCS_COP.1.1/Manage
ment
The TSF shall perform [assignment: list of cryptographic operations]
in accordance with a specified cryptographic algorithm [assignment:
cryptographic algorithm] and cryptographic key sizes [assignment:
cryptographic key sizes] that meet the following: [[19]].
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
Application Note 5: The cryptographic functionality in FCS_COP.1/Management and
FCS_CKM.1/Management shall be used to establish the trusted path
for remote management. See chapter 6.1.7.1 for the definition of the
trusted path.
It is recommended that the cryptographic functionality in
FCS_CKM.1/Management complies with the requirements of the
PKCS#1 standard described in [14].
This SFR can implicitly be fulfilled by the mechanisms for
cryptographically secured communication with the connector.
6.1.1.7FCS_COP.1/SIG_FW Cryptographic operation for firmware signature
verification
FCS_COP.1.1/SIG_F
W
The TSF shall perform [signature verification for firmware updates] in
accordance with a specified cryptographic algorithm [assignment:
cryptographic algorithm] and cryptographic key sizes [assignment:
cryptographic key sizes] that meet the following: [[19]].
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
Application Note 6: The functionality for signature verification is used to check the
integrity and authenticity of a potential firmware update. Such
functionality usually relies on hashing and encryption using a public
key. The public key must be part of the installed firmware. Further
details on the used cryptographic algorithms need to be specified by
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 37 of 74
the ST author.
It is recommended that the cryptographic functionality complies with
the requirements of the PKCS#1 standard described in [14].
6.1.1.8FCS_COP.1/SIG_TSP Cryptographic operation for verification of TSP CA lists
FCS_COP.1.1/SIG_TS
P
The TSF shall perform [assignment: list of cryptographic operations] in
accordance with a specified cryptographic algorithm [assignment:
cryptographic algorithm] and cryptographic key sizes [assignment:
cryptographic key sizes] that meet the following: [[19]].
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
Application Note 7: The functionality is used to verify the integrity and authenticity of a
potential update of the TSP CA list. Such functionality may rely on
hashing and encryption using a public key (signature verification) but
could also require the interaction of an administrator (verification of
hash value).
It is recommended that the cryptographic functionality complies with
the requirements of the PKCS#1 standard described in [14] (if
applicable).
Please also note that if the vendor choses to provide TSP CA list
updates via the firmware update mechanism, this SFR is to be
considered to be fulfilled accordingly.
6.1.2 User data protection (FDP)
6.1.2.1FDP_ACC.1/Terminal Subset access control for terminal functions
FDP_ACC.1.1/Termin
al
The TSF shall enforce the [Terminal SFP] on [
Subjects: all subjects,
Objects: PIN, TSP CA list, shared secret, management credentials,
firmware, cryptographic keys, Communication data [assignment: other
objects]
Operations: Read, modify, [assignment: other operations among
subjects and objects covered by the SFP]].
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 38 of 74 Federal Office for Information Security
Hierarchical to: No other components.
Dependencies: FDP_ACF.1 Security attribute based access control
6.1.2.2FDP_ACC.1/Management Subset access control for management
FDP_ACC.1.1/Manag
ement
The TSF shall enforce the [Management SFP] on [Subjects: users,
[assignment: other subjects or none]
Objects: manageable objects, i.e. management functions
Operations: execute].
Hierarchical to: No other components.
Dependencies: FDP_ACF.1 Security attribute based access control
6.1.2.3FDP_ACF.1/Terminal Security attribute based access control for terminal
functions
FDP_ACF.1.1/Termin
al
The TSF shall enforce the [Terminal SFP] to objects based on the
following: [
Subjects: all subjects, attribute: user role7
Objects: PIN, shared secret, management credentials, firmware,
cryptographic keys, attribute: firmware version, Enable/Disable the
functionality of an unauthorized reset to factory defaults8
[assignment: other objects and related attributes]
].
FDP_ACF.1.2/Termin
al
The TSF shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed: [If a
firmware update is initiated, a modification of the firmware of the TOE
shall only be allowed after the integrity and authenticity of the
firmware has been verified according to FCS_COP.1/SIG_FW and :
The card terminal shall recognize non- authentic transmissions.
The security anchor required for this action shall be placed in a
writing-protected area of the external interfaces of the TOE.
Furthermore, the security anchor shall be located in a read-
only area of the device and shall only be able to be replaced
with an administrative action.
The transmission mechanism shall be in a position to detect
transmission errors independently.
7 The role of the user (e.g. medical supplier, TOE administrator)
8 i.e. its configuration status
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 39 of 74
An update of the firmware of the TOE shall only be allowed by
an authenticated administrator:
o A firmware consists of two parts: firstly the so-
called “firmware list” and secondly the “firmware
core” which includes the whole firmware except the
firmware list. The firmware list states all firmware
core versions to which a change is allowed.
Firmware lists and cores have to be versioned
independently.
o An update of the firmware core is only allowed if the
core version is included in the firmware list.
Firmware lists must only contain version numbers of
firmware cores which are certified according this
Protection Profile. For the use in the German
Healthcare System the named versions must also be
approved by the gematik.
o In case of downgrades of the firmware the TOE must
warn the administrator before the installation that
he is doing a downgrade, not an upgrade. The TOE
must offer him the chance to cancel the installation.
o In case of a common update the TOE has to install
the new firmware list at first. The new list is used to
decide whether an update to the accompanying
firmware core is allowed.
o Updates of the firmware list are only allowed to
newer versions. Use higher version numbers to
distinguish newer versions.
o Installation of firmware cores and lists are only
allowed after the integrity and authenticity of the
firmware has been verified using the mechanism as
described in FCS_COP.1/SIG_FW.
If a TSP CA list update is initiated, a modification of the list shall only
be allowed after the integrity and authenticity of the new TSP CA list
has been verified according to FCS_COP.1/SIG_TSP.
The developer of the TOE shall ensure that in case of a downgrade of
the firmware the TOE must warn the Administrator (e.g. within the
Guidance) before the installation that the action to be performed is not
an upgrade. The TOE must offer a chance to cancel the installation. A
downgrade of the TOE shall only be possible after warning the
administrator about the risks of this action. This warning shall be
performed by the developer- specific update component.
The following management functions shall be executable by
authenticated TOE administrators (excluding SICCT interface):
[selection: Enable/Disable the functionality of unauthorized
reset to factory defaults or none]
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 40 of 74 Federal Office for Information Security
[assignment: other rules or none]
].
FDP_ACF.1.3/Termin
al
The TSF shall explicitly authorise access of subjects to objects based
on the following additional rules: [assignment: rules, based on security
attributes that explicitly authorise access of subjects to objects].
FDP_ACF.1.4/Termin
al
The TSF shall explicitly deny access of subjects to objects based on the
following additional rules [
No subject shall access any object but the TOE administrator’s
local management credentials before the TOE administrator’s
credentials are initially set.
No subject shall read out the PIN, shared secret, management
credentials or secret cryptographic keys while they are
temporarily stored in the TOE
No subject shall modify the public key for the signature
verification of firmware updates unless a new public key is part
of a firmware update.
].
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
Application Note 8: Specific implementations of a TOE compliant to this PP may require
more objects that are subject to Access Control and more granular rules
for Access Control. Therefore the open assignment in FDP_ACF.1.2
should allow the ST author to specify the Access Control Policy for the
TOE in more detail.
Note that “firmware version” in FDP_ACF.1.2/Terminal could also be
interpreted as a firmware group version. This allows the use of the
firmware group concept described in [19] making downgrades
possible.
The developer may implement an additional unauthorized reset to
factory defaults mechanism.
In case the additional unauthorized reset to factory defaults mechanism
is implemented, the following notes shall be considered:
The TOE administrators shall be able to enable/disable this
mechanism.
This mechanism shall be disabled by the default setting of the
TOE.
The TOE shall offer two reset options, i.e. authorized and
unauthorized reset to factory default settings for the TOE
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 41 of 74
administrator, if the later is enabled.
The unauthorized reset to factory default settings may be
technically performed by every user. It is, however,
recommended that a reset shall only be performed by the TOE
administrator.
An unauthorized reset to factory defaults by unauthorized
personnel results in an organisationally insecure state.
The TOE administrator shall check the TOE and its
environment regularly.
The potentially insecure state shall be identified by the TOE or
its environment.
Information about the question of how the TOE and its
environment indicate the insecure state after an unauthorized
reset to factory defaults by unauthorized personnel shall be
provided in the Guidance documentation.
The information given in the Guidance documentation has to
deal with the identification of the potentially insecure state and
steps to take for reprocessing or disposal of the TOE.
The reprocessing or disposal also shall be subject to ALC work
units. If additional functionality was necessary for this, the ST
author would have to model it in the ST.
6.1.2.4FDP_ACF.1/Management Security attribute based access control for
management
FDP_ACF.1.1/Manage
ment
The TSF shall enforce the [Management SFP] to objects based on the
following: [
Subjects: users, [assignment: other subjects or none]
Subject attributes: role(s), management interface9, [assignment: other
subject attributes or none]
Objects: management functions,
Object attributes: none
].
FDP_ACF.1.2/Manage
ment
The TSF shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed: [
The following management functions shall be executable by all roles:
Display the product version number of the TOE
Manage own login credentials
View card terminal name for card terminal
[selection, if applicable: View the available network
9 The subject attribute management interface specifies the interface from which the user is connecting (i.e. local,
remote, SICCT).
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 42 of 74 Federal Office for Information Security
configuration]
[selection, if applicable: Display the MAC-address(es) of the
TOEs network interface(s)]
[selection, if applicable: Reset the TOE settings to factory
defaults (unauthorized reset to factory defaults)10]
[assignment: further management functions that do not
contradict the intention of the policy]
The following management functions shall be executable by
authenticated TOE administrators (excluding SICCT interface):
[selection, if applicable: Manage the available network
configuration]
[selection, if applicable: Set card terminal name for card
terminal]
[selection, if applicable: Enable/Disable remote update
functionality for firmware update]
Manage local and remote management login credentials
Secure deletion of pairing information from all three possible
pairing processes (initial pairing, review of pairing-
information and maintenance-pairing)
Manage the list of TSP CAs
Perform a firmware update
Reset the TOE settings to factory defaults
[selection, if applicable: Enable/Disable the functionality of
unauthorized reset to factory defaults]
[assignment: further management functions that do not
contradict the intention of the policy]
The following management functions shall be executable by TOE
administrators that were authenticated using the SICCT interface:
[selection, if applicable: Set card terminal name for card
terminal]
Perform a firmware update
The following management functions shall be only executable by TOE
administrators that were authenticated using the local management
interface:
Enable/disable the remote management interface (if applicable)
10 Note that an unauthorized reset to factory defaults can technically be performed by every user but shall only
be performed by the TOE administrator. Moreover an unauthorized reset to factory defaults executed by
unauthorized personnel results in an insecure state which will make it necessary for the administrator to replace
the TOE. Further this potentially insecure state has to be indicated by the TOE or its environment. The St author
will have to address the question of how the TOE and its environment indicate the insecure state after an
unauthorized reset to factory defaults by unauthorized personnel (e.g. by indicating the lost pairing) and provide
information in the Guidance documentation regarding the identification this state and steps to take for
reprocessing or disposal of the TOE. Please refer to Application Note 8 for further information.
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 43 of 74
Perform the initial pairing process with the connector
[assignment: further management functions that do not
contradict the intention of the policy]
The TOE Reset Administrator shall only be able to execute the
following management function:
Reset the TOE settings to factory defaults (fallback)
[assignment: further rules that do not contradict the intention of the
policy[assignment: change the PUK, if applicable]]
].
FDP_ACF.1.3/Manage
ment
The TSF shall explicitly authorise access of subjects to objects based
on the following additional rules: [assignment: rules, based on security
attributes that explicitly authorise access of subjects to objects [that do
not contradict the intention of the policy]].
FDP_ACF.1.4/Manage
ment
The TSF shall explicitly deny access of subjects to objects based on the
following additional rules [assignment: rules, based on security
attributes, that explicitly deny access of subjects to objects [that do not
contradict the intention of the policy]]
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
Application Note 9: FDP_ACF.1/Management was used to define the access control for
management functionality of the TOE. It simplifies the enhancement of
further management functions and necessary privileges by the ST
author. It applies to all local, remote or SICCT interfaces, which are
capable of management functionality.
6.1.2.5 FDP_IFC.1/PIN Subset information flow control for PIN
FDP_IFC.1.1/PIN The TSF shall enforce the [PIN SFP] on [
Subjects: user, card, connector, remote card terminal11
Information: PIN
Operation: Entering the PIN].
Hierarchical to: No other components.
Dependencies: FDP_IFF.1 Simple security attributes
11 A remote card terminal either sends or receives a PIN for remote-PIN verification.
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 44 of 74 Federal Office for Information Security
6.1.2.6 FDP_IFF.1/PIN Simple security attributes for PIN
FDP_IFF.1.1/PIN The TSF shall enforce the [PIN SFP] based on the following types of
subject and information security attributes: [
Subject attribute: slot identifier12 , [assignment: other attributes]].
FDP_IFF.1.2/PIN The TSF shall permit an information flow between a controlled subject
and controlled information via a controlled operation if the following
rules hold: [
PINs shall never be stored in the non-volatile memory of the TOE.
The PIN entered by the user shall only be sent via the secure channel
targeting the card in the card slot of the TOE or a remote card
terminal for remote-PIN verification.
In the latter case the TOE shall assure that the connection to the
connector is TLS secured.
].
FDP_IFF.1.3/PIN The TSF shall enforce the [PIN digits shall never be displayed on the
display during entry of the PIN. The TOE shall rather present asterisks
as replacement for digits.].
FDP_IFF.1.4/PIN The TSF shall explicitly authorise an information flow based on the
following rules: [none].
FDP_IFF.1.5/PIN The TSF shall explicitly deny an information flow based on the
following rules: [
The PIN shall never leave the TOE in clear text for remote-PIN
verification.
].
Hierarchical to: No other components.
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
12 This is the slot the user plugged his smart card in
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 45 of 74
Application Note 10: Please note that the term "display" in this and other SFR refers to a
generic display device and does not require any specific realization.
Specifically this term does not require any display based on text or
graphics but could e.g. also be realized as a simple LED as long as the
requirements are fulfilled. However, [19] may specify more detailed
requirements about the display device.
For remote-PIN verification the TOE may send the PIN to another card
terminal via the connector. The PIN is then encrypted and transferred
using card-to-card authentication of the smart cards in both card
terminals.
Remote-PIN verification is initiated by the connector. Therefore, it is
responsible to select the participating card terminals and to initiate
card-to-card authentication between both.
Communication between TOE and connector is additionally secured
using FCS_COP.1/Con_Sym.
6.1.2.7 FDP_IFC.1/NET Subset information flow control for network
connections
FDP_IFC.1.1/NET The TSF shall enforce the [NET SFP] on [
Subjects: Connector, the TOE,
Information: all information arriving at the network interface
Operation: accept the communication].
Hierarchical to: No other components.
Dependencies: FDP_IFF.1 Simple security attributes
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 46 of 74 Federal Office for Information Security
6.1.2.8 FDP_IFF.1/NET Simple security attributes for network connections
FDP_IFF.1.1/NET The TSF shall enforce the [NET SFP] based on the following types of
subject and information security attributes: [
Subject: Connector
Information: Passwords, patient data, shared secret, any other
information
Information attribute: sent via the trusted channel, [assignment: other
attributes]].
FDP_IFF.1.2/NET The TSF shall permit an information flow between a controlled subject
and controlled information via a controlled operation if the following
rules hold: [
Any information arriving at the network interface from the connector
must only be accepted if the communication path is encrypted and the
connector has been successfully authenticated13
The TOE shall have only one connection to one connector at a time.
].
FDP_IFF.1.3/NET The TSF shall enforce the [assignment: additional information flow
control SFP rules].
FDP_IFF.1.4/NET The TSF shall explicitly authorise an information flow based on the
following rules: [
The TOE shall accept the following SICCT commands arriving at the
network interface even if no pairing process is established and no valid
connector certificate is presented:
SICCT CT INIT CT SESSION
SICCT CT CLOSE CT SESSION
SICCT GET STATUS
SICCT SET STATUS
SICCT CT DOWNLOAD INIT
SICCT CT DOWNLOAD DATA
SICCT CT DOWNLOAD FINISH
The TOE shall additionally accept the following EHEALTH commands
(please refer to [19]) arriving at the network interface if no pairing
process is established but a valid connector certificate14 is presented:
EHEALTH TERMINAL AUTHENTICATE
Commands to identify the TOE in the network (service discovery) may
be accepted and processed even without an encrypted or authenticated
connection.
13 See the trusted channel in section 6.1.7.1 and the verification in section 6.1.1.5.
14 For the steps in verifying signatures of the certificate application component see [19], Table 2.
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 47 of 74
].
FDP_IFF.1.5/NET The TSF shall explicitly deny an information flow based on the
following rules: [
Passwords for management interfaces shall never leave the
TOE
The shared secret shall never leave the TOE in clear text (even
over trusted channel)
Patient data shall not be transferred via the management
interfaces
].
Hierarchical to: No other components.
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
Application Note 11: Please note that the information flow policy defined in
FDP_IFC.1/NET and FDP_IFF.1/NET is focused on the
communications, which fall into the scope of the application for the
electronic health card and which happen between the connector and the
TOE.
Connections for administration of the TOE may not be initiated by a
connector. Therefore such a connection may not be covered by this
policy.
Further, according to [19] the terminal is free to accept unencrypted
communications for other applications, which may be additionally
realized by the terminal (or during the migration phase). In these cases
the terminal would have to indicate to the user that it is working in an
insecure state.
Please note that as a limitation to [20] the control byte for the bits
b2..b1 of the Command-To-Perform Data Object CMD DO shall not
contain other values than {b 2 = 1, b1 = 0} or {b 2 = 1, b1 = 1}.
6.1.2.9 FDP_RIP.1 Subset residual information protection
FDP_RIP.1.1 The TSF shall ensure that any previous information content of a
resource is made unavailable upon the [deallocation of the resource
from] the following objects: [PIN, cryptographic keys, all information
that is received by a card in a slot of the TOE or by the connector
(except the shared secret), [assignment: other object or none]].
Hierarchical to: No other components.
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 48 of 74 Federal Office for Information Security
Dependencies: No dependencies.
Application Note 12: The functionality, defined in FPD_RIP.1 defines that the TOE is not
allowed to save any information that was received by the connector or
a card in a slot of the TOE permanently. This is necessary as the TOE
relies on a controlled environment (A.ENV) to provide an adequate
level of protection for the assets. If a TOE was e.g. stolen an attacker
must not be able to read any of the information that was received from
the connector or a card in a slot of the TOE.
Only information that is absolutely indispensable for the operation of
the TOE (e.g. a secret that may be used for an initial review or the
review of pairing information as part of the authentication with the
connector) may be stored permanently within the TOE.
If the TOE performs Batch Signatures, it shall use the functionality of
the authorized card rather than implement its own batch signature loop.
In particular, this means that the PIN shall not be stored temporarily to
trigger single signature processes using the stored PIN. The PIN shall
be sent to the card once only and be made unavailable immediately
after the batch signing process is initiated.
6.1.3 Identification and Authentication (FIA)
6.1.3.1 FIA_AFL.1 Authentication failure handling
FIA_AFL.1.1 The TSF shall detect when [[at least 3]] unsuccessful authentication
attempts occur related to [management authentication excluding
authentication for the TOE Reset Administrator].
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has
been [met, surpassed], the TSF shall [lock the particular management
interface for that account for a time period according to Table 10
depending on the number of consecutive unsuccessful authentication
attempts].
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication
Application Note 13: The assignment in FIA_AFL.1.2 implies that each management
interface shall have its own counters for unsuccessful authentication
attempts.
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 49 of 74
Consecutive unsuccessful
authentication attempts
Lockout time
3-6 1 minute
7-10 10 minutes
11-20 1 hour
>20 1 day
Table 10: Lockout times
6.1.3.2 FIA_ATD.1 User attribute definition
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes
belonging to individual users: [Role15, [assignment: list of security
attributes]].
Hierarchical to: No other components.
Dependencies: No dependencies
Application Note 14: For the case that no further user attributes are needed for any policy of
a TOE "none" should be considered as a valid assignment in
FIA_ATD.1.1
6.1.3.3 FIA_SOS.1 Verification of secrets
FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet [the
following]:
[
Passwords for management shall
Have a length of at least 8 characters,
Be composed of at least the following characters: “0”-“9”,
Not contain the User ID/logon name shall not be a part of the
password for the management interface,
Not be saved on programmable function keys,
Not be displayed as clear text during entry,
].
Hierarchical to: No other components.
Dependencies: No dependencies
15 The role (attribute) of the user (e.g. medical supplier, TOE administrator).
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 50 of 74 Federal Office for Information Security
Application Note 15: Note that the requirements on passwords hold for all management
interfaces. Passwords for management interfaces (user authentication
mechanism) may be implemented separately for each management
interface.
6.1.3.4 FIA_UAU.1 Timing of authentication for management
FIA_UAU.1.1 The TSF shall allow [
Display the product version number of the TOE
[selection, if applicable: Display the MAC-address(es) of the
TOEs network interface(s)]
[selection, if applicable: Reset the TOE settings to factory
defaults (unauthorized reset to factory defaults)16]
[assignment: other TSF-mediated actions]
] 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.
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
6.1.3.5 FIA_UAU.5 Multiple authentication mechanisms
FIA_UAU.5.1 The TSF shall provide [
A password based authentication mechanism,
A remote authentication mechanism using the SICCT interface
An authentication mechanism for the TOE Reset Administrator
[assignment: additional authentication mechanism]
] to support user authentication.
16 Note that an unauthorized reset to factory defaults can technically be performed by every user but shall only
be performed by the TOE administrator. Moreover an unauthorized reset to factory defaults executed by
unauthorized personnel results in an insecure state which will make it necessary for the administrator to replace
the TOE. Further this potentially insecure state has to be indicated by the TOE or its environment. The St author
will have to address the question how the TOE and its environment indicate the insecure state after an
unauthorized reset to factory defaults by unauthorized personnel (e.g. by indicating the lost pairing) and provide
information in the Guidance documentation regarding the identification this state and steps to take for
reprocessing or disposal of the TOE. Please refer to Application Note 8 for further information.
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 51 of 74
FIA_UAU.5.2 The TSF shall authenticate any user's claimed identity according to the
[following]: [
The local authentication mechanism is used for authentication
of TOE administrators for management and other users
The remote authentication mechanism is used for
authentication of TOE administrators for management if
applicable
The remote authentication for the SICCT interface is used for
authentication of TOE administrators for management
The authentication mechanism for the TOE Reset Administrator
is used to authenticate the TOE Reset Administrator who alone
is able to reset the TOE settings to factory defaults (fallback)
when the management credentials are lost
[assignment: additional rules]
]
Hierarchical to: No other components.
Dependencies: No dependencies
Application Note 16: Please note that FIA_UID.1 and FIA_UAU.1 refer to the
authentication of TOE administrators, the TOE Reset Administrator
and users of the TOE. According to [19] this should not be seen as a
requirement to maintain the ID of the current user for access control.
The scope of these requirements is to determine to which group the
current user belongs as the access control mechanism of the TOE
primarily works on the basis of the user role
The authentication mechanism for the TOE Reset Administrator could
be a challenge-response-mechanism. It is important that replay attacks
are not possible. Therefore, an authentication token for a card terminal
(if applicable) is either distinct from those for other card terminals or
additionally protected by other means to avoid misuse.
As part of authentication a possible introduction of a secure certificate
into the client can be considered. In case of the use of such a secure
certificate for a management connection the developer shall describe
the procedure of the authentication in the user documentation.
6.1.3.6 FIA_UAU.7 Protected authentication feedback
FIA_UAU.7.1 The TSF shall provide only [asterisks for password characters during
PIN entry] to the user while the authentication is in progress.
Hierarchical to: No other components
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 52 of 74 Federal Office for Information Security
Dependencies: FIA_UID.1 Timing of identification
Application Note 17: This SFR covers the management authentication feedback.
6.1.3.7 FIA_UID.1 Timing of identification
FIA_UID.1.1 The TSF shall allow [
Display the product version number of the TOE
View card terminal name for card terminal
[selection, if applicable: Display the MAC-address(es) of the
TOEs network interface(s)]
[selection, if applicable: Reset the TOE settings to factory
defaults (unauthorized reset to factory defaults)17]
[assignment: other TSF-mediated actions]
] 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.
Hierarchical to: No other components
Dependencies: No dependencies.
Application Note 18: Although the ST author is in charge of defining other TSF mediated
actions, which are allowed without having the user successfully
authenticated before, the assignments in FIA_UAU.1.1/Management
and FIA_UID.1.1/Management have to be performed in a way that
none of the TSP of the TOE is violated.
6.1.4 Security Management (FMT)
6.1.4.1 FMT_MSA.1/Terminal Management of security attributes for
Terminal SFP
17 Note that this functionality is only applicable when it is implemented by the TOE and enabled by the
administrator. For further information please refer to 6.1.4.6 and Application Note 20. An unauthorized reset to
factory defaults can technically be performed by every user but shall only be performed by the TOE
administrator. Moreover an unauthorized reset to factory defaults executed by unauthorized results in an insecure
state which will make it necessary for the administrator to replace the TOE. Further this potentially insecure state
has to be indicated by the TOE or its environment. The St author will have to address the question how the TOE
and its environment indicate the insecure state after an unauthorized reset to factory defaults by unauthorized
personnel (e.g. by indicating the lost pairing) and provide information in the Guidance documentation regarding
the identification this state and steps to take for reprocessing or disposal of the TOE. Please refer to Application
Note 8 for further information.
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 53 of 74
FMT_MSA.1.1/Termi
nal
The TSF shall enforce the [Terminal SFP] to restrict the ability to
[modify] the security attributes [Enable/Disable the functionality of an
unauthorized reset to factory defaults18] to [authenticated TOE
administrators (excluding SICCT interface)19].
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
6.1.4.2 FMT_MSA.1/Management Management of security attributes for
Management SFP
FMT_MSA.1.1/Manag
ement
The TSF shall enforce the [Management SFP] to restrict the ability to
[query, modify, delete, [assignment: other operations]] the security
attributes [manageable objects, i.e. all management functions] to [TOE
administrators].
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
6.1.4.3 FMT_MSA.2 Secure security attributes
FMT_MSA.2.1 The TSF shall ensure that only secure values are accepted for
[role(s)20].
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_MSA.1 Management of security attributes
18 i.e its configuration status
19 i.e. the standard interface to the connector using the SICCT-Protocol
20 Role(s) as defined in 6.1.4.7
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 54 of 74 Federal Office for Information Security
FMT_SMR.1 Security roles
6.1.4.4 FMT_MSA.3/Terminal Static attribute initialisation for Terminal SFP
FMT_MSA.3.1/Termi
nal
The TSF shall enforce the [Terminal SFP] to provide [restrictive]
default values for security attributes that are used to enforce the SFP.
FMT_MSA.3.2/Termi
nal
The TSF shall allow the [no roles] to specify alternative initial values
to override the default values when an object or information is created.
Hierarchical to: No other components.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
6.1.4.5 FMT_MSA.3/Management Static attribute initialisation for
management SFP
FMT_MSA.3.1/Manag
ement
The TSF shall enforce the [Management SFP] to provide [restrictive]
default values for security attributes that are used to enforce the SFP.
FMT_MSA.3.2/Manag
ement
The TSF shall allow the [no roles] to specify alternative initial values
to override the default values when an object or information is created.
Hierarchical to: No other components.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
Application Note 19: Restrictive specifically means that remote update functionality for
firmware update and remote management functionality are disabled by
default.
6.1.4.6 FMT_SMF.1 Specification of Management Functions
FMT_SMF.1.1 The TSF shall be capable of performing the following management
functions: [
Manage local and remote management login credentials21
Perform the pairing process (initial pairing, review of pairing-
information and maintenance-pairing) with the connector
Secure deletion of pairing information from all three possible
pairing processes
21 On first start-up the TOE forces the administrator to specify a password for local management.
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 55 of 74
Manage the list of TSP CAs22
View/set card terminal name23 for card terminal
Perform a firmware update
Reset the TOE settings to factory defaults24
Reset the TOE settings to factory defaults (fallback)25
Display the product version number of the TOE
Display the installed firmware group version
Return self-assessment through the user interface of the
administration interface
Enable/disable remote management functionality
[selection, if applicable: Managing network configuration]
[selection, if applicable: Enable/Disable remote update
functionality for firmware update]
[selection, if applicable: Enable/Disable the functionality of an
unauthorized reset to factory defaults.26]
[selection, if applicable: Choose, which reset to factory defaults
mechanism (reset the TOE settings to factory defaults or
unauthorized reset to factory defaults) to perform.27]
[selection, if applicable: Display the MAC-address(es) of the
TOEs network interface(s)]28
[assignment: other relevant management functions [assignment:
Change the PUK, if applicable] or none] 29].
Hierarchical to: No other components.
Dependencies: No dependencies.
22 Management of TSP-CAs includes the update of TSP-CA lists as described in [19] as well as a selection of a
particular TSP-CA list to be used in case of multiple TSP-CA lists residing in the firmware (e.g. a separate TSP-
CA list for test purposes).
23 The card terminal name is a unique identifier for the card terminal. Note that the terminal name shall not be
set using dhcp.
24 Note that after a reset to factory defaults the TOE is supposed to be in its initial state, and the administrator’s
local management credentials have to be set again.
25 The fallback solution for reset of TOE settings is necessary in case the credentials for management are lost.
26 In case this functionality is implemented it must be disabled by default. Please also refer to Application Note 8
for further information
27 Note that an unauthorized reset to factory defaults executed by unauthorized personnel shall lead the TOE into
an insecure state which will make it necessary to send the TOE back to the developer. Please refer to Application
Note 8 for further information
28 Another option would be to attach the MAC-address(es) to the body of the card terminal.
29 For the case a PUK is implemented a reset to factory defaults shall be performed in the way described in [19].
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 56 of 74 Federal Office for Information Security
Application Note 20: FDP_ACF.1/Management and FDP_ACC.1/Management further
define which management functions are executable for the various user
roles.
Please note, that relevant data like failure counters for management
interfaces and the shared secret shall not be reset when the firmware is
updated.
As the reset to factory defaults (fallback) is only possible for
authenticated TOE administrators (see FDP_ACF.1/Management), the
ST author will also have to address the question how the TOE can be
reset to factory defaults when the management credentials are lost. If
additional security functionality was necessary for this, the ST author
would have to model it in the ST.
Note that remote update functionality for firmware update may only be
implemented as a PUSH service described in [19]. This requires an
update component located in the local network of the medical supplier
which is under the control of the TOE administrator (see
OE.PUSH_SERVER). The administrator approves and releases the
firmware update that should be pushed by the update component. The
update component logs card terminal identifier, the time of update, the
version of the firmware to install, and the result of the update for each
single update process.
The TOE administrators shall be able to Enable/Disable the
functionality of an unauthorized reset to factory defaults in case this
functionality is implemented by the TOE.
Further only authenticated TOE administrators shall be able to choose,
which reset to factory defaults mechanism (reset the TOE settings to
factory defaults or unauthorized reset to factory defaults) to perform
when performing a reset.
Those SFRs refer to all Management interfaces and have to be refined
accordingly. Those include mandatory local and SICCT as well as the
optional remote management interface.
6.1.4.7 FMT_SMR.1 Security roles
FMT_SMR.1.1 The TSF shall maintain the roles [user, TOE administrator, TOE Reset
Administrator [assignment: other roles or none]].
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 57 of 74
6.1.5 Protection of the TSF (FPT)
6.1.5.1 FPT_FLS.1 Failure with preservation of secure state
FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of
failures occur: [disconnection of connector30, failure during firmware
update, [assignment: list of other types of failures in the TSF]].
Hierarchical to: No other components.
Dependencies: No dependencies
Application Note 21: As [19] does not define the list of errors for which a secure state has to
be preserved, the assignment in FPT_FLS.1.1 is left to the ST author.
As a minimum the failure of any of the self-tests as defined in
FPT_TST.1 and failure of firmware updates shall be considered for this
assignment.
6.1.5.2 FPT_ITT.1 Basic internal TSF data transfer protection
FPT_ITT.1.1 The TSF shall protect TSF data from [disclosure, modification] when it
is transmitted between separate parts of the TOE.
Hierarchical to: No other components.
Dependencies: No dependencies
Application Note 22: Please note that this SFR is easily fulfilled for the cases where a TOE
does not comprise physically separated parts or a protection of the
communication between those parts is obviously not relevant.
6.1.5.3 FPT_PHP.1 Passive detection of physical attack
FPT_PHP.1.1 The TSF shall provide unambiguous detection of physical tampering
that might compromise the TSF.
FPT_PHP.1.2 The TSF shall provide the capability to determine whether physical
tampering with the TSF's devices or TSF's elements has occurred.
Hierarchical to: No other components.
Dependencies: No dependencies
30 When the TLS connection to the connector is lost, the secure state is preserved by resetting all plugged smart
cards.
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 58 of 74 Federal Office for Information Security
Application Note 23: It is strongly recommended that the ST author considers replacing
FPT_PHP.1 by FPT_PHP.2 (or a higher component) to require an
active protection mechanism against physical manipulation. In case
FPT_PHP.1 is replaced by FPT_PHP.2 the dependency to
FMT.MOF.1 shall also be considered.
6.1.5.4 FPT_TST.1 TSF testing
FPT_TST.1.1 The TSF shall run a suite of self-tests [during initial start-up, at the
conditions [assignment: conditions under which self-test should
occur]] to demonstrate the correct operation of [ the TSF].
FPT_TST.1.2 The TSF shall provide authorised users with the capability to verify the
integrity of [selection: [assignment: parts of TSFdata], TSF data]].
FPT_TST.1.3 The TSF shall provide authorised users with the capability to verify the
integrity of [selection: [assignment: parts of TSF], TSF].
Hierarchical to: No other components.
Dependencies: No dependencies
Application Note 24: Please note that [19] does not define any concrete requirements for the
minimum functionality that has to be covered by the self-test of the
TOE. However, as the focus of this requirement is to demonstrate the
correct operation of the complete TSF the ST author will have to
describe test functionality for all important aspects of all Security
Functions that the TOE provides.
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 59 of 74
6.1.6 TOE Access (FTA)
6.1.6.1 FTA_TAB.1/SEC_STATE Default TOE access banners for secure
state
FTA_TAB.1.1/SEC_
STATE
Before establishing a user session, the TSF shall display a message
indicating, whether the TOE is in a secure state or not.
Hierarchical to: No other components.
Dependencies: No dependencies.
Application Note 25: In the context of FTA_TAB.1/SEC_STATE the term “Before
establishing a user session” refers to every situation a user is about to
use the TOE.
Application Note 26: This SFR is used to meet O.STATE. The “secure state” refers to a
mode of operation in which all TSPs of this PP are met and no
additional value-added module functionality (as allowed by [19]) is
active that could compromise a TSP. Specifically the TOE will
guarantee a secure PIN entry within such a secure state.
For example according to [19] a TOE could in principle accept
unencrypted communications by a third party for applications that are
outside the scope of the German Healthcare System. However as long
as an unencrypted connection is established the TOE cannot be
considered being in a secure state.
This SFR is implicitly fulfilled in case the TOE doesn’t provide any
additional functionality than the functionality, required by this PP and
can’t operate in an insecure state.
6.1.7 Trusted path/channels (FTP)
6.1.7.1 FTP_ITC.1/Connector Inter-TSF trusted channel for connector
communication
FTP_ITC.1.1/Connect
or
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/Connect
or
The TSF shall permit [the connector] to initiate communication via the
trusted channel.
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 60 of 74 Federal Office for Information Security
FTP_ITC.1.3/Connect
or
The TSF shall initiate communication via the trusted channel for [all
communication functions used by eHealth applications].
Hierarchical to: No other components.
Dependencies: No dependencies.
Application Note 27: The SFR covers the authentication of the connector by the TOE using
the connector certificate of an already paired connector. The TOE also
verifies that the connector certificate is trusted by the TSP CA using
signature verification of FCS_COP.1/SIG.
The trusted channel will only be active when the TOE is in “secure
state”. Otherwise it will be dropped.
There is only one connection to one connector at a time.
The TOE authenticates itself with the shared secret and the certificate
of the SM-KT. It has to be ensured that no security threat arises when
the SM-KT is unplugged (e.g. by dropping the TLS connection).
6.1.7.2 FTP_TRP.1/Management Trusted path for remote management
FTP_TRP.1.1/Manage
ment
The TSF shall provide a communication path between itself and
[remote] users that is logically distinct from other communication
paths and provides assured identification of its end points and
protection of the communicated data from [modification or disclosure,
[assignment: other types of integrity or confidentiality violation]].
FTP_TRP.1.2/Manage
ment
The TSF shall permit [remote users] to initiate communication via the
trusted path.
FTP_TRP.1.3/Manage
ment
The TSF shall require the use of the trusted path for [[authentication of
TOE administrators, remote management]].
Hierarchical to: No other components.
Dependencies: No dependencies.
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 61 of 74
6.2 Security Assurance Requirements for the TOE
The following table lists the assurance components which are applicable to this PP:
Assurance Class Assurance Components
ADV: Development ADV_ARC.1 Security architecture description
ADV_FSP.4 Complete functional specification
ADV_IMP.1 Implementation representation of
the TSF
ADV_TDS.3 Basic modular design
AGD: Guidance documents AGD_OPE.1 Operational user guidance
AGD_PRE.1 Preparative procedures
ALC: Life-cycle support ALC_CMC.3 Authorisation controls
ALC_CMS.3 Implementation representation
CM coverage
ALC_DEL.1 Delivery procedures
ALC_DVS.1 Identification of security
measures
ALC_LCD.1 Developer defined life-cycle
model
ALC_TAT.1 Well-defined development tools
ASE: Security Target evaluation ASE_CCL.1 Conformance claims
ASE_ECD.1 Extended components definition
ASE_INT.1 ST introduction
ASE_OBJ.2 Security objectives
ASE_REQ.2 Derived security requirements
ASE_SPD.1 Security problem definition
ASE_TSS.1 TOE summary specification
ATE: Tests ATE_COV.2 Analysis of coverage
ATE_DPT.1 Testing: basic design
ATE_FUN.1 Functional testing
ATE_IND.2 Independent testing - sample
AVA: Vulnerability assessment AVA_VAN.5 Vulnerability analysis
Table 11: Chosen Evaluation Assurance Requirements
These assurance components represent EAL 3 augmented by the components marked in bold
text. The complete text for these requirements can be found in [3].
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 62 of 74 Federal Office for Information Security
6.3 Security Requirements Rationale
6.3.1 Security Functional Requirements Rationale
The following table provides an overview for security functional requirements coverage:
O.ACCESS_CONTROL
O.PIN_ENTRY
O.I&A
O.MANAGEMENT
O.SECURE_CHANNEL
O.STATE
O.PROTECTION
FCS_CKM.1/Connector X
FCS_CKM.1/Management X
FCS_CKM.4 X X X
FCS_COP.1/Con_Sym X
FCS_COP.1/SIG X
FCS_COP.1/Management X
FCS_COP.1/SIG_FW X
FCS_COP.1/SIG_TSP X
FDP_ACC.1/Terminal X X X
FDP_ACC.1/Management X
FDP_ACF.1/Terminal X X X
FSP_ACF.1/Management X
FDP_IFC.1/PIN X
FDP_IFF.1/PIN X
FDP_IFC.1/NET X
FDP_IFF.1/NET X
FDP_RIP.1 X
FIA_AFL.1 X
FIA_ATD.1 X
FIA_SOS.1 X
FIA_UAU.1 X
FIA_UAU.5 X
FIA_UAU.7 X
FIA_UID.1 X
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 63 of 74
O.ACCESS_CONTROL
O.PIN_ENTRY
O.I&A
O.MANAGEMENT
O.SECURE_CHANNEL
O.STATE
O.PROTECTION
FMT_MSA.1/Terminal X X
FMT_MSA.1/Management X
FMT_MSA.2 X X
FMT_MSA.3/Terminal X X
FMT_MSA.3/Management X
FMT_SMF.1 X
FMT_SMR.1 X
FPT_TST.1 X
FPT_FLS.1 X
FPT_ITT.1 X
FPT_PHP.1 X
FTA_TAB.1/SEC_STATE X
FTP_ITC.1/Connector X
FTP_TRP.1/Management X
Table 12: Coverage of Security Objective for the TOE by SFR
The Security Objective O.ACCESS_CONTROL is met by a combination of the SFR
FDP_ACC.1/Terminal, FDP_ACF.1/Terminal, FMT_MSA.1/Terminal and
FMT_MSA.3/Terminal. FDP_ACC.1/Terminal defines the access control policy for the
terminal and FDP_ACF.1/Terminal defines the rules for the access control policy. It is
specifically defined in FDP_ACF.1/Terminal that nobody must be allowed to read out the
PIN or private cryptographic keys from the terminal. FMT_MSA.1/Terminal defines, who will
be allowed to manage the attributes for the access control policy while FMT_MSA.3/Terminal
defines that the terminal has to provide restrictive default values for the access control policy
attributes.
The Security Objective O.PIN_ENTRY is met by a combination of the SFR
FDP_ACC.1/Terminal, FDP_ACF.1/Terminal, FDP_IFC.1/PIN, FDP_IFF.1/PIN, and
FIA_UAU.7. As part of the access control policy of the terminal FDP_ACC.1/Terminal and
FDP_ACF.1/Terminal define that nobody must be able to read out the PIN from the terminal,
which is required by O.PIN_ENTRY. FDP_IFC.1/PIN and FDP_IFF.1/PIN build an
information flow control policy for the PIN and define that the PIN, which is entered by the
user, will only be sent to the card slot as indicated. Finally, FIA_UAU.7 requires that the PIN
digits are presented as asterisks on the display.
The Security Objective O.I&A is met by a combination of FIA_AFL.1, FIA_ATD.1,
FIA_UAU.1, FIA_UAU.5, FIA_UID.1 and FMT_SMR.1. FIA_AFL.1 requires that the
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 64 of 74 Federal Office for Information Security
password policy is enforced. FIA_UID.1 and FIA_UAU.1 require each user to be
authenticated and identified before allowing any relevant actions on behalf of that user.
Further the objective requires that the TOE will at least maintain the roles, TOE administrator
and TOE Reset Administrator. This is defined in FMT_SMR.1, which defines the roles and
FIA_ATD.1, which defines the user attribute for the role. FIA_UAU.5 defines all the
authentication mechanism that shall or can be implemented by the TOE, in particular for local
and remote management.
The Security Objective O.MANAGEMENT is met by a combination of
FCS_CKM.1/Management, FCS_CKM.4, FCS_COP.1/Management, FCS_COP.1/SIG_FW,
FCS_COP.1/SIG_TSP, FDP_ACC.1/Terminal, FDP_ACF.1/Terminal,
FDP_ACC.1/Management, FDP_ACF.1/Management, FIA_SOS.1, FMT_MSA.1/Terminal,
FMT_MSA.1/Management, FMT_MSA.2, FMT_MSA.3/Terminal, FMT_MSA.3/Management,
FMT_SMF.1, and FTP_TRP.1/Management. FCS_CKM.1/Management requires that
adequate keys are generated for remote management communication. FCS_CKM.4 requires
that keys are adequately destroyed. FCS_COP.1/Management requires that remote
management shall enforce TLS. FCS_COP.1/SIG_FW is used to define the mechanism to
check the authenticity of a firmware update. FCS_COP.1/SIG_TSP is used to define the
mechanism to check the authenticity of a TSP CA list update. The access control policy
defined in FDP_ACC.1/Terminal and FDP_ACF.1/Terminal define the rules under which a
firmware update is possible. FDP_ACC.1/Management and FDP_ACF.1/Management define
the access control policy that determines under what circumstance a particular management
function is accessible and by whom. FIA_SOS.1 defines the password policy for management
credentials. FMT_MSA.1/Terminal and FMT_MSA.1/Management define, which roles are
allowed to administer the attributes of the access control and the information flow control
policies. FMT_MSA.2 requires that only secure values are accepted for security attributes.
FMT_MSA.3/Terminal defines that the terminal has to provide restrictive default values for
the terminal access control policy attributes. FMT_MSA.3/Management defines that the
terminal has to provide restrictive default values for the management access control policy
attributes. FMT_SMF.1 describes the minimum set of management functionality, which has to
be available according to the Security Objective. Finally, FTP_TRP.1/Management defines
the trusted path between the TOE and the management client.
The Security Objective O.SECURE_CHANNEL is met by a combination of the SFR
FCS_CKM.1/Connector, FCS_CKM.4, FCS_COP.1/Con_Sym, FCS_COP.1/SIG,
FDP_IFF.1/NET and FDP_IFC.1/NET., FMT_MSA.2, and FTP_ITC.1/Connector.
FCS_CKM.1/Connector, FCS_COP.1/Con_Sym, and FCS_COP.1/SIG define the
cryptographic operations, which are necessary for this objective. FCS_CKM.1/Connector
defines that the TOE has to be able to generate (negotiate) cryptographic keys, which can be
used to secure the communication with the connector. FCS_CKM.4 defines the functionality
to securely destroy cryptographic keys. The information flow control policy in
FDP_IFF.1/NET and FDP_IFC.1/NET defines that at the network interface only a command
to locate the TOE may be available without an encrypted connection and that all other
communications must only be accepted if the secure channel to the connector has been
established before. FMT_MSA.2 defines that only secure values shall be used for security
attributes. Finally FTP_ITC.1/ Connector defines the trusted channel itself, which is used to
secure the communication between the TOE and the connector.
O.STATE is directly and completely met by FTA_TAB.1/SEC_STATE as this SFR requires
that the TOE shall be able to indicate, whether it is working in a secure state.
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 65 of 74
The Security Objective O.PROTECTION is met by a combination of the SFR FCS_CKM.4,
FDP_RIP.1, FPT_ITT.1, FPT_PHP.1, FPT_FLS.1 and FPT_TST.1.
FCS_CKM.4 defines that cryptographic keys have to be securely deleted when they are no
longer used. FDP_RIP.1 defines the same additionally for the PIN and also ensures that an
attacker cannot read other protected information from the TOE even if the TOE is no longer
in its protected environment. FPT_ITT.1 defines that the TOE has to protect TSF data when it
is transmitted between physically separated parts of one TOE. FPT_PHP.1 builds the physical
protection for the stored assets. FPT_TST.1 defines the necessary test functionality for the
underlying abstract machine. FPT_FLS.1 defines a list of failures in the TSF for which the
TOE has to preserve a secure state. Finally FPT_TST.1 defines that the TSF have to run a
suite of self-tests to demonstrate the correct operation of the TSF at start-up and during the
normal operation of the TOE.
6.3.2 SFR Dependency Rationale
SFR Dependencies Support of the
Dependencies
FCS_CKM.1/Conn
ector
[FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
Fulfilled by the use
of FCS_CKM.4
FCS_CKM.1/Mana
gement
[FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
Fulfilled by the use
of
FCS_COP.1/Mana
gement and
FCS_CKM.4
FCS_CKM.4 [FDP_ITC.1 Import of user data without security
attributes, or
FDP_ITC.2 Import of user data with security
attributes, or
FCS_CKM.1 Cryptographic key generation]
Fulfilled by the use
of
FCS_CKM.1/Conn
ector
FCS_CKM.1/Man
agement
FCS_COP.1/Con_S
ym
[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
Fulfilled by the use
of
FCS_CKM.1/Conn
ector and
FCS_CKM.4
FCS_COP.1/SIG [FDP_ITC.1 Import of user data without security
attributes, or
FDP_ITC.2 Import of user data with security
attributes, or
Fulfilled by the use
of
FCS_CKM.1/Conn
ector and
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 66 of 74 Federal Office for Information Security
SFR Dependencies Support of the
Dependencies
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.4
FCS_COP.1/Manag
ement
[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
Fulfilled by the use
of
FCS_CKM.1/Man
agement and
FCS_CKM.4
FCS_COP.1/SIG_F
W
[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
See chapter 6.3.2.1
for FDP_ITC.1
and FCS_CKM.4
FCS_COP.1/SIG_T
SP
[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
See chapter 6.3.2.1
for FDP_ITC.1
and FCS_CKM.4
FDP_ACC.1/Termi
nal
FDP_ACF.1 Security attribute based access
control
Fulfilled by
FDP_ACF.1/Termi
nal
FDP_ACC.1/Mana
gement
FDP_ACF.1 Security attribute based access
control
Fulfilled by
FDP_ACF.1/Mana
gement
FDP_ACF.1/Termi
nal
FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialization
Fulfilled by
FDP_ACC.1/Term
inal and
FMT_MSA.3/Ter
minal
FDP_ACF.1/Mana
gement
FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialization
Fulfilled by
FDP_ACC.1/Mana
gement and
FMT_MSA.3/Man
agement
FDP_IFC.1/PIN FDP_IFF.1 Simple security attributes Fulfilled by
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 67 of 74
SFR Dependencies Support of the
Dependencies
FDP_IFF.1/PIN
FDP_IFF.1/PIN FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
Fulfilled by
FDP_IFC.1/PIN
See chapter 6.3.2.1
for FMT_MSA.3
FDP_IFC.1/NET FDP_IFF.1 Simple security attributes Fulfilled by
FDP_IFF.1/NET
FDP_IFF.1/NET FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
Fulfilled by
FDP_IFC.1/NET
See chapter 6.3.2.1
for FMT_MSA.3
FDP_RIP.1 No dependencies -
FIA_AFL.1 FIA_UAU.1 Timing of authentication Fulfilled by
FIA_UAU.1
FIA_ATD.1 No dependencies -
FIA_SOS.1 No dependencies -
FIA_UAU.1 FIA_UID.1 Timing of identification Fulfilled by
FIA_UID.1
FIA_UAU.5 No dependencies -
FIA_UAU.7 FIA_UID.1 Timing of identification Fulfilled by
FIA_UID.1
FIA_UID.1 No dependencies -
FMT_MSA.1/Term
inal
[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
Fulfilled by
FDP_ACC.1/Term
inal, FMT_SMR.1
and FMT_SMF.1
FMT_MSA.1/Mana
gement
[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
Fulfilled by
FDP_ACC.1/Mana
gement,
FMT_SMR.1 and
FMT_SMF.1
FMT_MSA.2 [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
Fulfilled by
FPD_ACC.1/Term
inal,
FPD_ACC.1/Mana
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 68 of 74 Federal Office for Information Security
SFR Dependencies Support of the
Dependencies
FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
gement
FDP_IFC.1/PIN,
FDP_IFC.1/NET,
FMT_MSA.1/Ter
minal, and
FMT_SMR.1
FMT_MSA.3/Term
inal
FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
Fulfilled by
FMT_MSA.1/Ter
minal and
FMT_SMR.1
FMT_MSA.3/Mana
gement
FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
Fulfilled by
FMT_MSA.1/Man
agement and
FMT_SMR.1
FMT_SMF.1 No dependencies -
FMT_SMR.1 FIA_UID.1 Timing of identification Fulfilled
FIA_UID.1
FPT_TST.1 No dependencies -
FPT_FLS.1 No dependencies -
FPT_ITT.1 No dependencies -
FPT_PHP.1 No dependencies -
FTA_TAB.1/SEC_
STATE
No dependencies -
FTP_ITC.1/Connec
tor
No dependencies -
FTP_TRP.1/Manag
ement
No dependencies -
Table 13: Dependencies of the SFR for the TOE
6.3.2.1Justification for missing dependencies
The dependencies of the information flow policies FDP_IFF.1/PIN and FDP_IFF.1/NET to
FMT_MSA.3 was considered to be not applicable as both information flow policies do not
require initialisation of their security attributes.
For the case that the ST author would extend these information flow policies in a way that
they require security attributes they shall consider the dependency to FMT_MSA.3.
The dependencies FDP_ITC.1 and FMT_MSA.2 of FCS_COP.1/SIG_FW and
FCS_COP.1/SIG_TSP result out of the original scope of FCS_COP.1 to specify the
implementation of encryption functionality within a TOE. These dependencies deal with the
import (or creation) and destruction of a secret key that is needed for encryption. However, as
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 69 of 74
in the context of this PP FCS_COP.1/SIG_FW and FCS_COP.1/SIG_TSP are used for a
requirement on signature verification for which no secret key is necessary these dependencies
do not need to be considered.
6.3.3 Security Assurance Requirements Rationale
The Evaluation Assurance Level for this Protection Profile is EAL 3 augmented by
ADV_FSP.4, ADV_IMP.1, ADV_TDS.3, ALC_TAT.1 and AVA_VAN.5.
The main decision about the Evaluation Assurance Level has been taken based on the fact that
the TOE described in this Protection Profile shall serve as a secure PIN entry device
according to [6] and [7] (see also OSP.SIGG).
This leads to an Evaluation Assurance Level of 3 augmented by the following component:
AVA_VAN.5
ALC_TAT.1
These components have the following direct and indirect dependencies:
ADV_FSP.4
ADV_TDS.3
ADV_IMP.1
6.3.4 Security Requirements – Mutual Support and Internal Consistency
The core TOE functionality in this PP is represented by the requirements for access control
(FDP_ACC.1 and FDP_ACF.1) and information flow control (FDP_IFC.1/PIN,
FDP_IFF.1/PIN, FDP_IFC.1/NET and FDP_IFF.1/NET).
Further functionality to protect the communication is defined by the requirements for
cryptographic support and the trusted channel.
In the end this PP contains a set of SFRs which deal with the detection and defeating of
attacks to the TOE, resp. SFRs which are used to show that the TOE is working correctly (e.g.
FPT_PHP.1, FPT_TST.1). By this way the SFRs in this PP mutually support each other and
form a consistent whole.
From the details given in this rationale it becomes evident that the functional requirements
form an integrated whole and, taken together, are suited to meet all security objectives.
Requirements from [2] are used to fulfil the security objectives.
6.4 Extended Functionality
It is also possible that a card terminal provides random additional functionality the so called
value-added modules (VAM) (see also [19]). There are two different approaches to include
VAM:
By including VAM into the same firmware that is used for other TOE functionality, or
By including VAM into separate firmware.
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 70 of 74 Federal Office for Information Security
In the first approach VAM would have to be considered during evaluation. The developer
would have to argue why the VAM do not interfere with the TSF. In the second approach,
there is probably no information on the aspect of interference as VAM could be brought into
the card terminal after evaluation. In this case, the TOE would have to provide adequate
separation mechanisms to ensure that VAM are not able to interfere with the TSF: The
enforcement of separation requires additional security functionality which would have to be
modelled by the ST author.
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 71 of 74
7 Glossary and Acronyms
Term Definition
AES Advanced Encryption Standard
BSI Bundesamt für Sicherheit in der Informationstechnik
CA Certification Authority
DF.KT Dedicated File Kartenterminal
eHC Electronic Health Card
gSMC-KT Gerätesepzifische Security Module Card Type Kartenterminal
HPC Health Professional Card
KSR Configuration and Software Repository- Service of the telematics
infrastructure
LAN Local Area Network
PIN Personal Identification Number
PP Protection Profile
PUK Personal Unblocking Key
SAC Signature Application Component
SFP Security Function Policy
SFR Security Functional Requirement
SICCT Secure Interoperable ChipCard Terminal
SM-KT Security Module Kartenterminal
SMC-B Security Module Card Typ B
ST Security Target
TOE Target of Evaluation
TSF TOE Security Function
TSP Trust-Service Provider that issues connector certificates
VAM Value-added module
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 72 of 74 Federal Office for Information Security
8 Literature
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 components; CCMB-2012-09-003, Version 3.1, Revision 4, September
2012
[4] Common Methodology for Information Technology Security Evaluation, Evaluation
methodology, CCMB-CCMB-2012-09-004, Version 3.1, Revision 4, September
2012
[5] AIS 27, Version 5, Transition from ITSEC to CC, Certification body of the BSI in
the context of the certification scheme, August, 17th 2010
Cryptography
[6] Signaturgesetz vom 16. Mai 2001 (BGBl. I S. 876), das zuletzt durch Artikel 4
Absatz 111 des Gesetzes vom 7. August 2013 (BGBl. I S. 3154) geändert worden ist
[7] Signaturverordnung vom 16. November 2001 (BGBl. I S. 3074), die zuletzt durch
Artikel 4 Absatz 112 des Gesetzes vom 7. August 2013 (BGBl. I S. 3154) geändert
worden ist
[8] BSI TR-03116, Technische Richtlinie für die eCard-Projekte der Bundesregierung,
Version 3.14, 26.04.2012
[9] BSI TR-03120, Technische Richtlinie „Sichere Kartenterminalidentität (incl.
Kartenterminalschutz)“, in ist current version31
[10] BSI TR-03120 Appendix, „Anhang: Kartenterminalschutz“ zur Technischen
Richtlinie BSI TR-03120, Version 1.1
[11] RFC 3268 Advanced Encryption Standard (AES) Ciphersuites for Transport Layer
Security (TLS), June 2002, http://www.ietf.org/rfc/rfc3268.txt
[12] RFC4346 The TLS Protocol, Version 1.1
[13] RFC5246 The TLS Protocol, Version 1.2
31 Transitional arrangement: It is sufficient to fulfil version 1.0 of TR-03120 and version 1.0.2 of its amendment
a) in case of an initial certification:
if an application for the issuance of a certificate based on a lower version than 3.0 of this PP was
requested from BSI before 30 May 2013 and an application for the issuance of a certificate based on
version 3.0 or higher of this PP was requested from BSI before 01 April 2014,
b) in case of a re-certification:
if an application for the issuance of a certificate based on this PP is requested from BSI before 01
April 2019 and the TOE has been certified according this PP before and changes compared to certified
TOE versions concern only software modifications.
Common Criteria Protection Profile Version 3.6., 10th
September 2015
Federal Office for Information Security Page 73 of 74
[14] RFC3447 Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography
Specifications Version 2.1
[15] RFC3546 Transport Layer Security (TLS) Extensions
[16] Federal Information Processing Standards Publication 180-2 SECURE HASH
STANDARD U.S. DEPARTMENT OF COMMERCE/National Institute of
Standards and Technology, 2002 August 1
[17] Common Criteria Protection Profile Card Operating System Generation 2 (PP COS
G2), BSI-CC-PP-0082, Bundesamt für Sicherheit in der Informationstechnik (BSI)
[18] Common Criteria Protection Profile - Schutzprofil 2: Anforderungen an den
Konnektor Online-Rollout (Stufe 1), BSI-CC-PP-0046, Bundesamt für Sicherheit in
der Informationstechnik (BSI)
Protection Profile – Electronic Health Card Terminal (eHCT)
Page 74 of 74 Federal Office for Information Security
Specifications
[19] gematik: Spezifikation eHealth-Kartenterminal, Version 3.5.0, Stand 17.06.2014
[20] TeleTrusT SICCT-Spezifikation as referenced by [19]
[21] gematik: Spezifikation der gSMC-KT Objektsystem, Version 3.7.0, Stand
26.08.2014