DiskCrypt M10 (Enterprise)
Security Target
(V1.0)
DiskCrypt M10 ST i
DiskCrypt M10 (Enterprise)
Security Target
Contents
Chapter 1 Security Target Introduction ................................................................................1
1.1 Security Target Reference...................................................................................1
1.2 TOE Reference Identification.............................................................................1
1.3 TOE Overview....................................................................................................2
1.3.1 TOE Type ..................................................................................................4
1.3.2 Non-TOE Hardware/Software and Firmware ...........................................4
1.4 TOE Description.................................................................................................5
1.4.1 Physical Scope of the TOE........................................................................5
1.4.2 Logical Scope of the TOE.........................................................................5
Chapter 2 Conformance Claims..............................................................................................8
Chapter 3 Security Problem Definition ..................................................................................9
3.1 Asset.......................................................................................................................9
3.2 Threats....................................................................................................................9
3.3 Organizational Security Policies ..........................................................................10
3.4 Assumptions.........................................................................................................10
Chapter 4 Security Objectives...............................................................................................11
4.1 Security Objectives for the TOE.......................................................................11
4.2 Security Objectives for the Operational Environment .........................................11
4.3 Security Objective Rationale................................................................................12
Chapter 5 Extended components definition.........................................................................13
Chaper 6 IT Security Requirements.....................................................................................14
6.1 Conventions ......................................................................................................14
6.2 Security Functional Requirements....................................................................14
6.1.1 Class FIA: Identification and Authentication.........................................14
6.1.2 Class FCS: Cryptographic support .........................................................15
6.1.2 Class FDP: User Data Protection ............................................................16
6.1.3 Class FMT: Security management ..........................................................17
6.1.4 Class FPT: Protection of the TSF............................................................18
6.3 Security Requirement Dependency Rationale ..................................................19
DiskCrypt M10 ST ii
6.4 Security Requirements to Security Objective Mapping....................................20
6.5 Security Assurance Requirements ....................................................................24
6.5.1 Rationale for Security Assurance Requirements ..............................................25
Chapter 7 TOE Summary Specification...............................................................................26
7.1 SF1 – Identification and Authentication...........................................................26
7.2 SF2 – Cryptographic Support ...........................................................................26
7.3 SF3 – Security Management............................................................................27
7.4 SF4 – Protection of the TSF..............................................................................27
7.5 TOE Summary SFR to TSF mapping ...............................................................28
DiskCrypt M10 ST iii
List of Illustrations
Table 1 - Assets protected by the TOE............................................................................................9
Table 3 - Threat Statements...........................................................................................................10
Table 4 – Assumptions ..................................................................................................................10
Table 5 - Security Objectives for the TOE....................................................................................11
Table 6 - Security Objectives for the Operational Environment...................................................11
Table 7 - Security Objective Rationale..........................................................................................12
Table 8 - Security Requirement Dependency Rationale ...............................................................20
Table 9 - Security Requirements to Security Objective Mapping.................................................21
Table 10 - Security Objective to SFR mapping Rationale ............................................................24
Table 11 - Assurance Components................................................................................................25
Table 12 - SFR to Security Functions mapping ............................................................................29
DiskCrypt M10 ST 1
Chapter 1 Security Target Introduction
This document defines the security functionality of the target of evaluation (TOE) "DiskCrypt
M10 (Enterprise)"
1.1 Security Target Reference
Security Target Reference:
DiskCrypt M10 (Enterprise) Security Target
Security Target Publication Date: 17 February 2020
Document Version: 1.0
1.2 TOE Reference Identification
TOE Reference:
DiskCrypt M10 (Enterprise)
Ver: M321P32J1E1
DiskCrypt M10 comes with 6 colors (Cool Grey, Dynamic Blue, Vibrant Green, Charming Pink,
Mystic Purple, Scarlet Red).
Charming Pink Cool Grey Dynamic Blue
DiskCrypt M10 ST 2
Scarlet Red Mystic Purple Vibrant Green
1.3 TOE Overview
The TOE is a credit card size USB storage enclosure which provides a full disk
encryption/decryption function for user data stored in the M.2 SATA III Solid State Drive (SSD,
2242 form factor) within the TOE.
The TOE interoperates with an authorized paired smartcard which stores the input keying material
to the key derivation function for the Data Encryption Key (DEK). The smartcard and the PIN to
the smartcard must be provided by the user before access to the user data is granted.
DiskCrypt M10 ST 3
TOE Usage
The TOE has a built-in keypad and smartcard reader. It is powered via its USB interface (USB
3.1) by connecting it to a host machine (USB 3.1/3.0/2.0 are supported). The TOE requires users
to insert their authorized external smartcard and input his/her smartcard PIN via the integrated
keypad of the TOE to authenticate to the smartcard. Upon successful user authentication to the
smartcard, access to the user data is granted.
Security Features
The TOE employs hardware-based full disk encryption using the AES-256 XTS algorithm to
encrypt all data stored in the M.2 SSD.
The TOE performs full disk encryption using a Data Encryption key (DEK) derived from 2
separate keying materials. The first keying material (SKM – Smartcard Keying Material) is
retrieved from the user smartcard. 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.
M.2 SSD
DiskCrypt M10 ST 4
The TOE is inbuilt with self-test mechanisms – Power-On-Self-Test (POST) and Known Answer
Test (KAT). These self-tests mechanisms ensure the integrity and functionality of the TOE.
The TOE provides the following administrative functions:
1) Pairing of smartcard
2) DKM injection (during device setup)
3) Enable/disable smartcard 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 smartcard and providing the Admin PIN. The TOE
will disable the administrative function if there are eight consecutive Administrator authentication
failures.
Prior to the issuance of the TOE and smartcard to the end-user, the TOE requires the Administrator
to setup each TOE with its associated smartcards through the invocation of the above mentioned
TOE administrative functions.
1.3.1 TOE Type
The TOE is a credit card size USB encrypted storage enclosure which provides real time full disk
encryption/decryption function for user data stored in the M.2 SSD within the TOE.
1.3.2 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) Smartcard – Two types of smartcards are provided: Admin smartcard and
User smartcard. The smartcards are PKCS #11 compliant. The Admin smartcard stores the
DKM and the User smartcard stores the SKM. DKM and SKM are inputs to the key
derivation function for the DEK. The smartcards are also used for identification.
2. DiskCrypt Key Management Software (DMS) – The smartcards issued along with the
DiskCrypt M10 are provisioned by the Administrator using the DiskCrypt Key Management
software (DMS). The DMS is an external software application for enterprises to manage their
own smartcards and SKM for usage with DiskCrypt M10.
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 smartcards issued with DiskCrypt. It
communicates with the smartcards through a PKCS #11 module.
4. Host Workstation – The TOE requires a host system that provides an USB interface (USB
3.1/3.0/2.0) supporting the USB mass storage device class.
5. KeyCrypt Token – Used for 2FA login to the DMS software application.
DiskCrypt M10 ST 5
6. M.2 SATA III SSD – The SSD consists of 2242 form factor and has max height of 3.6mm.
It is also Multi-level cell (MLC) NAND flash type.
1.4 TOE Description
1.4.1 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 smartcard and the M.2 SATA SSD.
The scope of delivery (of the TOE) is listed as follow:
No. Delivery Items Type Part of TOE
1 DigiSAFE DiskCrypt M10
(See Table 1.)
Hardware Yes
2 DC Smartcards (User and Admin) Hardware No
3 USB 3.1 cable Hardware No
4 DiskCrypt M10 User Manual Soft Copy – Download
from website
Yes
5 M.2 SATA III SSD Hardware No
6 DMS Software Software Application No
7 AWP Manager Software Software Application No
8 DiskCrypt M10 Administrator Guide Soft copy Document
(*.pdf)
Yes
9 DiskCrypt Key Management Software
(DMS) Guide
Soft copy Document
(*.pdf)
No
10 AWP Manager Guide Soft copy Document
(*.pdf)
No
Items 6-10 (software deliverables and soft copy documents) are burnt into a CD and along with
the other items from 1,2,3 and 5 are packaged in a box and delivered via either:
 In-house delivery – for Local delivery (Singapore)
 Trusted courier – for Overseas delivery
