security target lite - common criteria · uekae dirak serisi hsm (hardware security module) flow...
TRANSCRIPT
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
TÜBİTAK UEKAE
ULUSAL ELEKTRONİK & KRİPTOLOJİ ARAŞTIRMA ENSTİTÜSÜ
HSM PROJECT
UEKAE Dirak Serisi HSM (HARDWARE SECURITY MODULE)
Flow Control Firmware V2.13
SECURITY TARGET LITE
Revision No 06
Revision Date 05.04.2013
Document Code HSM-ST-LITE
File Name HSM_UEKAE_ST.doc
Prepared by
Development Engineer Ahmet Remzi ÖZCAN
Approved by
Project Manager Mustafa Ümit ÇEŞMECİ
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 2.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
Revision
No Revision Reason Date of Revision
01 First Publication 31.05.2010
02 Review 21.05.2012
03 Review 06.12.2012
04 Product Name Change 12.12.2012
05 Review 12.12.2012
06 Lite Version 05.04.2013
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 3.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
CONTENT
1. CHAPTER 1: SECURITY TARGET INTRODUCTION .................................................... 7
1.1 Security Target Reference .......................................................................................................... 7
1.2 TOE Reference ........................................................................................................................... 7
1.3 TOE Overview ........................................................................................................................... 7
1.4 TOE DESCRIPTION ................................................................................................................. 8
2. CHAPTER 2: CONFORMANCE CLAIMS ........................................................................ 11
2.1 Common Criteria Conformance ............................................................................................... 11
2.2 Evaluation Assurance Level Package Conformance ................................................................ 11
2.3 Protection Profile Conformance ............................................................................................... 11
2.4 Conventions .............................................................................................................................. 11
3. CHAPTER 3: SECURITY ENVIRONMENT ..................................................................... 12
3.1 Introduction .............................................................................................................................. 12
3.2 Assumptions ............................................................................................................................. 12
3.3 Threats ...................................................................................................................................... 12
3.4 Organizational Security Policies .............................................................................................. 13
4. CHAPTER 4: SECURITY OBJECTIVES .......................................................................... 14
4.1 Security Objectives for the TOE .............................................................................................. 14
4.2 Security Objectives for the IT Environment ............................................................................ 14
4.3 Security Objectives for the Non-IT Environment .................................................................... 15
5. CHAPTER 5: SECURITY REQUIREMENTS .................................................................. 16
5.1 TOE Security Functional Requirements ................................................................................... 16
5.2 TOE Security Assurance Requirements ................................................................................... 22
5.3 CC Component Hierarchies and Dependencies ....................................................................... 22
6. CHAPTER 6: TOE SUMMARY SPECIFICATION .......................................................... 25
6.1 TOE Security Functions ........................................................................................................... 25
6.2 Assurance Measures ................................................................................................................. 25
7. CHAPTER 7: PROTECTION PROFILE ........................................................................... 29
7.1 Protection Profile Rationale ..................................................................................................... 29
8. CHAPTER 8: RATIONALE ................................................................................................. 30
8.1 Rationale for IT and Environmental Security Objectives ........................................................ 30
8.2 Security Requirements Rationale ............................................................................................. 34
8.3 TOE Summary Specification Rationale ................................................................................... 37
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 4.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
LIST OF TABLES
Table 1 – TOE Functional Security Requirements ..................................................................... 16
Table 2 – Assurance Requirements ............................................................................................. 22 Table 3 – TOE SFR Dependency Rationale ................................................................................ 24 Table 4 – EAL4+ Assurance Measures ....................................................................................... 28 Table 5 – Threats,Assumptions and Policies to Security Objectives Mapping ........................... 30 Table 6 – Threats to Security Objectives Rationale .................................................................... 32
Table 7 – Assumptions to Security Objectives Rationale ........................................................... 33 Table 8 – OSPs to Security Objectives Rationale ....................................................................... 33 Table 9 – SFRs to Security Objectives Mapping ........................................................................ 34 Table 10 – Security Objectives to SFR Rationale ....................................................................... 37
Table 11 – SFRs to TOE Security Functions Mapping ............................................................... 38 Table 12 – SFR to SF Rationale .................................................................................................. 39
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 5.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
LIST OF FIGURES
Figure 1 Pysical Boundary of the TOE ................................................................................... 9 Figure 2 HSM device and TOE Life Cycle Phases .............................................................. 10
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 6.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
ACRONYMS LIST
AES........................................................................................... Advanced Encryption Standard
API ..............................................................................................Application Program Interface
CC................................................................................................................... Common Criteria
CM...................................................................................................Configuration management
DES.................................................................................................... Data Encryption Standard
EAL4........................................................................................... Evaluation Assurance Level 4
FIPS ........................................................................... Federal Information Processing Standard
FPGA……………………………………………………….... Field Programmable Gate Array
HSM................................................................................................. Hardware Security Module
IT...........................................................................................................Information Technology
MAC ........................................................................................... Message Authentication Code
NIST................................................................. National Institute of Standards and Technology
NVRAM……………………………………………… Non-Volatile Random Access Memory
PCI-E......................................................................Peripheral Component Interconnect Express
PKI ...................................................................................................... Public Key Infrastructure
RNG.................................................................................................Random Number Generator
RSA............................................................................................... Rivest, Shamir and Adleman
SF.................................................................................................................... Security Function
SFP.......................................................................................................Security Function Policy
SHA .......................................................................................................Secure Hash Algorithm
SOF .............................................................................................................Strength of Function
ST........................................................................................................................ Security Target
TOE.............................................................................................................Target of Evaluation
TSC .......................................................................................................... TSF Scope of Control
TSF......................................................................................................... TOE Security Function
TSFI ...................................................................................................................... TSF Interface
TSP............................................................................................................. TOE Security Policy
UEKAE……………………………………Ulusal Elektronik ve Kriptoloji Araştırma Ensitüsü
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 7.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
1. CHAPTER 1: SECURITY TARGET INTRODUCTION
1.1 Security Target Reference
UEKAE Dirak Serisi HSM (HARDWARE SECURITY MODULE) Flow Control Firmware
V2.13 Security Target Lite revision 06, 05.04.2013.
1.2 TOE Reference
TOE is UEKAE Dirak Serisi HSM (HARDWARE SECURITY MODULE) Flow Control
Firmware V2.13. Hereafter TOE is referred as TUBITAK-UEKAE HSM.
1.3 TOE Overview
UEKAE Dirak Serisi HSM device is a PCI-e module that provides physical and logical
protection for the cryptographic keys and confidential data of critical applications. It enhances
security for industry standard computing platforms and provides cryptographic hardware
acceleration. The HSM protects cryptographic keys and data from environmental threats, thanks
to its highly secure, tamper-resistant hardware design. In case of intrusion attempt the system
detects this event and clears all confidential keys and data.
TOE is a data flow control firmware on UEKAE Dirak Serisi HSM device. This firmware is
composed of several applications working on an embedded operating system. This operating
system is running on a processor located on UEKAE Dirak Serisi HSM device.
TOE supports the following functionalities;
Digital signature, data encryption and digital rights management using the following
cryptographic algorithms;
RSA Public key standard with up to 2048 bit key length,
Symmetric key encryption AES, DES,
HASH Functions SHA-1, SHA-256.
Storage of confidential keys and data on a high capacity (32 Mbit) temper-resistant
memory,
Robust key generation, using a hardware random number generator (RNG) following
FIPS 140-2, according to FIPS 186-2 specifications,
Secure backup, restore and transfer of keys and data,
Emergency erase,
Secured software update.
Among the above mentioned cryptographic functions, Diffie-Hellman, DSA, AES, DES, SHA-
1, SHA-256 cryptographic operations are performed using Open SSL library functions which
are not parts of the TOE. Moreover, RSA cryptographic operations are performed on the FPGA,
on the HSM card. This RSA implementation and the hardware RNG are also not included in the
TOE.
UEKAE Dirak Serisi HSM device can be used on Server or PC. TOE provide hardware
protection to critical applications such as public key infrastructures (PKIs), databases, web and
application servers. Due to HSM device hardware acceleration, customers take advantage of
performance increases for cryptographic operations, such as RSA signatures. UEKAE Dirak
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 8.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
Serisi HSM device can be used by government agencies, banks and financial services,
technology companies etc.
1.4 TOE DESCRIPTION
This section provides a general description of the UEKAE Dirak Serisi HSM device and
describes the Target of Evaluation (TOE) according to the type of product, the operational
environment, and the provided security functionality.
1.4.1 Introduction
TOE is a data flow control firmware on an Atmel ARM 9 processor on UEKAE Dirak Serisi
HSM device. On this processor, limited command set Linux kernel (version 2.6.32.9) is
installed. This kernel also include MIRACL (version 5.4.1) and Open SSL (version 0.9.8)
libraries for mathematical and cryptographic operations. On the HSM device, to accelerate
public key cryptographic operations the RSA algorithm is implemented on an FPGA and used
by TOE. Consequently, TOE is an application packet that runs on the Linux operating system
and uses above mentioned cryptographic resources to produce and protect cryptographic
variables (keys, initial vectors etc.) and proceed cryptographic functions. TOE uses these
resources in a secure way.
TOE basically manages dataflow between PKCS#11 command interface (for communicating to
host computer), FPGA based RSA2048 algorithm, Open SSL library, True Noise Generator (for
cryptographic variable production), secure memory (for cryptographic variable protection) and
SIM Card in a secure way.
UEKAE Dirak Serisi HSM device has a PCIe x1 interface for being used by the host computer.
PKCS#11 commands, sent by the user software, come to UEKAE Dirak Serisi HSM device
and consequently to TOE via this interface. These commands are to be converted to UEKAE-
HSM data command format by a driver software on the host computer.
The basic function of TOE is proceeding PKCS#11 commands coming from PCIe x1 interface.
The user adds PKCS#11 commands in his software code (or directly calls), driver software
converts these commands into UEKAE-HSM data command format. Next, TOE performs these
commands. In addition, there are dedicated management commands for management of HSM
device as authentication, initializing, backup, emergency erase etc. Dedicated management
commands are already in UEKAE-HSM data command format and they do not need to be
converted. The HSM management software on the host computer calls these management
functions and the user does not need to know these commands.
1.4.2 Initialization of UEKAE Dirak Serisi HSM device
UEKAE Dirak Serisi HSM device and its Initialization Card have factory initialization.
Initialization Card and its PIN/PUK codes are produced by UEKAE special to HSM device.
This card is necessary for HSM initialization process. On the initialization stage, Administrator
Card is produced; Back-up card could be produced as well.
1.4.3 Roles
For HSM device two type of users are described; that is Administrator and User. Administrator
is the authorized person for software update and new user definition process. User has
authorization only on permitted process execution. Users and Administrator login to device by
using User Card and its password. User cards and its passwords are produced by Administrator
durig user definition process.
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 9.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
1.4.4 Physical Scope of UEKAE Dirak Serisi HSM device and phsical Boundry of TOE
UEKAE Dirak Serisi HSM device is a PCI-e module that is integrated with a server. It includes
a processor, FPGA, secure memory and hardware noise generator. The TOE executes on the
processor. Cryptographic algorithm acceleration, random number generation and PCI-e
communication modules exist on the FPGA. To prevent any intrusion, the processor, FPGA,
secure memory and other electronic components covered with epoxy filled protective steel. In
addition to the PCI-e connection, the HSM also have two USB buses for smart card reader
connection and data transfer operations. For random number generating process according to
FIPS 186-2 specifications, HSM device uses a hardware noise generator.
The relationships between the components of the system presented as block diagram on Figure
2. On the block diagram, the physical boundary of the TOE also depicted. White filled boxes
symbolize hardware components on the system while yellow filled boxes symbolize software
entities. The physical boundary of TOE that consists of HSM applications running on the
embedded Linux OS and tamper-resistant RAM, illustrated with blue box on the diagram.
Figure 1 Pysical Boundary of the TOE
1.4.5 Logical Scope of the TOE
The HSM applications running on an embedded Linux Operating System that has limited
command set. In addition to standart libraries, this Linux compilation includes specific libraries;
Open SSL for cryptographic functions as calculation of message digest (MD5, SHA-1),
encryption and decryption with ciphers (AES), creation of public key parameters (RSA),
MIRACL Version 5.4.1 to perform complicated mathematical functions Besides these
supporting libraries, the HSM applications use the FPGA based cryptographic algorithm
accelerator for RSA 2048 encryption/decryption process. The TOE doesn’t include these
cryptographic resources, just uses them in a secure way.
Life cycle of HSM Device and TOE: The HSM’s life cycle process consists of some certain
phases. Relations between these life cycle phases are shown as a diagram in Figure 4. There are
4 different life cycle phases available on TOE. In the Base Phase, the HSM is just manufactured
as hardware; does not store any key or data. In the Production Phase system’s software, HSM
applications and essential keys have been loaded to HSM hardware. The transition processes
from Base Phase to Initialization Phase are actualized on Manufacturer.
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 10.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
Figure 2 HSM device and TOE Life Cycle Phases
An HSM product comes to user on initialization phase with an initialization card and its
password. This initialization card and its password are created by manufacturer special to
device in production phase. A couple of unique keys are created on this process: Initialization
Public Key and Initialization Private Key. The Initialization Public Key is loaded on the HSM
hardware and private one is loaded on the initialization card. In the initialization phase, HSM
checks the integrity of this private key that is stored in the initialization card by public key. In
case of any failure, initialization process is aborted.
TOE life cycle comprise HSM life cycle’s two phases these are initialization phase and
operation phase. On initialization phase only initialization command is performed by TOE.
Other management commands and PKCS#11 commands are not operated. If initialization
process is success with pluged initialization card and typed password, TOE passes to operation
phase. On operation phase, for performing PKCS#11 commands a user must login to TOE.
TOE is logged in until receiving logout command or HSM device power down. Even host
computer restart because of any operating system error, TOE continues to run and is loged in.
(as long as power is up)
Return from operation phase to initializaiton phase is occurred only emergency erase command.
In this instance all confidential keys and datas are erased. To use TOE again, re-initializaiton is
necessary.
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 11.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
2. CHAPTER 2: CONFORMANCE CLAIMS
2.1 Common Criteria Conformance
The TUBITAK-UEKAE HSM is compliant with the Common Criteria (CC) Version 3.1 rev3,
functional requirements (Part 2) conformant and assurance requirements (Part 3) conformant
2.2 Evaluation Assurance Level Package Conformance
Assurance claims conform to EAL4+ (Evaluation Assurance Level 4) from the Common
Criteria for Information Technology Security Evaluation (ISO 15408), Version 3.1 rev3
augmented (ALC_DVS.2)
2.3 Protection Profile Conformance
The TUBITAK-UEKAE HSM does not claim conformance to any registered Protection Profile.
2.4 Conventions
The CC defines operations on security requirements. The font conventions listed below state the
conventions used in this ST to identify the operations.
Assignment: indicated in italics and begin with assignment
Selection: indicated in italics and begin with selection
Assignments within selections: indicated in italics and begin with assignment
Refinement: begin with Refinement in bold text
Iterations of security functional requirements may be included. If so, iterations are specified at
the component level and all elements of the component are repeated. Iterations are identified by
numbers in parentheses following the component or element (e.g., FDP_IFF.1).
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 12.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
3. CHAPTER 3: SECURITY ENVIRONMENT
3.1 Introduction
This section provides the statement of the TOE security environment, specifically following:
A. Assumption about the TOE’s operational environment,
B. Known and presumed threats,
C. Organisational security policies the TOE must comply with
This chapter identifies assumptions as A.assumption, threats as T.threat and policies as
P.policy.
3.2 Assumptions
The specific conditions listed in the following table are assumed to exist in the operational
environment.
A.CONNECT The PC on which the TOE is running is not connected directly
to an untrusted network, either assumed not to be coonected to
any networks or it is connected to a trusted network which is
protected malicious attacks.
A.INSTALL The Administrator will install and configure the TOE according
to the administrator guidance.
A.NOEVIL Administrator of the TOE are assumed to be responsible, non-
hostile individuals who will follow by the instruction provided
by TOE documentation.
A.PHYSICAL The TOE will be located in an environment that is physically
protected and well management.(stable power, acceptable
temperature) Only the autherized user of the TOE has physical
access.
A.PLATFORM The Administrator will ensure that the platforms used to host the
TOE conform to the hardware and software outlined in the
administrator guidance.
3.3 Threats
The threats identified in this section are addressed by the TOE.
T.BYPASS An unauthorized person may attempt to bypass the security
mechanisms of the TOE because of a defect in the TOE
functioning.
T.CAPTURE The data transmitted from the TOE to IT environment may be
captured by a malicious user by monitoring data bus.
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 13.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
T.DISARRANGE Data may be disarranged as a result of IT environment driver
error while traversing the connection between TOE and the IT
environment.
T.INF_LEAK An unauthorized person may gather residual information from
previous information flow or internal TOE data by monitoring
the padding of the information flows from TOE because of a
defect in the TOE functioning.
T.POOR_TEST Lack of or insufficient tests that ran from developer to
demonstrate that all TOE security functions operate correctly
(including in a fielded TOE) may result in incorrect TOE
behavior being discovered thereby causing potential security
vulnerabilities.
T.REPEAT The TOE permit A user or process may repeatedly send
command to the TOE and cause a data corruption or lost
because of a defect in the TOE functioning.
T.UNSECURED_IT The cryptographic entities may not be created correctly or
cryptographic operations may not execute properly because of
unsecured IT environments that used from TOE developer.
3.4 Organizational Security Policies
The organizational security policies identified in the following are addressed by the TOE and/or
the IT environment.
P.EMERGENCY All encryption keys contained in the default key database shall
be deleted in case of emergency.
P.ERASURE All encryption keys contained in the default key database shall
be deleted upon the request of the authorized user.
P.CRYPTOGRAPHY Only NIST FIPS 140-2 validated cryptography (methods and
implementations) are acceptable for key management.
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 14.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
4. CHAPTER 4: SECURITY OBJECTIVES
This section describes the security objectives of the TOE , TOE’s IT environment and non-IT
environment. The security objectives identify the responsibilities of the TOE and its operational
environment in meeting the security needs. Objective of the TOE are identifies as O.objective.
Objectives that apply to the IT environment are appointed as OE.objective. Objectives that
apply to the non-IT environment are appointed with an ON.objective.
4.1 Security Objectives for the TOE
The following are the IT security objectives to be met by the TOE.
O.ACCESS_CONTROL The TOE will store and retrieve information (to authorized
users) related to the user profile and access rights.
O.SECURE_ACCESS The TOE shall ensure that only authorized users are granted
access to the security functions, configuration and associated
data.
O.SELF_PROTECT The TSF will maintain a domain for its own execution that
protects itself and its resources from external interference,
tampering, or unauthorized disclosure.
O.PROTECT_KEYS The TOE will protect cryptographic keys from compromise.
O.ERASURE All encryption keys contained in the HSM database will be
deleted upon the request of the authorized user.
O.REPEAT The TOE will keep received command waiting when it is same
as executed command. Thus the TOE prevent a data corruption
or lost for sending a command repeatedly.
O.FUNC_TEST The TOE will undergo security functional testing that
demonstrates that the TSF satisfies its security functional
requirements.
O.SELF_TEST The TOE will provide functionality to perform integrity testing
of TOE components and stability testing of IT environments
during initial start-up.
4.2 Security Objectives for the IT Environment
The TOE’s IT environment must satisfy the following objectives.
OE.CRYPTOGRAPHY The TOE shall includes any functions that use cryptographic
modules that are all validated at FIPS 140-2 series Level 1 or
higher. This FIPS 140-2 validated module or modules will
perform one or more of the following: key pair generation,
digital signature generation and verification, encryption,
decryption, secure hash and HMAC.
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 15.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
OE.DISCLOSURE The protection of UserData against unauthorised access within
the IT system as well as during the transfer is ensured by the
use of encryption procedures
OE.PROTECT The IT environment protects the TOE, TOE assets and intra-
TOE communications from disclosure, interference, and
tampering.
OE.EMERGENCY All encryption keys contained in the HSMdatabase will
be deleted in case of emergency.
4.3 Security Objectives for the Non-IT Environment
The TOE’s Non-IT environment must satisfy the following objectives.
ON.INSTALL The Administrator will install and configure product’s PC-side
softwares according to the administrator guidance.
ON.ADMIN The TOE Administrators are appropriately trained, not careless,
not willfully negligent, and follow and abide by the instructions
provided in the guidance documentation.
ON.USER The TOE Users are appropriately trained, not careless, not
willfully negligent, and follow and abide by the instructions
provided in the guidance documentation.
ON.PHYSICAL The TOE must be operated in a physically secure and well
managed environment.
ON.PLATFORM The Administrator will ensure that the platforms used to host the
TOE conform to the hardware and software outlined in the
administrator guidance.
ON.CONNECT The PC on which the TOE is running must not be connected
directly to an untrusted network. This means that the PC must
either not be connected to any networks or it must be connected
to a trusted network, which is protected against attacks, so that
no undocumented security critical side effects on the security
functions of the TOE are coming from this network.
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 16.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
5. CHAPTER 5: SECURITY REQUIREMENTS
This section contains the functional requirements that are provided by the TOE. These
requirements consist of functional components from Part 2 of the CC.
5.1 TOE Security Functional Requirements
The functional requirements are described in detail in the following subsections. Additionally,
these requirements are derived verbatim from Part 2 of the Common Criteria for Information
Technology Security Evaluation, Version 3.1 rev3 with the exception of completed operations.
Security Requirement Component
User Data
Protection (FDP)
Subset access control FDP_ACC.1
Security attribute based access control FDP_ACF.1
Export of user data with security attributes FDP_ETC.2
Subset information flow control FDP_IFC.1
Simple Security Attributes FDP_IFF.1
Import of user data with security attributes FDP_ITC.2
Identification and
Authentication
(FIA)
User attribute definition FIA_ATD.1
Timing of authentication FIA_UAU.1
Timing of identification FIA_UID.1
Security
Management
(FMT)
Management of TSF data FMT_MTD.1
Specification of Management Functions FMT_SMF.1
Security roles FMT_SMR.1
Management of security functions behaviour FMT_MOF.1
Protection of the
TSF (FPT)
Testing of external entities FPT_TEE.1
TSF testing FPT_TST.1
Notification of physical attack FPT_PHP.2
Resistance to physical attack FPT_PHP.3
Table 1 – TOE Functional Security Requirements
5.1.1 FDP_ACC.1 Subset access control (hsm database access)
5.1.1.1 FDP_ACC.1.1 The TSF shall enforce the [assignment: HSM database access
control SFP] on [assignment: all users, the HSM database, the
management of the HSM database].
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 17.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
5.1.2 FDP_ACF.1 Security attribute based access control (hsm database access)
5.1.2.1 FDP_ACF.1.1 The TSF shall enforce the [assignment: HSM database access
control SFP] to objects based on the following: [assignment: users,
user smart card and password].
5.1.2.2 FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an
operation among controlled subjects and controlled objects is
allowed: [assignment: the user must use authorized smart card and
enter the correct password to manage the HSM database].
5.1.2.3 FDP_ACF.1.3 The TSF shall explicitly authorise access of subjects to objects based
on the following additional rules: [assignment: none].
5.1.2.4 FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on
the following additional rules: [assignment: none].
5.1.3 FDP_ETC.2 Export of user data with security attributes
5.1.3.1 FDP_ETC.2.1 The TSF shall enforce the [assignment: Backup and Transmission
Model ] when exporting user data, controlled under the SFP(s), from
outside of the TOE
5.1.3.2 FDP_ETC.2.2 The TSF shall export the user data with the user data’s associated
security attributes.
5.1.3.3 FDP_ETC.2.3 The TSF shall ensure that the security attributes, when exported
outside the TOE are unambiguously associated with the exported
user data.
5.1.3.4 FDP_ETC.2.4 The TSF shall enforce the following rules when user data is exported
from the TOE [assignment: the HSM database must be encrypted
and signed. Therefore; the hsm database must be encrypted using
the encryption key, the hsm database must be integrity protected
using HMAC key].
Reference: “Backup and Transmission Model” is described in HSM Projesi Kripto Mimari
Tanım Dökümanı document.
Application Note: This requirement regulates that only encrypted and integrity protected key
files are exported out of the TOE.
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 18.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
5.1.4 FDP_IFC.1 Subset information flow control
5.1.4.1 FDP_IFC.1.1 The TSF shall enforce the [assignment: information flow control
SFP] on [assignment: all user,objects out of which the information
can be read or rather in which the information can be written, and
the operation reading and writing of information]
5.1.5 FDP_IFF.1 Simple Security Attributes
5.1.5.1 FDP_IFF.1.1 The TSF shall enforce the [assignment: information flow control
SFP] based on the following types of subject and information
security attributes: [assignment: TOE management interface, TOE
pkcs#11 interface].
5.1.5.2 FDP_IFF.1.2 The TSF shall permit an information flow between a controlled
subject and controlled information via a controlled operation if the
following rules hold: [assignment: The program code that include
the TSF data verified with program code sign certificate].
5.1.5.3 FDP_IFF.1.3 The The TSF shall enforce the [assignment: none].
5.1.5.4 FDP_IFF.1.4 The TSF shall explicitly authorise an information flow based on the
following rules: [assignment: none].
5.1.5.5 FDP_IFF.1.5 The TSF shall explicitly deny an information flow based on the
following rules: [assignment: none].
5.1.6 FDP_ITC.2 Import of user data with security attributes
5.1.6.1 FDP_ITC.2.1 The TSF shall enforce the [assignment: Restore Model and Access
Control SFP] when importing user data, controlled under the SFP,
from outside of the TOE
5.1.6.2 FDP_ITC.2.2 The TSF shall use the security attributes associated with the
imported user data.
5.1.6.3 FDP_ITC.2.3 The TSF shall ensure that the protocol used provides for the
unambiguous association between the security attributes and the user
data received.
5.1.6.4 FDP_ITC.2.4 The TSF shall ensure that interpretation of the security attributes of
the imported user data is as intended by the source of the user data.
5.1.6.5 FDP_ITC.2.5 The TSF shall enforce the following rules when importing user data
controlled under the SFP from outside the TOE [assignment: none].
Reference: “Restore Model” is described in HSM Projesi Kripto Mimari Tanım Dökümanı
document.
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 19.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
5.1.7 FIA_ATD.1 User attribute definition
5.1.7.1 FIA_ATD.1.1 The TSF shall maintain the following list of security attributes
belonging to individual users: [assignment: user type]
5.1.8 FIA_UAU.1 Timing of authentication
5.1.8.1 FIA_UAU.1.1 The TSF shall allow [assignment:
HSM_CMD_EMERGENCYERASE,
HSM_CMD_DOINITIALIZATION,
HSM_CMD_VERIFYINITCARD] on behalf of the user to be
performed before the user is authenticated.
5.1.8.2 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.
5.1.9 FIA_UID.1 Timing of identification
5.1.9.1 FIA_UID.1.1 The TSF shall allow [assignment:
HSM_CMD_EMERGENCYERASE,
HSM_CMD_DOINITIALIZATION,
HSM_CMD_VERIFYINITCARD] on behalf of the user to be
performed before the user is identified
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 20.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
5.1.9.2 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.
5.1.10 FMT_MTD.1 Management of TSF data
5.1.10.1 FMT_MTD.1.1 Iteration 1. The TSF shall restrict the ability to [selection:initialize]
the [assignment: TOE, Administrator cards] to [assignment: the
TOE-Administrator in activation phase]
5.1.10.2 FMT_MTD.1.1 Iteration 2. The TSF shall restrict the ability to
[selection:initialize,finalize] the [assignment: Administrator cards,
user cards, backup cards] to [assignment: the TOE-Administrator in
administrator phase]
5.1.10.3 FMT_MTD.1.1 Iteration 3. The TSF shall restrict the ability to [selection:read] the
[assignment: user list, system state] to [assignment: the TOE-
Administrator in administrator phase]
5.1.10.4 FMT_MTD.1.1 Iteration 4. The TSF shall restrict the ability to [selection: finalize]
the [assignment: TOE] to [assignment: the TOE-Administrator,
TOE-User ]
5.1.11 FMT_SMF.1 Specification of Management Functions
5.1.11.1 FMT_SMF.1.1 The TSF shall be capable of performing the following management
functions: [assignment: HSM_CMD_EMERGENCYERASE,
HSM_CMD_DOINITIALIZATION,
HSM_CMD_VERIFYINITCARD,
HSM_CMD_CREATEADMINCARD,
HSM_CMD_CREATEUSERCARD,
HSM_CMD_CREATEBACKUPCARD,
HSM_CMD_DELETEUSER, HSM_CMD_BACKUPDB,
HSM_CMD_RESTOREDB, HSM_CMD_SOFTWAREUPDATE]
5.1.12 FMT_SMR.1 Security roles
5.1.12.1 FMT_SMR.1.1 The TSF shall maintain the roles [assignment: TOE-Administrator,
TOE-User]
5.1.12.2 FMT_SMR.1.2 The TSF shall be able to associate users with roles.
5.1.13 FMT_MOF.1 Management of security functions behaviour
5.1.13.1 FMT_MOF.1.1 The TSF shall restrict the ability to [selection: disable] the functions
[assignment: PKCS#11 Functions] to [assignment: the TOE-User]
5.1.14 FPT_TEE.1 Testing of external entities
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 21.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
5.1.14.1 FPT_TEE.1.1 The TSF shall run a suite of tests [selection: during initial start-up]
to check the fulfillment of [assignment: proper working of IT
environment]
5.1.14.2 FPT_TEE.1.2 If the tests fail, the TSF shall [assignment: stop initialization
process].
5.1.15 FPT_TST.1 TSF testing
5.1.15.1 FPT_TST.1.1 The TSF shall run a suite of self tests [selection: during initial start-
up] to demonstrate the correct operation of [selection: the TSF]
5.1.15.2 FPT_TST.1.2 The TSF shall provide authorised users with the capability to verify
integrity of [selection: TSF data].
5.1.15.3 FPT_TST.1.3 The TSF shall provide authorised users with the capability to verify
the integrity of [selection: TSF].
5.1.16 FPT_PHP.2 Notification of physical attack
5.1.16.1 FPT_PHP.2.1 The TSF shall provide unambiguous detection of physical tampering
that might compromise the TSF.
5.1.16.2 FPT_PHP.2.2 The TSF shall provide the capability to determine whether physical
tampering with the TSF's devices or TSF's elements has occurred.
5.1.16.3 FPT_PHP.2.3 For [assignment: front side Components], the TSF shall monitor the
devices and elements and notify [assignment: TOE-Administrator]
when physical tampering with the TSF's devices or TSF's elements
has occurred.
5.1.17 FPT_PHP.3 Resistance to physical attack
5.1.17.1 FPT_PHP.3.1 Iteration 1. The TSF shall resist [assignment: listening critical
component communications] to the [assignment: NVRAM, FPGA,
Processor] by responding automatically such that the SFRs are
always enforced.
Refinement: The data paths among NVRAM, FPGA and Processor exist only inner layer of the
PCB.
5.1.17.2 FPT_PHP.3.1 Iteration 2. The TSF shall resist [assignment: reading user's
confidential data] to the [assignment: NVRAM] by responding
automatically such that the SFRs are always enforced.
Refinement: All of confidental datas stored in NVRAM that supply with battery power. The
system power down the NVRAM when sense a tamper attack.
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 22.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
5.2 TOE Security Assurance Requirements
The TOE meets the assurance requirements for the Evaluation Assurance Level 4(EAL4),
augmented with ALC_DVS.2: Identification of security measures. These requirements are
summarised in the following table.
Assurance Class Assurance component
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
Guidance documents AGD_OPE.1 Operational user guidance
AGD_PRE.1 Preparative procedures
Life-cycle support ALC_CMC.4 Production support, acceptance
procedures and automation
ALC_CMS.4 Problem tracking CM coverage
ALC_DEL.1 Delivery procedures
ALC_DVS.2 Identification of security measures
ALC_FLR.2 Flaw Reporting Procedures
ALC_LCD.1 Developer defined life-cycle model
ALC_TAT.1 Well-defined development tools
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
Tests ATE_COV.2 Analysis of coverage
ATE_DPT.1 Testing: basic design
ATE_FUN.1 Functional testing
ATE_IND.2 Independent testing - sample
Vulnerability assesment AVA_VAN.3 Focused vulnerability analysis
Table 2 – Assurance Requirements
5.3 CC Component Hierarchies and Dependencies
This section of the ST demonstrates that the identified SFRs include the appropriate hierarchy
and dependencies. The following table lists the TOE SFRs and the SFRs each are hierarchical
to, dependent upon and any necessary rationale.
SFR Hierarchical To Dependency Rationale
FDP_ACC.1 No other components. [FDP_ACF.1] Satisfied
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 23.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
FDP_ACF.1 No other components. [FDP_ACC.1,
FMT_MSA.3]
Satisfied
The TOE does not
support
management of
security attributes.
Authorised users
and other roles
don’t manage (edit,
clear, delete) any
security attributes
FDP_ETC.2 No other components. [FDP_ACC.1 or
FDP_IFC.1]
Satisfied
FDP_IFC.1 No other components. [FDP_IFF.1] Satisfied
FDP_IFF.1 No other components. [FDP_IFC.1,
FMT_MSA.3]
Satisfied
The TOE does not
support
management of
security attributes.
Authorised users
and other roles
don’t manage (edit,
clear, delete) any
security attributes
FDP_ITC.2 No other components. [FDP_ACC.1 or
FDP_IFC.1]
[FTP_ITC.1 or
FTP_TRP.1]
[FPT_TDC.1]
Satisfied
The TOE does not
support the ability
to enforce a trusted
path because the
TOE does not
protect against
modification of
frame flows.
The TOE does not
support inter-TSF
data consistency
because the TOE
have a non-
distributed
environment and
don’t permit
exchange TSF data
with another trusted
IT product except
backup & restore
procedure.
FIA_ATD.1 No other components None n/a
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 24.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
FIA_UAU.1 No other components [FIA_UID.1] Satisfied
FIA_UID.1 No other components None n/a
FMT_MTD.1 No other components [FMT_SMF.1,
FMT_SMR.1]
Satisfied
Satisfied
FMT_SMF.1 No other components None n/a
FMT_SMR.1 No other components [FIA_UID.1] Satisfied
FMT_MOF.1 No other components [FMT_SMR.1 ,
FMT_SMF.1]
Satisfied
FPT_TEE.1 No other components None n/a
FPT_TST.1 No other components None n/a
FPT_PHP.2 No other components [FMT_MOF.1] Satisfied
FPT_PHP.3 No other components None n/a
Table 3 – TOE SFR Dependency Rationale
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 25.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
6. CHAPTER 6: TOE SUMMARY SPECIFICATION
The TOE summary specification provides a complete high-level definition of the security
functions and assurance measures of the TOE and their relationship to the security functional
and assurance requirements of this ST.
The TOE summary specification identifies the security function that the TOE implements to
meet the security requirements defined in chapter 6 of this document.
6.1 TOE Security Functions
The TOE security functions include the following:
6.1.1 Identification and Authentication
The TOE provides its own identification and authentication mechanism. The authentication,
identification and access control functionality provides security that access to resources and
critical data is only privileged to the parties whose authenticity is unambiguously established
and who have an explicitly declared right to access the data (FIA_ATD.1, FIA_UID.1,
FIA_UAU.1)
6.1.2 Security Management
The TOE can only be managed through well defined functions by users entering administrative
roles. This covers FDP_ACC.1, FDP_ACF.1, FMT_MTD.1, FMT_SMR.1, FMT_SMF.1 and
FMT_MOF.1.
6.1.3 Key Management
The TOE ensures to export and import user data cryptographically protected. This covers
FDP_ETC.2 and FDP_ITC.2.
6.1.4 Isolation
The TOE ensures that only legitimate information flows of user data occur. This covers
FDP_IFC.1 and FDP_IFF.1.
6.1.5 Protection of the TOE
The TOE implements a measure to protect itself from the integrity intrusion and to ensure that
secure state follows both from legitimate and expected TOE accesses as well as from
anticipated failures. This covers FPT_TST.1 and FPT_TEE.1.
6.1.6 Physical protection of the TOE
The TOE have mechanisms ensure that the TSF is protected from physical tampering and
interference. This covers FPT_PHP.2 and FPT_PHP.3
6.2 Assurance Measures
The TOE meets the assurance requirements for the Evaluation Assurance Level 4 (EAL4),
augmented with ALC_DVS.2: Identification of security measures. The following table provides a
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 26.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
reference between each TOE assurance requirement and the related vendor documentation that
satisfies each requirement.
Assurance
Class CC Assurance Component
Documentation Satisfying
Component
Development
ADV_ARC.1 Security
architecture
description
TUBITAK UEKAE DIRAK HSM
V2.13 Detailed Design and Security
Architecture Document
ADV_FSP.4 Complete
functional
specification
TUBITAK UEKAE DIRAK HSM
V2.13 Functional Specification Core
Developers Referance
The external TSFs are fully
documented along with the
description of the security functions
and a correspondence between the
interfaces and the security functions.
ADV_IMP.1 Implementation
representation of
the TSF
TUBITAK UEKAE DIRAK HSM
V2.13 Source Code
ADV_TDS.3 Basic modular
design
TUBITAK UEKAE DIRAK HSM
V2.13 Detailed Design and Security
Architecture Document
Guidance
Documents
AGD_OPE.1 Operational user
guidance
TUBITAK UEKAE DIRAK HSM
V2.13 User Guide
AGD_PRE.1 Preparative
procedures
TUBITAK UEKAE DIRAK HSM
V2.13 User Guide
Lifecycle
Support
ALC_CMC.4 Production
support,
acceptance
procedures and
automation
TUBITAK UEKAE DIRAK HSM
V2.13 Configuration Management
Plan
ALC_CMS.4 Problem
tracking CM
coverage
TUBITAK UEKAE DIRAK HSM
V2.13 Configuration Management
Plan
ALC_DEL.1 Delivery
procedures
TUBITAK UEKAE DIRAK HSM
V2.13 Delivery Processes and
Procedures
ALC_DVS.2 Identification of
security
measures
TUBITAK UEKAE DIRAK HSM
V2.13 Life Cycle
TUBITAK UEKAE implements
development security mechanisms
during the development and
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 27.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
maintenance of the TOE.
ALC_LCD.1 Developer
defined life-
cycle model
TOE Life Cycle Model
ALC_TAT.1 Well-defined
development
tools
TOE Development Environment
Security and Development Tools
Security
Target
Evaluation
ASE_CCL.1 Conformance
claims
TUBITAK UEKAE DIRAK HSM
V2.13 Security Target Document
ASE_ECD.1 Extended
components
definition
TUBITAK UEKAE DIRAK HSM
V2.13 Security Target Document
ASE_INT.1 ST introduction TUBITAK UEKAE DIRAK HSM
V2.13 Security Target Document
ASE_OBJ.2 Security
objectives
TUBITAK UEKAE DIRAK HSM
V2.13 Security Target Document
ASE_REQ.2 Derived security
requirements
TUBITAK UEKAE DIRAK HSM
V2.13 Security Target Document
ASE_SPD.1 Security
problem
definition
TUBITAK UEKAE DIRAK HSM
V2.13 Security Target Document
ASE_TSS.1 TOE summary
specification
TUBITAK UEKAE DIRAK HSM
V2.13 Security Target Document
Tests
ATE_COV.2 Analysis of
coverage
TUBITAK UEKAE DIRAK HSM
V2.13 Test Plan
TUBITAK UEKAE DIRAK HSM
V2.13 Test Coverage TUBITAK
UEKAE demonstrates the external
interfaces tested during functional
testing using a coverage analysis.
The analysis includes information
describing how the interfaces are
tested.
ATE_DPT.2 Testing: basic
design
TUBITAK UEKAE DIRAK HSM
V2.13 Test Plan
TUBITAK UEKAE demonstrates the
internal subsystem interfaces tested
during functional testing using a
depth analysis. The analysis includes
information describing how the
interfaces are tested.
ATE_FUN.1 Functional
testing
TUBITAK UEKAE DIRAK HSM
V2.13 Test Plan,
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 28.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
TUBITAK UEKAE DIRAK HSM
V2.13 Test Procedures, TUBITAK
UEKAE DIRAK HSM V2.13 Test
Results TUBITAK UEKAE
functional testing docmentation
contains a test plan, a description of
the tests, along with the expected and
actual results of the test conducted
against the functions specified in the
ST.
ATE_IND.2 Independent
testing – Sample
TUBITAK UEKAE DIRAK HSM
V2.13 Test Plan,
TUBITAK UEKAE DIRAK HSM
V2.13 Test Procedures,
TUBITAK UEKAE DIRAK HSM
V2.13 Functional Specification,
TUBITAK UEKAE HSM User
Guide
The TUBITAK UEKAE HSM
documentation provides the
necessary information for the
evaluators to develop independent
tests.
Vulnerability
Assessment
AVA_VAN.3 Focused
vulnerability
analysis
None
Table 4 – EAL4+ Assurance Measures
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 29.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
7. CHAPTER 7: PROTECTION PROFILE
7.1 Protection Profile Rationale
This Security Target does not claim conformance to any registered Protection Profile.
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 30.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
8. CHAPTER 8: RATIONALE
This chapter provides the rationale for the selection of the IT security requirements, objectives,
assumptions and threats. It shows that the IT security requirements are suitable to meet the
security objectives, Security Requirements, and TOE security functional requirements.
8.1 Rationale for IT and Environmental Security Objectives
This section of the ST demonstrates that the identified security objectives are covering all
aspects of the security needs. This includes showing that each threat and assumption is
addressed by a security objective.
The following table identifies for each threat and assumption, the security objective(s) that
address it.
A.C
ON
NE
CT
A.I
NS
TA
LL
A.N
OE
VIL
A.P
HY
SIC
AL
A.P
LA
TF
OR
M
T.B
YP
AS
S
T.C
AP
TU
RE
T.D
ISA
RR
AN
GE
T.I
NF
_L
EA
K
T.P
OO
R_
TE
ST
T.R
EP
EA
T
T.U
NS
EC
UR
ED
_IT
P.E
ME
RG
EN
CY
P.E
RA
SU
RE
P.C
RY
PT
OG
RA
PH
Y
O.ACCESS_CONTROL X
O.SECURE_ACCESS X X
O.SELF_PROTECT X
O.PROTECT_KEYS X
O.ERASURE X
O.REPEAT X X X
O.FUNC_TEST X X
O.SELF_TEST X X X
OE.CRYPTOGRAPHY X
OE.DISCLOSURE X
OE.PROTECT X
OE.EMERGENCY X
ON.INSTALL X
ON.ADMIN X X X
ON.USER X X
ON.PHYSICAL X X
ON.PLATFORM X
ON.CONNECT X X X
Table 5 – Threats,Assumptions and Policies to Security Objectives Mapping
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 31.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
8.1.1 Rationale Showing Threats to Security Objectives
The following table describes the rationale for the threat to security objectives mapping.
T.TYPE Security Objectives Rationale
T.BYPASS O.ACCESS_CONTROL mitigates this threat by providing user
access right control mechanisms that store access right
information related to the user profile.
O.SECURE_ACCESS mitigates this threat by ensuring that
only authorized users are granted access to the security
functions, configuration and associated data.
O.SELF_PROTECT mitigates this threat by ensuring that the
TSF maintain a domain for its own execution. Thus the TSF
protects itself and its resources from external interfaces,
tampering, or unauthorized disclosure
ON.CONNECT requires that the PC on which the TOE is
running must not be connected directly to an untrusted network.
The PC must either not be connected to any networks or it must
be connected to a trusted network, which is protected against
attacks.
T.CAPTURE OE.PROTECT counters this threat by ensuring that the IT
environment protects the TOE, TOE assets and intra-TOE
communications from disclosure, interface, and tampering.
OE.ADMIN and OE.USER requires that the TOE
administrators and users are appropriately trained, not careless,
not willfully negligent.
OE.PHYSICAL requires that the TOE must be run and
therefore operated in a physically secure and well managed
environment.
T.DISARRANGE O.REPEAT counters this threat by using a command
management structure. In this structure, the TOE keep received
command waiting when it is same as executed command. Thus
the TOE prevent a data corruption or lost sending a command
repeatedly.
O.FUNC_TEST mitigates this threat as a result of long time
security functional testing. These tests demonstrates that the
TSF satisfies its security functional requirements.
O.SELF_TEST mitigates this threat by providing functionality
to perform integrity testing of TOE components during initial
start-up.
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 32.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
T.INF_LEAK O.SECURE_ACCESS mitigates this threat by ensuring that
only authorized users are granted access to the security
functions, configuration and associated data.
O.REPEAT counters this threat by using a command
management structure. In this structure, the TOE keep received
command waiting when it is same as executed command. Thus
the TOE prevent a data corruption or lost sending a command
repeatedly.
O.FUNC_TEST mitigates this threat as a result of long time
security functional testing. These tests demonstrates that the
TSF satisfies its security functional requirements.
O.SELF_TEST mitigates this threat by providing functionality
to perform integrity testing of TOE components during initial
start-up.
T.POOR_TEST O.FUNC_TEST mitigates this threat as a result of long time
security functional testing. These tests demonstrates that the
TSF satisfies its security functional requirements.
T.REPEAT O.REPEAT counters this threat by using a command
management structure. In this structure, the TOE keep received
command waiting when it is same as executed command. Thus
the TOE prevent a data corruption or lost sending a command
repeatedly.
OE.ADMIN and OE.USER requires that the TOE
administrators and users are appropriately trained, not careless,
not willfully negligent, and follow and abide by the instructions
provided in the guidance documentation.
T.UNSECURED_IT O.SELF_TEST mitigates this threat by providing functionality
to perform stability testing of IT environments during initial
start-up.
Table 6 – Threats to Security Objectives Rationale
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 33.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
8.1.2 Rationale Showing Assumptions to Environment Security Objectives
The following table describes the rationale for the assumption to security objectives mapping.
A.TYPE Environment Security Objective Rationale
A.CONNECT ON.CONNECT requires that the single user PC on which the
TOE is running must not be connected directly to an untrusted
network. This means that the PC must either not be connected
to any networks or it must be connected to a trusted network,
which is protected against attacks, so that no undocumented
security critical side effects on the security functions of the
TOE are coming from this network.
A.PHYSICAL ON.PHYSICAL requires that the TOE must be run and
therefore operated in a physically secure and well managed
environment.
A.INSTALL ON.INSTALL requires that the administrator must install and
configure product’s PC-side softwares according to the
administrator guidance.
A.NOEVIL ON.ADMIN requires that the administrators are must
appropriately trained, not careless, not willfully negligent, and
follow and abide by the instructions provided in the guidance
documentation.
A.PLATFORM ON.PLATFORM requires that the administrator must ensure
that the platforms used to host the TOE conform to the
hardware and software outlined in the administrator guidance
Table 7 – Assumptions to Security Objectives Rationale
8.1.3 Rationale Showing OSPs to Security Objectives
The following table describes the rationale for the organisational security policies to security
objectives mapping.
P.TYPE Environment Security Objective Rationale
P.EMERGENCY OE.EMERGENCY satisfies this policy by ensuring that all
encryption keys contained in the HSM database will be deleted
in case of emergency.
P.ERASURE O.ERASURE satisfies this policy by ensuring that all
encryption keys contained in the HSM database will be deleted
upon the request of the authorized user.
P.CRYPTOGRAPHY OE.CRYPTOGRAPHY satisfies this policy by requiring the IT
environment to implement NIST FIPS 140-2 validated
cryptographic operations.
Table 8 – OSPs to Security Objectives Rationale
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 34.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
8.2 Security Requirements Rationale
8.2.1 Rationale for Security Functional Requirements of the TOE Objectives
This section provides rationale for the Security Functional Requirements demonstrating that the
SFRs are suitable to address the security objectives.
The following table identifies for each TOE security objective, the SFR(s) that address it.
Table 9 – SFRs to Security Objectives Mapping
The following table provides the detail of TOE security objective(s).
Security Objective SFR and Rationale
O.ACCESS_CONTROL FIA_ATD.1 ensures that the TOE store information
O.A
CC
ES
S_
CO
NT
RO
L
O.S
EC
UR
E_
AC
CE
SS
O.S
EL
F_
PR
OT
EC
T
O.P
RO
TE
CT
_K
EY
S
O.E
RA
SU
RE
O.R
EP
EA
T
O.F
UN
C_
TE
ST
O.S
EL
F_
TE
ST
FDP_ACC.1 X X
FDP_ACF.1 X
FDP_ETC.2 X X
FDP_IFC.1 X X
FDP_IFF.1 X X X
FDP_ITC.2 X X
FIA_ATD.1 X
FIA_UAU.1 X X X
FIA_UID.1 X X X
FMT_MTD.1 X X
FMT_SMF.1 X X X
FMT_SMR.1 X
FMT_MOF.1 X
FPT_TEE.1 X
FPT_TST.1 X
FPT_PHP.2 X X
FPT_PHP.3 X
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 35.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
related to the user profile and access rights.
FIA_UAU.1 ensures that the TSF allow emergency
erase, initialize, initialization card verify, login and
logout commands to be performed before the user is
authenticated as TOE-Administrator .
FIA_UID.1 ensures that the TSF allow emergency
erase, initialize, initialization card verify, login and
logout commands to be performed before the user is
identified as TOE-Administrator .
FMT_MTD.1 ensures that the TSF restrict the ability
to modify TSF data to the TOE-Administrator
FMT_SMR.1 ensures that the TSF associate users with
TOE-Administrator and TOE-User roles.
FMT_MOF.1 ensures that managing the behaviour of
functions in the TSF from authorised users.
O.SECURE_ACCESS FDP_ACC.1 enforces the HSM database access
control SFP on the manage of the HSM database.
FDP_ACF.1 enforces following rules that the user
must use authorized smart card and enter correct
password to manage the HSM database.
FDP_IFF.1 permits an information flow between a
controlled subject and controlled information via a
controlled operation if the security attribute-based
relationship hold between subject and information
security attributes for each operation.
FIA_UAU.1 ensures that the TSF allow emergency
erase, initialize, initialization card verify, login and
logout commands to be performed before the user is
authenticated as TOE-Administrator .
FIA_UID.1 ensures that the TSF allow emergency
erase, initialize, initialization card verify, login and
logout commands to be performed before the user is
identified as TOE-Administrator .
O.SELF_PROTECT FDP_ETC.2 enforces encryption and integrity
protection to the user data when it is exported from
TSC.
FDP_IFC.1 ensures that the TSF enforce the
information flow control SFP on all subjects,objects
out of which the information can be read or rather in
which the information can be written, and the operation
reading and writing of information.
FDP_IFF.1 permits an information flow between a
controlled subject and controlled information via a
controlled operation if the security attribute-based
relationship hold between subject and information
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 36.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
security attributes for each operation.
FDP_ITC.2 ensure that the TSF allow to import
encrypted and integrity protected user data only.
FMT_MTD.1 ensures that the TSF restrict the ability
to modify TSF data to the TOE-Administrator
FMT_SMF.1 details the TSF can perform following
management functions;
emergency erase, initialize, initialization card verify,
login and logout, admin/user/backup card create, user
delete, database backup/restore, software update.
O.PROTECT_KEYS FDP_ETC.2 enforces encryption and integrity
protection to the user data when it is exported from
TSC.
FDP_ITC.2 ensures that the TSF allow to import
encrypted and integrity protected user data only.
FPT_PHP.2 details the TSF can perform active erase
function to protect user data and keys.
FPT_PHP.3 details the TSF resists to tamper attack to
protect user data and keys.
O.ERASURE FMT_SMF.1 details the TSF can perform emergency
erase function.
FIA_UAU.1 ensures that the TSF allow emergency
erase, command to be performed before the user is
authenticated as TOE-Administrator .
FIA_UID.1 ensures that the TSF allow emergency
erase, command to be performed before the user is
identified as TOE-Administrator .
FPT_PHP.2 details the TSF can perform active erase
function.
O.REPEAT FDP_IFC.1 ensures that the TSF enforce the
information flow control SFP on all subjects,objects
out of which the information can be read or rather in
which the information can be written, and the operation
reading and writing of information.
O.FUNC_TEST FDP_ACC.1 enforces the HSM database access
control SFP on the manage of the HSM database.
FDP_IFF.1 permits an information flow between a
controlled subject and controlled information via a
controlled operation if the security attribute-based
relationship hold between subject and information
security attributes for each operation.
FMT_SMF.1 details the TSF can perform following
management functions;
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 37.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
emergency erase, initialize, initialization card verify,
login and logout, admin/user/backup card create, user
delete, database backup/restore, software update.
O.SELF_TEST FPT_TEE.1 ensure that the TSF run a suite of tests
during initial start-up to check the fulfilment of IT
environment. If the tests fail, the TSF stop initialization
process.
FPT_TST.1 ensure that the TSF run a suite of self tests
during initial start-up to demonstrate the correct
operation of the TSF.
Table 10 – Security Objectives to SFR Rationale
8.2.2 Security Assurance Requirements Rationale
The TOE meets the assurance requirements for EAL4+ and is augmented by ALC_DVS.2. The
TOE stresses assurance through vendor actions that are within the bounds of current best
commercial practice. The TOE provides, primarily via review of vendor-supplied evidence,
independent confirmation that these actions have been competently performed.
The general level of assurance for the TOE is:
A Consistent with current best commercial practice for IT development and provides a product
that is competitive against non-evaluated products with respect to functionality, performance,
cost, and time-to-market.
B The TOE assurance also meets current constraints on widespread acceptance, by expressing
its claims against part 3 of the Common Criteria.
8.3 TOE Summary Specification Rationale
This section demonstrates that the TOE’s Security Functions completely and accurately meet
the TOE SFRs.
The following tables provide a mapping between the TOE’s Security Functions and the SFRs
and the rationale.
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 38.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
Identification
and
Authentication
Security
Management
Key
Management Isolation
Protection of
the TOE
Physical
protection of
the TOE
FDP_ACC.1 X
FDP_ACF.1 X
FDP_ETC.2 X
FDP_IFC.1 X
FDP_IFF.1 X
FDP_ITC.2 X
FIA_ATD.1 X
FIA_UAU.1 X
FIA_UID.1 X
FMT_MTD.1 X
FMT_SMF.1 X
FMT_SMR.1 X
FMT_MOF.1 X
FPT_TEE.1 X
FPT_TST.1 X
FPT_PHP.2 X
FPT_PHP.3 X
Table 11 – SFRs to TOE Security Functions Mapping
SFR SF and Rationale
FDP_ACC.1 Security Management – The SF provides security of HSM database
access by enforcing the HSM database access control SFP on all
objects.
FDP_ACF.1 Security Management – The SF provides security of TOE access by
enforcing password and authorized smart card protected access control
for all access request.
FDP_ETC.2 Key Management – The TOE export user data with security
attributes that encrypted and integrity protected by signing.
FDP_IFC.1 Isolation – The SF ensure that which the information can be read or
rather in which the information can be written owing to the
information flow control SFP.
FDP_IFF.1 Isolation – The SF permits an information flow between two units if
the security relationship hold between these units for each operation.
Thus, the SF provides isolations between units continuously.
FDP_ITC.2 Key Management – The SF allow to import user data with security
attributes that encrypted and integrity protected only.
FIA_ATD.1 Identification and Authentication – The TOE store information
related to the user profile and access rights.
FIA_UAU.1 Identification and Authentication – The SF allow emergency erase,
initialize, initialization card verify, login and logout commands to be
performed before the user is authenticated as TOE-Administrator .
V2.13
Security Target Lite
Rev. No: 06 Rev. Date: 05.04.2013 HSM-ST-LITE 39.th page of 39 pages
Th
e co
nte
nts
of
this
docu
men
t a
re t
he
pro
per
ty o
f T
ÜB
İTA
K
UE
KA
E a
nd
sh
ou
ld n
ot
be
rep
rodu
ced
, co
pie
d o
r d
iscl
ose
d t
o
a t
hir
d p
art
y w
ithou
t th
e w
ritt
en c
on
sent
of
the
pro
pri
eto
r.
© 2
013
TÜ
BİT
AK
UE
KA
E
Ulu
sal
Ele
ktro
nik
ve
Kri
pto
loji
Ara
ştır
ma
En
stit
üsü
P.K
. 74
, G
ebze
, 4
14
70
Ko
cael
i, T
ÜR
KİY
E
Tel
: (0
26
2)
648
100
0,
Faks
: (0
262
) 64
8 1
10
0
Bu
do
küm
an
ın i
çeri
ği
TÜ
BİT
AK
UE
KA
E’n
in m
ülk
iyet
inded
ir.
Sah
ibin
in y
azı
lı i
zni
olm
ada
n ç
oğa
ltıl
am
az,
kop
yala
na
ma
z ve
üçü
ncü
şa
hıs
lara
açı
klan
am
az.
FIA_UID.1 Identification and Authentication – The SF allow emergency erase,
initialize, initialization card verify, login and logout commands to be
performed before the user is identified as TOE-Administrator .
FMT_MTD.1 Security Management – The SF restrict the ability to modify TSF
data to the TOE-Administrator
FMT_SMF.1 Security Management – The SF can perform following management
functions only; emergency erase, initialize, initialization card verify,
login and logout, admin/user/backup card create, user delete,
database backup/restore, software update.
FMT_SMR.1 Security Management – The SF associate users with TOE-
Administrator and TOE-User roles.
FMT_MOF.1 Security Management – The SF restrict managing the behaviour of
functions in the TSF from authorized users.
FPT_TEE.1 Protection of the TOE – The SF run a suite of tests during initial
start-up to check the fulfilment of IT environment.
FPT_TST.1 Protection of the TOE – The SF run a suite of self tests during initial
start-up to demonstrate the correct operation of the TSF.
FPT_PHP.2 Physical protection of the TOE – The SF perform active erase
function to protect user data and keys.
FPT_PHP.3 Physical protection of the TOE – The SF resists to tamper attack to
protect user data and keys.
Table 12 – SFR to SF Rationale