i
DiskCrypt Series
Security Target
Version 0.4
The information contained herein is the property of ST Engineering Info-Security Pte. Ltd. and may
not be copied, used or disclosed in whole or in part to any third party except with written approval of
ST Engineering Info-Security Pte. Ltd. or if it has been authorised under a contract.
ISSUE A
ii
DiskCrypt Series
Security Target
Distribution List
COPY NO.
1 Product Manager, ST Engineering (Original)
ISSUE A
iii
DiskCrypt Series
Security Target
Contents
Preliminary Pages Page
Title / Authorisation ...................................................................................................................i
Distribution List.........................................................................................................................ii
Contents....................................................................................................................................iii
List of Illustrations ...................................................................................................................iv
Amendment Record...................................................................................................................v
Chapter 1 – Security Target Introduction..........................................................................1-1
Security Target Reference................................................................................1-3
TOE Reference.................................................................................................1-3
TOE Overview.................................................................................................1-4
1.3.1 TOE Type...............................................................................................1-4
1.3.2 TOE Usage .............................................................................................1-5
1.3.3 TOE Security Features ...........................................................................1-5
1.3.4 Non-TOE Hardware/Software and Firmware ........................................1-6
Chapter 2 TOE Description.................................................................................................2-1
Physical Scope of the TOE ..............................................................................2-1
Logical Scope of the TOE................................................................................2-2
2.2.1 Identification...........................................................................................2-2
2.2.2 Authentication ........................................................................................2-2
2.2.3 Cryptographic Support ...........................................................................2-2
2.2.4 Security Management.............................................................................2-2
2.2.5 Protection of TSF ...................................................................................2-2
Chapter 3 – Conformance Claims.......................................................................................3-1
Chapter 4 – Security Problem Definition ...........................................................................4-1
Asset.................................................................................................................4-1
Threats..............................................................................................................4-1
ISSUE A
iv
Organizational Security Policies......................................................................4-1
Assumptions.....................................................................................................4-2
Chapter 5 –Security Objectives ...........................................................................................5-1
Security Objectives for the TOE......................................................................5-1
Security Objectives for the Operational Environment.....................................5-1
Security Objective Rationale ...........................................................................5-2
Chapter 6 – Extended Components Definition ..................................................................6-1
Chapter 7 – IT Security Requirements...............................................................................7-1
Conventions .....................................................................................................7-1
Security Functional Requirements...................................................................7-2
7.2.1 Class FIA: Identification and Authentication........................................7-2
7.2.2 Class FCS: Cryptographic support ........................................................7-3
7.2.3 Class FDP: User Data Protection ...........................................................7-5
7.2.4 Class FMT: Security management .........................................................7-6
7.2.5 Class FPT: Protection of the TSF...........................................................7-8
Security Requirement Dependency Rationale .................................................7-9
Security Functional Requirements Rationale.................................................7-11
Security Assurance Requirements .................................................................7-16
Security Assurance Requirement Rationale...................................................7-17
Chapter 8 – TOE Summary Specification..........................................................................8-1
SF1 – Identification and Authentication..........................................................8-1
SF2 – Cryptographic Support ..........................................................................8-1
SF3 – Security Management...........................................................................8-2
SF4 – Protection of the TSF.............................................................................8-2
TOE Summary SFR to TSF mapping..............................................................8-4
ISSUE A
v
List of Illustrations
Figure Page
Figure 1 DiskCrypt M20 ............................................................................................................. 1-1
Figure 2 DiskCrypt M200 ........................................................................................................... 1-2
Figure 3 TOE Usage Overview ................................................................................................... 1-5
Table..........................................................................................................................................Page
Table 1. DiskCrypt M20 Product ID ........................................................................................... 1-1
Table 2. DiskCrypt M200 Product ID ......................................................................................... 1-2
Table 3. Scope of Delivery.......................................................................................................... 2-1
Table 4. Assets protected by the TOE......................................................................................... 4-1
Table 5. Threat Statements.......................................................................................................... 4-1
Table 6. Assumptions .................................................................................................................. 4-2
Table 7. Security Objectives for the TOE ................................................................................... 5-1
Table 8. Security Objectives for the Operational Environment .................................................. 5-1
Table 9. Security Objective Rationale......................................................................................... 5-2
Table 10. Security Requirement Dependency Rationale........................................................... 7-10
Table 11. Security Requirements to Security Objective Mapping ............................................ 7-11
Table 12. Security Objective to SFR mapping Rationale.......................................................... 7-15
Table 13. Assurance Components ............................................................................................. 7-16
Table 14. SFR to Security Functions mapping............................................................................ 8-4
ISSUE A
vi
Amendment Record
AMDT NO. AFFECTED PAGE(S) ECR/DCR NO. EFFECTIVE DATE
ISSUE A
1-1
Chapter 1 – Security Target Introduction
This Security Target (ST) defines the security functionality of the Target of Evaluation (TOE)
for the DiskCrypt Series Family.
DiskCrypt Series Family includes:
1. DiskCrypt M20
The DiskCrypt M20 comes in a form factor that accommodates SATA M.2 SSD. It comes
delivered with internal storage device.
Figure 1 DiskCrypt M20
Description Part No.
DiskCrypt M20 1TB 9910-2401-099G
DiskCrypt M20 2TB 9910-2401-100G
Table 1. DiskCrypt M20 Product ID
2. DiskCrypt M200
DiskCrypt M200 comes in a form factor that accommodates 2.5 inch SSD. It comes delivered
without internal storage device.
ISSUE A
1-2
Figure 2 DiskCrypt M200
Description Part No.
DiskCrypt M200 9910-2401-098G
Table 2. DiskCrypt M200 Product ID
ISSUE A
1-3
Security Target Reference
ST Title: DiskCrypt Series Security Target
ST Document Version: 0.4
ST Publication Date: 23 June 2025
TOE Reference
TOE Identification: M331P10J1E1
ISSUE A
1-4
TOE Overview
This TOE is a USB data storage encryptor which provides real-time full disk encryption (FDE) for
user data stored within its internal storage. The internal storage is out of the TOE scope.
The TOE operates with a paired smart card which stores a smart card keying material (SKM). At
the same time, a device keying material (DKM) is stored within the TOE. To access the user data
stored within the internal storage, a user must authenticates itself to the smart card using a smart
card PIN. After the smart card has successfully authenticated the user, the smart card releases the
SKM to the TOE. The SKM and DKM are inputs to the TOE’s key derivation function that derives
a Data Encryption Key (DEK). The DEK shall then be used for disk encryption/decryption, in turn,
the user gains read/write access to the user data stored within the internal storage.
1.3.1 TOE Type
This TOE is a USB data storage encryptor which provides real-time full disk encryption (FDE) for
user data stored within its internal storage. The internal storage is out of the TOE scope.
ISSUE A
1-5
1.3.2 TOE Usage
The TOE has a built-in keypad and smart card reader. It is powered via its USB interface (USB
3.1) by connecting it to a host workstation (USB 3.1/3.0 are supported). The TOE requires users
to insert their authorized smart card and input the smart card PIN via the integrated keypad of the
TOE to authenticate to the smart card. Upon successful authentication, access to the user data is
granted.
Figure 3 TOE Usage Overview
1.3.3 TOE Security Features
The TOE employs hardware-based full disk encryption using the AES-256 XTS algorithm to
encrypt all data stored in the internal storage.
The TOE performs full disk encryption using a Data Encryption key (DEK) derived from 2
separate keying materials. The first keying material, SKM (Smart Card Keying Material), is
retrieved from the user’s smart card. The second keying material, DKM (Device Keying Material),
is injected into the TOE during device setup by the administrator.
The TOE ensures that the DEK, SKM, and Admin PIN are zeroized when no longer used.
The TOE is inbuilt with self-test mechanisms – Power-On-Self-Test (POST) and Known Answer
Test (KAT). These self-test mechanisms ensure the integrity and functionality of the TOE.
The TOE provides the following administrative functions:
ISSUE A
1-6
1) Pairing of smart cards
2) DKM injection (during device setup)
3) Enable/disable smart card lockout mode
4) Changing of Admin PIN
The TOE ensures that usage of the administrative functions requires the Administrator to
authenticate to the TOE by inserting the paired smart card and providing the Admin PIN. The TOE
will disable the administrative function if there are eight consecutive Administrator authentication
failures.
Before the issuance of the TOE and smart card to the end-user, the TOE requires the Administrator
to prepare the TOE using the abovementioned administrative functions.
1.3.4 Non-TOE Hardware/Software and Firmware
The following components described are hardware/software for supporting some of the TOE
device functionality. These components are not part of the physical TOE for evaluation.
1. DiskCrypt (DC) Smart Card – Two types of smart cards are provided: Admin Smart Card
and User Smart Card. The Smart Cards are PKCS #11 compliant. The Admin Smart Card
stores the DKM, and the User Smart Card stores the SKM. The Admin Smart Card is used to
inject the DKM into the TOE during TOE preparation. DKM and SKM are input to the key
derivation function for the DEK. The Smart Cards are also used for identification.
2. DiskCrypt Key Management Software (DMS) - The smart cards issued along with the
DiskCrypt are provisioned by the Administrator using the DiskCrypt Key Management
software (DMS). The DMS is an external software application for enterprises to manage their
smart cards and SKM for usage with DiskCrypt. Administrators may refer to the DMS Guide
for installation and operation guidance.
3. AWP Manager Software Version – AWP Manager is a software application used for
performing cryptographic modification of smart cards issued with DiskCrypt. It communicates
with the smart cards through a PKCS #11 module.
4. Host Workstation – The TOE requires a host system that provides a USB interface (USB
3.1/3.0) supporting the USB mass storage device class.
5. KeyCrypt Token – Used for 2FA login to the DMS software application.
6. Internal Storage Device – 2.5inch SSD (use in DiskCrypt M200 Type C) and M.2 SSD with
2280 form factor (used in DiskCrypt M20).
ISSUE A
2-1
Chapter 2 TOE Description
Physical Scope of the TOE
The physical scope of the TOE is defined by the enclosure and hardware components which
provide the cryptographic function, authentication mechanism, interfaces for authentication and
LED indicators. It does not include the smart card and the internal storage device.
The scope of delivery (of the TOE) is listed as follows:
No. Delivery Items Format Delivery method
Part of
TOE
1 TOE Hardware
In-house delivery –
for Singapore
delivery
Trusted courier – for
Overseas delivery
Yes
2 Smart cards (User and Admin) Hardware No
3 USB cable Hardware No
4 KeyCrypt Hardware No
5 Internal Storage Device1
Hardware No
6
DiskCrypt Key Management
Software (DMS) Software
MSI stored in
CD
No
7 AWP Manager Software
MSI stored in
CD
No
8
DiskCrypt Administrator’s
Guide v1.0.2
PDF stored in
CD
Yes
9 DMS Guide v2.4
PDF stored in
CD
No
10 AWP Manager Guide v1.5
PDF stored in
CD
No
11 DiskCrypt User Manual v1.0.2 PDF
Download via
developer’s website
Yes
Table 3. Scope of Delivery
The TOE is shipped with a default factory configuration.
1
DiskCrypt M20 comes delivered with internal storage device. DiskCrypt M200 comes delivered without internal
storage device.
ISSUE A
2-2
Logical Scope of the TOE
The TOE provides the core security functionalities in the following areas.
2.2.1 Identification
The TOE requires the user to be identified before either access to the administrative functions can
be granted or user data can be decrypted.
2.2.2 Authentication
The TOE requires the Administrator to be authenticated before they are allowed to administer the
TOE using the administrative functions available in the TOE.
Administrators shall present a paired smartcard and input the correct Admin PIN via the integrated
keypad, authenticating to the TOE. During Administrator authentication, a hash of the input Admin
PIN is computed and compared with the stored hash value. Upon successful authentication, the
administrative function selected will be successfully invoked. The Admin PIN is zeroized upon
completion of usage.
2.2.3 Cryptographic Support
User data sent from the host machine via the USB interface will be encrypted and stored in the
internal storage. Similarly, all data retrieved from the encrypted storage will be decrypted and sent
to the host machine. Data encryption is performed using the DEK (AES-256 XTS algorithm) to
provide user data confidentiality.
The DEK is derived from 2 separate keying materials. The first keying material (SKM – Smart
card Keying Material) is retrieved from the user’s smart card. The second keying material (DKM
– Device Keying Material) is injected into the TOE during device setup by the administrator.
The TOE performs Hashing to verify the integrity of TSF data (TOE application, configuration
data, DKM and Admin PIN) during POST. The Admin PIN is stored as a hash within the TOE
during device setup.
The TOE performs zeroization of SKM and DEK when no longer required.
2.2.4 Security Management
The TOE provides the following administrative functions:
1. Injection of DKM into the TOE during device setup
2. Pairing a user smart card with the TOE
3. Change Admin PIN
4. Enable/disable the smart card lockout mode
2.2.5 Protection of TSF
The TOE implements the Power-On Self-Test (POST) of the Micro Controller Unit (MCU) during
the initial start-up to ensure correct functionality. Separately, the TOE implements a Known
Answer Test of the cryptographic module upon the cryptographic module’s start-up to ensure
correct operation.
ISSUE A
3-1
Chapter 3 – Conformance Claims
The following conformance claims are made for the TOE and ST:
CCv3.1 Rev.5 conformant. The ST and the TOE are Common Criteria conformant to Common
Criteria version 3.1 Revision 5.
Part 2 conformant. The ST is Common Criteria Part 2 conformant.
Part 3 conformant. The ST is Common Criteria Part 3 conformant.
Package conformant. The ST is package conformant to the package Evaluation Assurance Level
EAL2.
Protection Profile conformant. None.
ISSUE A
4-1
Chapter 4 – Security Problem Definition
Asset
The TOE is concerned with the protection of the following assets enumerated in the table below.
Identifier Asset Statement
AST.DATA Confidential plaintext user data stored in or processed by
the TOE.
AST.TSF_DATA MatchID, DEK, SKM, DKM, Admin PIN and
configuration data of the TOE.
Table 4. Assets protected by the TOE
Threats
The Threats enumerated in the table shown below Table 3 are relevant to the TOE.
Identifier Threat statement
T.LOGICAL_ ACC An attacker compromises the confidentiality of
AST.DATA or gain unauthorized access to
AST.TSF_DATA by applying logical attack on the TOE.
T.PHYSICAL_ACC An attacker compromises the confidentiality of
AST.DATA or gain unauthorized access to
AST.TSF_DATA by applying physical attack on the TOE.
T.MALFUNCTION An attacker may use a malfunction of the TOE to
deactivate, modify, or circumvent security functions of the
TOE to enable attacks against the confidentiality of
AST.DATA or gain unauthorized access to
AST.TSF_DATA.
Table 5. Threat Statements
Organizational Security Policies
No organizational security policy is defined for the TOE.
ISSUE A
4-2
Assumptions
This section lists the security-related assumption for the environment in which the TOE is to be
used. It can be considered a set of rules for the TOE operator.
A.TRUSTED_USER Users of the TOE are able to operate the TOE in a secure
manner in accordance to the user guidance documentation.
A.ADMIN Administrator of the TOE is trusted, well-trained and
adheres to all guidance documentation provided.
A.SMARTCARD The smartcard used together with the TOE must conform
to the following:
• Secure Signature Creation Device Protection
Profile Type 2 v1.04, EAL 4+
• Secure Signature Creation Device Protection
Profile Type 3 v1.05, EAL 4+
Table 6. Assumptions
ISSUE A
5-1
Chapter 5 –Security Objectives
This Chapter identifies the security objectives of the TOE and the IT Environment. The security
objectives identify the responsibilities of the TOE and the TOE’s IT environment in meeting the
security needs.
Security Objectives for the TOE
Security objectives for the TOE are enumerated in the table below.
Identifier Objective Statement
O.DATA_ACC Access to user data is only granted to identified users.
O.ADMIN_ACC Access to administrative functions and TSF data is only granted to
legitimate administrators.
O.TOE_INTEGRITY The security state of the TOE, including TSF data stored
persistently on the TOE, is protected against unauthorized
modification, and can only be altered by authorized and
authenticated parties.
O.ENCRYPT User data stored in the internal storage is encrypted, providing
confidentiality protection in the event of physical and logical
attacks on the TOE.
Table 7. Security Objectives for the TOE
Security Objectives for the Operational Environment
Identifier Objective Statement
OE.TRUSTED_USER The TOE users must operate the TOE in accordance to the
user guidance documentation.
OE.ADMIN Administrator of the TOE must administer the TOE by the
admin guidance documentation.
OE.SMARTCARD The smartcard used together with the TOE must conform to
the following:
• Secure Signature Creation Device Protection Profile
Type 2 v1.04, EAL 4+
• Secure Signature Creation Device Protection Profile
Type 3 v1.05, EAL 4+
Table 8. Security Objectives for the Operational Environment
ISSUE A
5-2
Security Objective Rationale
Threat/Assumption Objective Rationale
T.LOGICAL_ACC O.DATA_ACC
O.ADMIN_ACC
O.ENCRYPT
OE.SMARTCARD
O.DATA_ACC ensures that only identified
users are allowed to access the user data.
O.ADMIN_ACC ensures that only authorized
administrators are allowed to access the TOE’s
administrative functions and TSF data.
O.ENCRYPT ensures that user data are
encrypted and prevents unauthorized access to
user data.
O.DATA_ACC, O.ADMIN_ACC, and
O.ENCRYPT make use of OE.SMARTCARD
for user identification and storage of SKM.
T.MALFUNCTION O.TOE_INTEGRITY O.TOE_INTEGRITY requires the TOE to
perform self-tests to ensure that the TOE is
functional that and TSF data is not modified. If
the self-test fails, the TOE shall preserve a
secure state (non-operational).
T.PHYSICAL_ACC O.ENCRYPT
OE.TRUSTED_USER
O.TOE_INTEGRITY
O.ENCRYPT ensures that user data are
encrypted prior to storage in the internal
storage device, hence preventing adversaries
from compromising the confidentiality of user
data in the event that the TOE is physically
compromised.
O.TOE_INTERGRITY ensures that the TSF
and TSF data are protected against
unauthorised modification.
OE.TRUSTED_USER ensures user will not
leave the TOE unattended, hence reducing risk
of physical attack.
A.TRUSTED_USER OE.TRUSTED_USER OE.TRUSTED_USER ensures that users
practice proper usage procedures in accordance
to the user guidance documentation
A.ADMIN OE.ADMIN OE.ADMIN ensures that administrative
personnel will administer the TOE according
to the admin guidance documentation.
A.SMARTCARD OE.SMARTCARD OE.SMARTCARD directly upholds
A.SMARTCARD.
Table 9. Security Objective Rationale
ISSUE A
6-1
Chapter 6 – Extended Components Definition
There are no extended components applicable to the TOE, hence none of the requirements for the
Extended Components Definition (ASE_ECD) applies to this ST.
ISSUE A
7-1
Chapter 7 – IT Security Requirements
This section identifies the Security Functional Requirements for the TOE. The Security Functional
Requirements included in this section are derived from Part 2 of the Common Criteria for
Information Technology Security Evaluation, Version 3.1, Revision 5, dated: April 2017 and all
international interpretations.
Conventions
The CC defines operations on Security Functional Requirements: assignments, selections,
assignments within selections and refinements. This document uses the following font conventions
to identify the operations defined by the CC:
• Assignment: Indicated with bold italicized text.
• Refinement: Indicated with bold text.
• Selection: Indicated with italicized text.
• Iteration: Indicated by appending the iteration symbol.
e.g., FCS_COP.1/AES, FCS_COP.1/Hash
ISSUE A
7-2
Security Functional Requirements
7.2.1 Class FIA: Identification and Authentication
7.2.1.1 FIA_UID.2 User identification before any action
Hierarchical to: FIA_UID.1 Timing of identification
Dependencies: No dependencies.
FIA_UID.2.1 The TSF shall require each user to be successfully identified before allowing any
other TSF-mediated actions on behalf of that user.
7.2.1.2 FIA_UAU.2 User authentication before any action
Hierarchical to: FIA_UAU.1 Timing of authentication
Dependencies: FIA_UID.1 Timing of identification
FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated before allowing
any other TSF-mediated actions on behalf of that user.
7.2.1.3 FIA_SOS.1 Verification of secrets
Hierarchical to: No other components.
Dependencies: No dependencies
FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet the requirements
where the PIN entered through the Keypad must be 8 digits in length.
Application Note: Applicable to the authentication of the Administrator.
7.2.1.4 FIA_AFL.1 Authentication failure handling
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication.
FIA_AFL.1.1 The TSF shall detect when 8 (eight) unsuccessful authentication attempts occur
related to the authentication of the Administrator.
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met,
the TSF shall disable all future access to administrative functions of the TOE.
Application note: In the case when TOE’s administrative function is disabled, the
TOE’s encryption/decryption of user data as enforced by FCS_COP.1/AES remains
functional. To recover the administrative function, a TOE user is required to return the
TOE to the developer to re-flash its firmware.
ISSUE A
7-3
7.2.2 Class FCS: Cryptographic support
7.2.2.1 FCS_CKM.1 Cryptographic key generation
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1 The TSF shall generate DEK by a specified cryptographic key generation
algorithm XOR and specified cryptographic key sizes 512 bits that meet the
following: none
Application Note: Applicable to FCS_COP.1/AES
7.2.2.2 FCS_CKM.4/MCU Cryptographic Key Destruction
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4.1/MCU The TSF shall destroy cryptographic keys by a specified cryptographic key
destruction method with 7 rounds of zeroization that meets the following
none
Application Note: Applicable to zeroization of DEK from MCU.
7.2.2.3 FCS_CKM.4/Crypto Cryptographic Key Destruction
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4.1/Crypto the TSF shall destroy cryptographic keys by a specified cryptographic key
destruction method writing zero to the specific memory location that meets
the following none.
Application Note: Applicable to zeroization of DEK from the Cryptographic module.
7.2.2.4 FCS_COP.1/AES - Cryptographic operation
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/AES The TSF shall perform data encryption and decryption by a specified
cryptographic algorithm AES 256 XTS mode and cryptographic key sizes
512 bits that meet the following: IEEE P1619-2018 Standard.
ISSUE A
7-4
7.2.2.5 FCS_COP.1/Hash - Cryptographic operation
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/Hash The TSF shall perform cryptographic hashing by a specified cryptographic
algorithm SHA-256 and message digest sizes 256 bits that meet the
following: FIPS PUB 180-4, "Secure Hash Standard".
Application note: SHA-256 was used for Integrity check during POST and Admin
PIN verification.
ISSUE A
7-5
7.2.3 Class FDP: User Data Protection
7.2.3.1 FDP_RIP.1 Subset residual information protection
Hierarchical to: No other components.
Dependencies: No dependencies.
FDP_RIP.1.1 The TSF shall ensure that any previous information content of a resource is
made unavailable upon the deallocation of the resource from the following
objects: Admin PIN, SKM.
7.2.3.2 FDP_ACF.1 Security attribute-based access control
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
FDP_ACF.1.1 The TSF shall enforce the role-based SFP to objects based on the
following:
Subjects All subjects acting on behalf of users
Objects User data
Security Attributes
MatchID, smartcard VERIFY PIN
response, SKM
FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed:
• Subject with the role "Identified User" is allowed to encrypt and
decrypt (based on FCS_COP.1/AES) user data.
• Subject with the role "Identified User" is allowed to import SKM
into the TOE
FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to objects based on the
following additional rules: none
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the
following additional rules:
• POST Failure
• KAT Failure
7.2.3.3 FDP_ACC.1 Subset access control
Hierarchical to: No other components.
Dependencies: FDP_ACF.1 Security attribute-based access control
FDP_ACC.1.1
The TSF shall enforce the role-based SFP on:
Subjects All subjects acting on behalf of users
Objects User data
Operations Encryption & Decryption
ISSUE A
7-6
7.2.4 Class FMT: Security management
7.2.4.1 FMT_SMR.1 Security roles
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification.
FMT_SMR.1.1 The TSF shall maintain the roles, Unidentified user, Identified user,
Administrators
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
7.2.4.2 FMT_SMF.1 Specification of Management Functions
Hierarchical to: No other components.
Dependencies: No dependencies
FMT_SMF.1.1 The TSF shall be capable of performing the following management
functions:
1) Enable/disable the smartcard lockout mode.
2) Change Admin PIN
7.2.4.3 FMT_MOF.1 Management of security functions behaviour
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MOF.1.1 The TSF shall restrict the ability to disable, enable the function of lockout
mode to Administrator.
7.2.4.4 FMT_MTD.1 Management of TSF data
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MTD.1.1 The TSF shall restrict the ability to change_default, modify the Admin PIN,
DKM, and MatchID to Administrator.
7.2.4.5 FMT_MSA.1 Management of security attributes
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MSA.1.1 The TSF shall enforce the role-based SFP to restrict the ability to modify
the security attributes from Role to None.
ISSUE A
7-7
Application note: Roles are pre-programmed into the TOE and not modifiable
7.2.4.6 FMT_MSA.3 Static attribute initialisation
Hierarchical to: No other components.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_MSA.3.1 The TSF shall enforce the role-based SFP to provide restrictive default
values for security attributes that are used to enforce the SFP.
FMT_MSA.3.2 The TSF shall allow the None to specify alternative initial values to
override the default values when an object or information is created.
ISSUE A
7-8
7.2.5 Class FPT: Protection of the TSF
7.2.5.1 FPT_FLS.1 Failure with preservation of secure state
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of failures
occur failure of self-test as defined in FPT_TST.1)
7.2.5.2 FPT_TST.1 TSF Testing
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_TST.1.1 The TSF shall run a suite of self-tests during the initial start-up 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 none.
FPT_TST.1.3 The TSF shall provide authorised users with the capability to verify the
integrity of none
ISSUE A
7-9
Security Requirement Dependency Rationale
SFR Dependency Fulfilment
FIA_UID.2 No dependencies -
FIA_UAU.2 FIA_UID.1 FIA_UID.2
FIA_SOS.1 No dependencies -
FIA_AFL.1 FIA_UAU.1 FIA_UAU.2
FCS_CKM.1
[FCS_CKM.2 or
FCS_COP.1]
FCS_CKM.4
FCS_COP.1/AES
FCS_CKM.4/MCU, FCS_CKM.4/Crypto
FCS_CKM.4/MCU
FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1
FCS_CKM.1
FCS_CKM.4/Crypto
FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1
FCS_CKM.1
FCS_COP.1/AES
[FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1]
FCS_CKM.4
FCS_CKM.1
FCS_CKM.4/MCU, FCS_CKM.4/Crypto
FCS_COP.1/Hash
[FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1]
FCS_CKM.4
Keys are not required for hashing.
FDP_RIP.1 No dependencies -
FDP_ACF.1
FDP_ACC.1
FMT_MSA.3
FDP_ACC.1
FMT_MSA.3
FDP_ACC.1 FDP_ACF.1 FDP_ACF.1
FMT_SMR.1 FIA_UID.1 FIA_UID.2
FMT_SMF.1 No dependencies -
FMT_MOF.1
FMT_SMR.1
FMT_SMF.1
FMT_SMR.1
FMT_SMF.1
FMT_MTD.1
FMT_SMR.1
FMT_SMF.1
FMT_SMR.1
FMT_SMF.1
ISSUE A
7-10
SFR Dependency Fulfilment
FMT_MSA.1
[FDP_ACC.1 or
FDP_IFC.1]
FMT_SMR.1
FMT_SMF.1
FDP_ACC.1
FMT_SMR.1
FMT_SMF.1
FMT_MSA.3
FMT_MSA.1
FMT_SMR.1
FMT_MSA.1
FMT_SMR.1
FPT_FLS.1 No dependencies -
FPT_TST.1 No dependencies -
Table 10. Security Requirement Dependency Rationale
ISSUE A
7-11
Security Functional Requirements Rationale
SFR
O.DATA_ACC
O.ADMIN_ACC
O.TOE_INTEGRITY
O.ENCRYPT
FIA_UID.2 X X
FIA_UAU.2 X
FIA_SOS.1 X
FIA_AFL.1 X
FCS_CKM.1 X
FCS_CKM.4/MCU X
FCS_CKM.4/Crypto X
FCS_COP.1/AES X X
FCS_COP.1/Hash X X
FDP_RIP.1 X X
FDP_ACF.1 X
FDP_ACC.1 X
FMT_SMR.1 X X
FMT_SMF.1 X
FMT_MOF.1 X
FMT_MTD.1 X
FMT_MSA.1 X X
FMT_MSA.3 X
FPT_FLS.1 X X
FPT_TST.1 X X
Table 11. Security Requirements to Security Objective Mapping
ISSUE A
7-12
The security objective of the SFR mapping rationale is summarized in the table below.
Security objective SFR Mapping Rationale
O.DATA_ACC FIA_UID.2 This requirement helps meet the
objective by ensuring only the legitimate
user can access the user data in the
internal storage.
FCS_COP.1/AES This requirement helps meet the
objective by ensuring that user data is
encrypted in the internal storage and only
accessible by the legitimate user.
FDP_RIP.1 This requirement helps meet the
objective by ensuring that SKM is
zeroized from the TOE after use.
FDP_ACF.1 This requirement helps meet the
objective by ensuring that the Subject
with the role "Identified User" is allowed
to encrypt and decrypt (based on
FCS_COP.1/AES) user data and import
SKM into the TOE.
FDP_ACC.1
FMT_SMR.1 This requirement helps meet the
objective by ensuring only legitimate
smartcards can access the user data.
FMT_MSA.1 This requirement helps meet the
objective by ensuring that no users can
modify the security attribute: Role.
O.ADMIN_ACC FIA_UID.2 This requirement helps meet the
objective by ensuring that access to the
TOE’s administrative functions is
granted only upon the insertion of a
paired smartcard.
FIA_UAU.2 This requirement helps meet the
objective by ensuring that only
authenticated Administrators can access
the TOE’s administrative functions.
FIA_SOS.1 This requirement helps meet the
objective by ensuring that the Admin PIN
is 8 digits in length.
ISSUE A
7-13
Security objective SFR Mapping Rationale
FIA_AFL.1 This requirement helps meet the
objective by ensuring that access to
administrative functions will be made
unavailable upon 8 unsuccessful
authentication attempts.
FCS_COP.1/Hash This requirement helps meet the
objective by ensuring that the Admin PIN
is stored as a hash using SHA-256.
FDP_RIP.1 This requirement helps meet the
objective by ensuring that Admin PIN is
zeroized from TOE.
FMT_MTD.1 This requirement helps meet the
objective by ensuring that only the
Administrator can access the TSF data on
the TOE.
FMT_SMF.1 This requirement helps meet the
objective by providing administrative
functions for the management of the
TOE.
FMT_SMR.1 This requirement helps meet the
objective by ensuring only legitimate
Administrators can access the
administrative functions.
FMT.MOF.1 This requirement helps meet the
objective by ensuring that only
authenticated Administrators can access
the administrative functions.
FMT.MSA.1
This requirement helps meet the
objective by ensuring that only legitimate
administrators can modify the security
attribute: Role.
FMT.MSA.3
This requirement helps meet the
objective by ensuring that no one shall be
able to define initial restrictive values for
the security attribute: Role.
O.TOE_INTEGRITY FCS_COP.1/Hash This requirement ensures the integrity of
the TOE configuration through the use of
SHA-256 hash
ISSUE A
7-14
Security objective SFR Mapping Rationale
FPT_FLS.1 This requirement helps meet the
objective by ensuring that the TOE will
enter a “halt” state with secret parameters
zeroized when the integrity of the TOE is
deemed compromised or at risk (e.g.,
POST failure).
FPT_TST.1 This requirement helps meet the
objective by ensuring that the TOE will
self-test to ensure that the TOE can
operate correctly and that the integrity of
internal application data and TSF data
stored persistently in the TOE is intact.
O.ENCRYPT FCS_CKM.1 This requirement provides the key
derivation function for the encryption
key that is utilised in FCS_COP.1/AES.
FCS.CKM.4/MCU This requirement helps meet the
objective by ensuring that the DEK is
zeroized from the MCU memory. E.g.,
upon removal of the smartcard when
lockout mode is enabled. This is to
minimize any possible compromise of
the DEK.
FCS_CKM.4/Crypto This requirement helps meet the
objective by ensuring that the DEK is
zeroized from the Cryptographic Module
memory. E.g., upon removal of the
smartcard when lockout mode is enabled.
This is to minimize any possible
compromise of the DEK.
FCS_COP.1/AES This requirement helps meet the
objective by ensuring that all user data
are encrypted using the AES-256 XTS
algorithm.
FPT_FLS.1 This requirement helps meet the
objective by ensuring that in the event of
a malfunction of the Cryptographic
module which performs the full disk
encryption, the TOE will enter a “halt”
state with secret parameters zeroized
when the integrity of the device is
deemed compromised or at risk (e.g.,
KAT failure).
ISSUE A
7-15
Security objective SFR Mapping Rationale
FPT_TST.1 This requirement helps meet the
objective by ensuring that the
cryptographic function of the TOE which
performs the full disk encryption is
functional and unaltered.
Table 12. Security Objective to SFR mapping Rationale
ISSUE A
7-16
Security Assurance Requirements
The security assurance requirements for the TOE are the Evaluation Assurance Level 2
components, as specified in (CC) part 3. No operations are applied to the assurance components.
The assurance components are summarised in the table below.
Assurance Class Assurance components
ADV: Development
ADV_ARC.1 Security architecture description
ADV_FSP.2 Security-enforcing functional
specification
ADV_TDS.1 Basic design
AGD: Guidance documents
AGD_OPE.1 Operational user guidance
AGD_PRE.1 Preparative procedures
ALC: Life-cycle support
ALC_CMC.2 Use of a CM system
ALC_CMS.2 Parts of the TOE CM coverage
ALC_DEL.1 Delivery procedures
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.1 Evidence of Coverage
ATE_FUN.1 Functional testing
ATE_IND.2 Independent testing - sample
AVA: Vulnerability assessment AVA_VAN.2 Vulnerability analysis
Table 13. Assurance Components
ISSUE A
7-17
Security Assurance Requirement Rationale
The evaluation assurance package selected for the evaluation of the TOE is Evaluation Assurance
Level 2 (EAL2). EAL2 was chosen to provide a low to moderate level of assurance that is
consistent with commercial products of this sort. The chosen assurance level is appropriate for the
threats defined for the environment (limited interface and access to the TOE).
ISSUE A
8-1
Chapter 8 – TOE Summary Specification
This section summarizes the Security Functions of the TOE (TSF) - a high-level description of
how the TOE implements the claimed security functional requirements.
SF1 – Identification and Authentication
The default state upon the powering up of the TOE provides access only to the identification and
authentication mechanism.
Identification
Each smartcard is paired to a TOE by a “MatchID”. The MatchID is required for both User and
Administrator access. The MatchID of the smartcard is verified against the MatchID stored in the
TOE.
Users are first required to insert a paired smartcard containing the correct SKM. Upon successful
identification of the smartcard (MatchID) and, subsequently, successful authentication by the
smartcard, the SKM will be allowed to be imported by the TOE allowing decryption of the data
(Master Boot Record, file allocation table, etc) to enable access to the user data that is encrypted
in the internal storage. If an unpaired smartcard is inserted, no access to the decryption/encryption
function is allowed.
Authentication
Administrators, similarly, are required to insert a paired smartcard and authenticate successfully
to the TOE to successfully invoke any Admin function (modification of: Admin PIN, lockout mode
- DKM, MatchID) of the TOE. The administrator is required to enter an 8-digit PIN to authenticate
to the TOE. The TOE maintains a counter of the number of failed consecutive Admin
authentication attempts. All-access to administrative functions will be blocked after 8 consecutive
wrong PIN entries. In the event, that an unpaired smartcard is inserted, only access to the Admin
functions: initialize smartcard shall be allowed upon successful authentication.
The TOE is also designed with a “lockout mode” feature. If lockout mode is enabled, the TOE
shall automatically zeroize the DEK whenever the smartcard is removed. This would require users
to re-perform the authentication process to gain user access.
This TSF is mapped to the following SFRs: FIA_UID.2, FIA_UAU.2, FIA_AFL.1, FDP_ACC.1,
FDP_ACF.1, FMT_MSA.1, FMT_MSA.3, FMT_SMR.1, FIA_SOS.1
SF2 – Cryptographic Support
The TOE provides cryptographic functions such as symmetric data encryption/decryption and
integrity verification using secure hashing.
The SKM retrieved from the inserted smartcard and the DKM that is stored in the TOE are used
as inputs to a key derivation function to generate the DEK. The DEK is then loaded into the
cryptographic module of the TOE where the MBR or file allocation table will be decrypted and
sent to the host PC; thereafter user may access the encrypted data stored in the internal storage of
the TOE.
ISSUE A
8-2
The TOE’s cryptographic module utilizes the DEK to perform real-time data encryption when data
is transferred from the host machine to internal storage and vice versa. Encryption and decryption
of user data are performed by the cryptographic algorithm AES-256 XTS mode.
This TSF is mapped to the following SFRs: FCS_COP.1/AES, FCS_COP.1/Hash, FCS_CKM.1
SF3 – Security Management
The TOE shall provide the following administrative functions to the Administrator:
1) Pairing of the legitimate smartcard to TOE
2) Enable/disable the smartcard lockout mode.
3) Change Admin PIN.
4) DKM injection (device setup)
Option 1: enables the Administrator to pair a smartcard with a TOE using the smartcard’s
MatchID attribute. The smartcard’s MatchID is stored in the TOE.
Option 2: enables the Administrator to enable/disable the lockout mode (enabled by default).
When lockout mode is enabled, the TOE will enter an unauthenticated state whenever the
smartcard is removed from the TOE.
Option 3: enables the Administrator to change the Admin PIN. The Admin PIN must be 8 digits
in length and will be stored as a hash (SHA-256) within the TOE.
Option 4: enables the Administrator to inject the DKM (from the Administrator smartcard) into
the TOE during device setup.
The TOE enters a “halt” state upon the successful invocation of each of the four administrative
functions. The Administrator is required to power cycle the TOE and authenticate again should
they want to invoke any of the administrative functions again.
This TSF is mapped to the following SFRs: FIA_UID.2, FIA_UAU.2, FIA_SOS.1,
FCS_COP.1/Hash, FMT_SMR.1, FMT_SMF.1, FMT_MOF.1, FMT_MSA.1, FMT_MSA.3,
FMT_MTD.1, FDP_ACC.1, FDP_ACF.1
SF4 – Protection of the TSF
The TOE is designed with protection and detection mechanisms to prevent and detect possible
malfunction or compromised TSF/TSF data.
After the DEK is derived from the SKM and DKM, the TOE transfers the DEK to the
cryptographic module and performs the zeroization of the SKM and the DEK from the MCU’s
memory.
The TOE performs zeroization of the Admin PIN upon completion of usage.
The “lockout mode” feature forces the TOE to automatically zeroize the DEK whenever the
smartcard is removed from the TOE..
The TOE performs a POST upon every power-up to perform integrity checks on the MCU, a
critical subsystem of the TOE.
In the event of any POST failure, the TOE will enter a “halt” state. POST includes the following
tests:
1) LED Display Test
2) Memory Read/Write Test (includes MCU’s internal RAM)
ISSUE A
8-3
3) ROM (EEPROM) Integrity Check
4) SHA-256 Hash Check
The cryptographic module conducts a Known Answer Test whenever it is enabled. The TOE
performs zeroization of all parameters (e.g., DEK) upon failure of the KAT.
In the event of failure of any of the above self-tests, the TOE enters a “halt” and secure state, and
the “ERROR” LED will be lighted up. In this state, the TOE is non-operational.
This TSF is mapped to the following SFRs: FCS_CKM.4/MCU, FCS_CKM.4/Crypto,
FCS_COP.1/Hash, FDP_RIP.1, FPT_TST.1, FPT_FLS.1.
ISSUE A
8-4
TOE Summary SFR to TSF mapping
Table 14. SFR to Security Functions mapping
SFR Security Functions
FIA_UAU.2 SF1, SF3
FIA_UID.2 SF1, SF3
FIA_SOS.1 SF3
FIA_AFL.1 SF1
FCS_CKM.1 SF2
FCS_CKM.4/MCU SF4
FCS_CKM.4/Crypto SF4
FCS_COP.1/AES SF2
FCS_COP.1/Hash SF2, SF3, SF4
FDP_RIP.1 SF4
FDP_ACF.1 SF1, SF3
FDP_ACC.1 SF1, SF3
FMT_SMR.1 SF1, SF3
FMT_SMF.1 SF3
FMT.MOF.1 SF3
FMT.MSA.1 SF1, SF3
FMT.MSA.3 SF1, SF3
FMT_MTD.1 SF3
FPT_FLS.1 SF4
FPT_TST.1 SF4