The TOE is shipped with a default factory configuration.
1.4.2 Logical Scope of the TOE
The TOE provides the core security functionalities in the following areas.
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.
DiskCrypt M10 ST 6
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 the paired Admin 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.
Cryptographic Support
User data sent from the host machine via the USB interface will be encrypted and stored in the
M.2 SSD. 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 – Smartcard
Keying Material) is retrieved from the user smartcard. 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 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.
Administrative Management
The TOE provides the following administrative functions:
1) Injection of DKM into the TOE during device setup
2) Pairing a User smartcard with the TOE
3) Change Admin Pin
4) Enable/disable the Smartcard Lockout mode
This function controls the behavior of TOE when the smartcard is removed (after user
authentication). The Smartcard Lockout mode is enabled by default: In this mode, DEK
is zeroized from internal RAM memory upon removal of smartcard. The TOE requires
users to re-authenticate to the smartcard should the user wish to access the user data again.
If Smartcard Lockout mode is disabled, users may continue to access the encrypted user
data even after smartcard removal.
Protection of TSF
The TOE implements the Power-On Self-Test (POST) of the Micro Controller Unit (MCU) during
initial startup to ensure the integrity and functionality. Separately, the TOE implements a Known
Answer Test of the cryptographic module upon the cryptographic module’s startup to ensure
correct operation.
The TOE performs zeroization of the Admin PIN.
DiskCrypt M10 ST 7
The TOE’s critical components such encryption chip and MCU chip are stycast protected and any
tampering can be detected (through visual inspection).
DiskCrypt M10 ST 8
Chapter 2 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. The ST claims conformance to the following Protection Profiles:
None.
DiskCrypt M10 ST 9
Chapter 3 Security Problem Definition
3.1 Asset
The TOE is concerned with the protection of the following assets enumerated in the table below.
Identifier Asset statement
AST.DATA SKM, confidential plaintext user data stored in or
processed by the TOE.
AST.TSF_DATA MatchID, DEK, DKM, Admin PIN and configuration data
of the TOE.
Table 1 - Assets protected by the TOE
The subjects, some of which constitutes threat agents as highlighted in the description of threats,
are stated in Table 3.
Subjects Subject definition
Unidentified User A user who has no access to the user data and TOE
administrative functions.
Identified User A user who has access to the encrypted user data stored on
the SSD.
Adminstrator Legitimate Administrator accessing the administrative
functions of the TOE.
Table 2 - Subjects relevant to the TOE
3.2 Threats
Threats enumerated in 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 means of logical attack on the TOE
through the available interfaces provided by the TOE.
T.PHYSICAL_ACC An attacker compromises the confidentiality of
AST.DATA or gain unauthorized access to
AST.TSF_DATA by means of physical attack, bypassing
the logical interfaces of the TOE.
DiskCrypt M10 ST 10
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 3 - Threat Statements
3.3 Organizational Security Policies
No organizational security policy is defined for the TOE.
3.4 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, trained, competent,
and adheres to all guidance documentation provided.
A.SMARTCARD DC Smartcard provides appropriate protection for the
SKM.
Table 4 – Assumptions
DiskCrypt M10 ST 11
Chapter 4 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.
4.1Security 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 are 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 M.2 SSD is encrypted, providing
confidentiality protection in the event of physical and logical
attacks on the TOE.
Table 5 - Security Objectives for the TOE
4.2 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 in
accordance to the admin guidance documentation.
OE.SMARTCARD The cryptographic 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 - Security Objectives for the Operational Environment
DiskCrypt M10 ST 12
4.3 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 makes use of OE.SMARTCARD
for user identification and storage of SKM.
T.PHYSICAL_ACC O.ENCRYPT
OE.TRUSTED_USER
O.TOE_INTEGRITY
O.ENCRYPT ensures that user data are
encrypted prior to storage in the M.2 SSD,
hence preventing adversaries from
compromising the confidentiality of user data in
the event that the TOE (with M.2 SSD) 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.
T.MALFUNCTION O.TOE_INTEGRITY O.TOE_INTEGRITY requires the TOE to
perform self-tests to ensure that TOE is
functional and TSF data is not modified. In the
event that self-test fails, the TOE shall preserve
a secure state (non-operational).
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 in
accordance to the admin guidance
documentation.
A.SMARTCARD OE.SMARTCARD OE.SMARTCARD ensures that the DC
Smartcard is certified and therefore provides
appropriate protection for the SKM.
Table 7 - Security Objective Rationale
DiskCrypt M10 ST 13
Chapter 5 Extended components definition
There are no extended components applicable to the TOE, hence none of the requirements for the
Extended Components Definition (ASE_ECD) are applicable to this ST.
DiskCrypt M10 ST 14
Chaper 6 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.
6.1Conventions
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
6.2Security Functional Requirements
6.1.1 Class FIA: Identification and Authentication
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.
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 administrator to be successfully authenticated before
allowing any other TSF-mediated actions on behalf of that administrator.
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 Administrator.
DiskCrypt M10 ST 15
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.
6.1.2 Class FCS: Cryptographic support
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 in accordance with a specified cryptographic key
generation algorithm key derivation function and specified cryptographic key sizes 512 bits that
meet the following: None.
Application Note: Applicable to FCS_COP.1/AES
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 in accordance with a specified
cryptographic key destruction method 7 rounds of zeroization that meets the following none.
Application Note: Applicable to zeroization of DEK from MCU.
FCS_CKM.4.1/Crypto The TSF shall destroy cryptographic keys in accordance with 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 Cryptographic module.
FCS_COP.1/AES - Cryptographic operation
Hierarchical to: No other components.
DiskCrypt M10 ST 16
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 in accordance with a
specified cryptographic algorithm AES 256 XTS mode and cryptographic key sizes 512 bits that
meet the following: IEEE P1619 Standard (2007).
FCS_COP.1.1/Hash
The TSF shall perform cryptographic hashing in accordance with a specified cryptographic
algorithm SHA-1 and message digest sizes 160 bits that meet the following: FIPS PUB 180-4,
"Secure Hash Standard".
Application note: SHA-1 used for Integrity check during POST and Admin PIN verification.
6.1.2 Class FDP: User Data Protection
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.
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, SKM
Security Attributes Role as defined in FMT_SMR.1
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 role "Identified User" is allowed to encrypt and decrypt (based on
FCS_COP.1/AES) user data.
 Subject with 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
DiskCrypt M10 ST 17
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the
following additional rules:
 POST Failure
 KAT Failure
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, SKM
Operations
Encryption & Decryption,
Import
6.1.3 Class FMT: Security management
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,
Administrator
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
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
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 functions smartcard
lockout mode to Administrator.
FMT_MTD.1 Management of TSF data
Hierarchical to: No other components.
DiskCrypt M10 ST 18
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, MatchID to Administrator.
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 Role to None.
Application note: Roles are pre-programmed into the TOE and not modifiable
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.
6.1.4 Class FPT: Protection of the TSF
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)
FPT_TST.1 TSF Testing
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_TST.1.1 The TSF shall run a suite of self-tests during initial start-up to demonstrate the
correct operation of the TSF.
DiskCrypt M10 ST 19
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.
6.3Security Requirement Dependency Rationale
SFR Dependency Inclusion/Rationale for Non-inclusion
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
FMT_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1
FCS_CKM.1
FCS_CKM.4/Crypto
FMT_MTD.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
DiskCrypt M10 ST 20
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
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 8 - Security Requirement Dependency Rationale
6.4Security Requirements to Security Objective Mapping
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
DiskCrypt M10 ST 21
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 9 - Security Requirements to Security Objective Mapping
The security objective to 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 identified user is able
to access the user data in the M.2 SSD.
FCS_COP.1/AES This requirement helps meet the objective
by ensuring that user data is encrypted in
the M.2 SSD and only accessible by the
identified 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 Subject with 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 identified users are able
to access the user data.
DiskCrypt M10 ST 22
FMT_MSA.1 This requirement helps meet the objective
by ensuring that no users are able to
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 insertion of a paired smartcard.
FIA_UAU.2 This requirement helps meet the objective
by ensuring that only authenticated
Administrators are able to 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.
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 SHA1.
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 are able to access the
administrative functions.
DiskCrypt M10 ST 23
FMT_MOF.1 This requirement helps meet the objective
by ensuring only authenticated
Administrators are able to access the
administrative functions.
FMT.MSA.1
This requirement helps meet the objective
by ensuring that no one shall be able to
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
SHA1 hash.
FPT_FLS.1 This requirement helps meet the objective
by ensuring that 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 TOE will self-tests to
ensure that the TOE is able to operate
correctly and that the integrity of internal
of 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
smartcard when lockout mode is enabled.
This is to minimize any possible
compromise of the DEK.
DiskCrypt M10 ST 24
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 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 AES-256 XTS algorithm.
FPT_FLS.1 This requirement helps meet the objective
by ensuring that in the event of
malfunction of the Cryptographic module
which performs the full disk encryption,
the TOE will enter a “halt” state with
secret parameters zeroized when integrity
of device is deemed compromised or at
risk (e.g. KAT failure).
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 10 - Security Objective to SFR mapping Rationale
6.5Security 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
DiskCrypt M10 ST 25
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 11 - Assurance Components
6.5.1 Rationale for Security Assurance Requirements
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 with
the threats defined for the environment.
DiskCrypt M10 ST 26
Chapter 7 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.
7.1 SF1 – Identification and Authentication
The default state upon power 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), 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 in the encrypted M.2 SSD. In the event that 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 a 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
automatically enters into an unauthenticated state 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
7.2 SF2 – Cryptographic Support
The TOE provides cryptographic function 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 M.2 SSD of the TOE.
DiskCrypt M10 ST 27
The TOE’s cryptographic module utilizes the DEK to perform real time data encryption when data
is transferred from host machine to M.2 SSD and vice versa. Encryption and decryption of user
data is performed in accordance to 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
7.3 SF3 – Security Management
The TOE shall provide the following administrative functions to the Administrator:
1) Pairing of legitimate smartcard to TOE
2) Enable/disable the smartcard lockout mode.
3) Change of 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 into 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 (SHA1) 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 into a “halt” state upon the successful invocation of each of the four administrative
functions. The Administrator is required to authenticate again should they want to invoke any of
the administrative function 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
7.4 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 enter into an unauthenticated state
whenever the smartcard is removed from the TOE. When the TOE enters into an unauthenticated
state, the DEK stored in the internal RAM of the cryptographic chip will be zeroized.
DiskCrypt M10 ST 28
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)
3) ROM (EEPROM) Integrity Check
4) SHA-1 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 into a “halt” and secure state,
and the “ERROR” LED will be lighted up. In this state, the TOE is non-operational.
The TSF shall resist physical manipulation and probing of critical components such as encryption
chip and MCU chip as they are stycast protected and any tampering can be detected (through visual
inspection).
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.
7.5 TOE Summary SFR to TSF 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
DiskCrypt M10 ST 29
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
Table 12 - SFR to Security Functions mapping