DIGISTOR TCG OPAL SSC FIPS SSD Series,
firmware version SCPG13.0/ECPG13.0/ECPM13.1
Security Target
Version 1.7
March 2023
Document prepared by
www.lightshipsec.com
DIGISTOR Security Target
Page 2 of 33
Document History
Version Date Description
0.1 24 June 2021 Initial draft for client review
0.2 20 Sept 2021 2nd draft for client review.
0.3 4 Oct 2021 Initial draft for evaluation
1.0 9 Feb 2022 Addressed evaluator ORs
1.1 25 April 2022 Modified FCS_VAL_EXT claims. Addressed evaluator ORs.
1.2 11 May 2022 Updated list of hardware models.
1.3 29 June 2022 Updated typo in hardware list.
Added TD0606.
1.4 12 Aug 2022 Addressed validator comments
1.5 4 Oct 2022 Updated ST title and vendor references.
1.6 19 Jan 2023 Addressed evaluator ORs.
1.7 2 March 2023 Addressed ORs.
DIGISTOR Security Target
Page 3 of 33
Table of Contents
1 Introduction ........................................................................................................................... 4
1.1 Overview ........................................................................................................................ 4
1.2 Identification ................................................................................................................... 4
1.3 Conformance Claims...................................................................................................... 4
1.4 Terminology.................................................................................................................... 5
2 TOE Description.................................................................................................................... 8
2.1 Type ............................................................................................................................... 8
2.2 Usage ............................................................................................................................. 8
2.3 Security Functions / Logical Scope................................................................................ 8
2.4 Physical Scope............................................................................................................... 9
3 Security Problem Definition............................................................................................... 13
3.1 Threats ......................................................................................................................... 13
3.2 Assumptions................................................................................................................. 14
3.3 Organizational Security Policies................................................................................... 15
4 Security Objectives............................................................................................................. 16
5 Security Requirements....................................................................................................... 17
5.1 Conventions ................................................................................................................. 17
5.2 Extended Components Definition................................................................................. 17
5.3 Functional Requirements ............................................................................................. 18
5.4 Assurance Requirements............................................................................................. 26
6 TOE Summary Specification.............................................................................................. 27
6.1 Cryptographic Support (FCS)....................................................................................... 27
6.2 User Data Protection (FDP) ......................................................................................... 30
6.3 Security Management (FMT) ....................................................................................... 31
6.4 Protection of the TSF (FPT) ......................................................................................... 31
7 Rationale.............................................................................................................................. 33
7.1 Conformance Claim Rationale ..................................................................................... 33
7.2 Security Objectives Rationale ...................................................................................... 33
7.3 Security Requirements Rationale................................................................................. 33
List of Tables
Table 1: Evaluation identifiers ......................................................................................................... 4
Table 2: NIAP Technical Decisions ................................................................................................. 4
Table 3: Terminology....................................................................................................................... 5
Table 4: CAVP Certificates.............................................................................................................. 8
Table 5: TOE Hardware / Firmware................................................................................................. 9
Table 6: Threats............................................................................................................................. 13
Table 7: Assumptions .................................................................................................................... 14
Table 8: Security Objectives for the Operational Environment ..................................................... 16
Table 9: Extended Components.................................................................................................... 17
Table 10: Summary of SFRs ......................................................................................................... 18
Table 11: Assurance Requirements .............................................................................................. 26
Table 12: Cryptographic Key Usage, Storage, and Destruction ................................................... 28
Table 13: TSF Self-Tests............................................................................................................... 32
DIGISTOR Security Target
Page 4 of 33
1 Introduction
1.1 Overview
1 This Security Target (ST) defines the DIGISTOR Target of Evaluation (TOE) for the
purposes of Common Criteria (CC) evaluation.
2 DIGISTOR Secure SSDs provide for AES encryption and decryption of user data
stored on NAND flash, offered on NVMe PCIe and SATA III Self-Encrypting Drives
(SEDs).
1.2 Identification
Table 1: Evaluation identifiers
Target of Evaluation DIGISTOR TCG OPAL SSC FIPS SSD Series, firmware version
SCPG13.0/ECPG13.0/ECPM13.1
Security Target DIGISTOR TCG OPAL SSC FIPS SSD Series, firmware version
SCPG13.0/ECPG13.0/ECPM13.1, Security Target, v1.7
1.3 Conformance Claims
3 This ST supports the following conformance claims:
a) CC version 3.1 revision 5
b) CC Part 2 extended
c) CC Part 3 conformant
d) collaborative Protection Profile for Full Drive Encryption – Encryption Engine,
v2.0 + Errata 20190201 (referenced within as CPP_FDE_EE)
e) NIAP Technical Decisions per Table 2
Table 2: NIAP Technical Decisions
TD # Name Rationale if n/a
TD0458 FIT Technical Decision for FPT_KYP_EXT.1 evaluation
activities
TD0460 FIT Technical Decision for FPT_PWR_EXT.1 non-
compliant power saving states
TD0464 FIT Technical Decision for FPT_PWR_EXT.1 compliant
power saving states
TD0606 FIT Technical Recommendation for Evaluating a NAS
against the FDE AA and FDEE
The TOE is not a NAS
device.
DIGISTOR Security Target
Page 5 of 33
1.4 Terminology
Table 3: Terminology
Term Definition
AA Authorization Acquisition
AES Advanced Encryption Standard
BEV Border Encryption Value
BIOS Basic Input Output System
CBC Cipher Block Chaining
CC Common Criteria
CEM Common Evaluation Methodology
CMOS Complementary Metal-Oxide Semiconductor
CPP Collaborative Protection Profile
DAR Data At Rest
DEK Data Encryption Key
DRBG Deterministic Random Bit Generator
DSS Digital Signature Standard
EE Encryption Engine
EEPROM Electrically Erasable Programmable Read-Only Memory
FIPS Federal Information Processing Standards
FDE Full Drive Encryption
GUI Graphical User Interface
HMAC Keyed-Hash Message Authentication Code
HW Hardware
IEEE Institute of Electrical and Electronics Engineers
IT Information Technology
ISO/IEC International Organization for Standardization / International
Electrotechnical Commission
DIGISTOR Security Target
Page 6 of 33
Term Definition
IV Initialization Vector
KEK Key Encryption Key
KMD Key Management Description
KW Key Wrap
MBR Master Boot Record
NIST National Institute of Standards and Technology
NVMe PCIe Non-Volatile Memory Express Peripheral Component
Interconnect Express
OS Operating System
OTP One-Time Programmable
PBKDF Password-Based Key Derivation Function
PRF Pseudo Random Function
RBG Random Bit Generator
RNG Random Number Generator
RSA Rivest Shamir Adleman Algorithm
RTU Root of Trust
SATA Serial Advanced Technology Attachment
SAR Security Assurance Requirements
SED Self-Encrypting Drive
SHA Secure Hash Algorithm
SFR Security Functional Requirements
SSD Solid-State Drive
ST Security Target
SPD Security Problem Definition
TCG Opal Trusted Computing Group Opal
TOE Target of Evaluation
DIGISTOR Security Target
Page 7 of 33
Term Definition
TSF TOE Security Functionality
TSS TOE Summary Specification
USB Universal Serial Bus
XOR Exclusive or
XTS XEX (XOR Encrypt XOR) Tweakable Block Cipher with
Ciphertext Stealing
DIGISTOR Security Target
Page 8 of 33
2 TOE Description
2.1 Type
4 The TOE is a solid state self-encrypting drive that provides encryption and
decryption of stored user data.
2.2 Usage
5 The TOE provides full drive encryption to protect data at rest on a lost or stolen
device. The Encryption Engine (EE) ensures that the data is encrypted using FIPS-
validated algorithms. It manages the encryption and decryption of the stored data,
policy enforcement, and key management.
2.3 Security Functions / Logical Scope
6 The TOE provides the following security functions:
a) Data Protection. The TOE enables encryption and decryption of user data on
a SED to protect it from unauthorized disclosure.
b) Secure Key Material. The TOE ensures key material used for storage
encryption is properly generated and protected from disclosure. It also
implements cryptographic key and key material destruction during
transitioning to a Compliant power saving state, or when all keys and key
material are no longer needed.
c) Secure Management. The TOE enables management of its security
functions, including:
i) Changing and erasing the DEK
ii) Updating the TOE firmware
d) Trusted Update. The TOE ensures the authenticity and integrity of firmware
updates through digital signatures using RSA 2048 with SHA-256.
e) Self-Testing. The TOE ensures its integrity and operation by performing self-
tests.
f) Cryptographic Operations. The TOE performs cryptographic operations as
shown in Table 4, which includes relevant Cryptographic Algorithm Validation
Program (CAVP) certificates.
Table 4: CAVP Certificates
Capability Certificate
AES-XTS – Encrypt/Decrypt C1356, C1358
HMAC-DRBG – Deterministic Random Bit
Generation
C1356, C1358
HMAC – Message Authentication C1356, C1358
AES-KW – Key Wrapping C1356, C1358
DIGISTOR Security Target
Page 9 of 33
Capability Certificate
RSA - Sig Ver C1356, C1358
SHS – Password Protection C1356, C1358
PBKDF2 – Password Derivation A1725, A1726
2.4 Physical Scope
7 The physical boundary of the TOE encompasses the DIGISTOR Secure SSD
firmware running on the SEDs identified in Table 5. The TOE hardware is delivered
to customers via trusted courier with the firmware preinstalled.
8 The TOE models support either NVMe PCIe or SATA III interfaces. All TOE models
incorporate an ARM Cortex-R5 processor (ARMv7-R microarchitecture).
Table 5: TOE Hardware / Firmware
Drive Capacity
FIPS HW P/N &
Version
CC/NIAP Listed
HW P/N &
Version
Controller
FW
Version
DIGISTOR
2.5-Inch SATA
SSD
128GB DIG-SSD21286-SI DIG-SSD21286-SI PS3112-S12 SCPG13.0
256GB DIG-SSD22566-SI DIG-SSD22566-SI
512GB DIG-SSD25126-SI DIG-SSD25126-SI
1024GB DIG-SSD210006-SI DIG-SSD210006-SI
2048GB DIG-SSD220006-SI DIG-SSD220006-SI
DIGISTOR
M.2 2280
SATA SSD
128GB DIG-M21286-SI DIG-M21286-SI
256GB DIG-M22566-SI DIG-M22566-SI
512GB DIG-M25126-SI DIG-M25126-SI
1024GB DIG-M210006-SI DIG-M210006-SI
2048GB DIG-M220006-SI DIG-M220006-SI
DIGISTOR
M.2 2280
NVMe SSD
256GB DIG-M2N22566-UI DIG-M2N22566-UI PS5012-E12 ECPG13.0
512GB DIG-M2N25126-UI DIG-M2N25126-UI
1024GB DIG-M2N210006-UI DIG-M2N210006-UI
2048GB DIG-M2N220006-UI DIG-M2N220006-UI
DIGISTOR Security Target
Page 10 of 33
Drive Capacity
FIPS HW P/N &
Version
CC/NIAP Listed
HW P/N &
Version
Controller
FW
Version
DIGISTOR
2.5-Inch SATA
SSD
128GB DIG-SSD21286-SI DIG-SSD212832 PS3112-S12 SCPG13.0
256GB DIG-SSD22566-SI DIG-SSD225632
512GB DIG-SSD25126-SI DIG-SSD251232
1024GB DIG-SSD210006-SI DIG-SSD2100032
2048GB DIG-SSD220006-SI DIG-SSD2100032
DIGISTOR
M.2 2280
SATA SSD
128GB DIG-M21286-SI DIG-M212832
256GB DIG-M22566-SI DIG-M225632
512GB DIG-M25126-SI DIG-M251232
1024GB DIG-M210006-SI DIG-M2100032
2048GB DIG-M220006-SI DIG-M2100032
DIGISTOR
M.2 2280
NVMe SSD
256GB DIG-M2N22566-UI DIG-M2N225632 PS5012-E12 ECPG13.0
512GB DIG-M2N25126-UI DIG-M2N251232
1024GB DIG-M2N210006-UI DIG-M2N2100032
2048GB DIG-M2N220006-UI DIG-M2N2100032
DIGISTOR
Ships
Removable
NVMe SSD
256GB DIG-M2N22566-UI Q80-M2N225632
512GB DIG-M2N25126-UI Q80-M2N251232
1024GB DIG-M2N210006-UI Q80-M2N2100032
2048GB DIG-M2N220006-UI Q80-M2N2200032
256GB DIG-M2N22566-UI Q80R-M2N225632
512GB DIG-M2N25126-UI Q80R-M2N251232
1024GB DIG-M2N210006-UI Q80R-M2N2100032
2048GB DIG-M2N220006-UI Q80R-M2N2200032
DIGISTOR C
Series FW M.2
2280 NVMe
SSD
256GB DIG-M2N22566-AI DIG-M2N225633 PS5012-E12 ECPM13.1
512GB DIG-M2N25126-AI DIG-M2N251233
1024GB DIG-M2N210006-AI DIG-M2N2100033
2048GB DIG-M2N220006-AI DIG-M2N2200033
DIGISTOR Security Target
Page 11 of 33
Drive Capacity
FIPS HW P/N &
Version
CC/NIAP Listed
HW P/N &
Version
Controller
FW
Version
DIGISTOR
Ships
Removable C
Series FW
NVMe SSD
256GB DIG-M2N22566-AI Q80-M2N225633
512GB DIG-M2N25126-AI Q80-M2N251233
1024GB DIG-M2N210006-AI Q80-M2N2100033
2048GB DIG-M2N220006-AI Q80-M2N2200033
256GB DIG-M2N22566-AI Q80R-M2N225633
512GB DIG-M2N25126-AI Q80R-M2N251233
1024GB DIG-M2N210006-AI Q80R-M2N2100033
2048GB DIG-M2N220006-AI Q80R-M2N2200033
2.4.1 Guidance Documents
9 The TOE includes the following guidance documents:
a) DIGISTOR TCG OPAL SSC FIPS SSD Series, firmware version
SCPG13.0/ECPG13.0/ECPM13.1, Common Criteria Guide, v1.3 (PDF).
2.4.2 Non-TOE Components
10 The TOE operates with the following components in the environment:
a) Authorization Acquisition. KLC CipherDrive v1.2.2 software installed on a
128 MB read-only Shadow MBR partition on the SED. This supplies the
Border Encryption Value (BEV) for locking and unlocking the drives. The KLC
software provides the GUI used for performing the security management
functions described within this ST.
b) Protected OS. The TOE supports protection of commonly used operating
systems, such as Linux Operating Systems/Linux based Hypervisors and
Windows Operating Systems.
c) Computer Hardware. Intel based UEFI booted systems that supports Intel
Secure Key Technology. CC Testing performed using CPUs:
i) Intel Core i3-8100
ii) Intel Core i5-8400
iii) Intel Core i5-9600
iv) Intel Core i7-3770K
DIGISTOR Security Target
Page 12 of 33
2.4.3 Security Functions not included in the TOE Evaluation
11 The evaluation is limited to those security functions identified in section 2.3.
12 The following configuration has not been evaluated:
a) Use of multiple drives.
DIGISTOR Security Target
Page 13 of 33
3 Security Problem Definition
13 The Security Problem Definition is reproduced from the CPP_FDE_EE.
3.1 Threats
Table 6: Threats
Identifier Description
T.UNAUTHORIZED_
DATA_ACCESS
The cPP addresses the primary threat of unauthorized disclosure of
protected data stored on a storage device. If an adversary obtains a
lost or stolen storage device (e.g., a storage device contained in a
laptop or a portable external storage device), they may attempt to
connect a targeted storage device to a host of which they have
complete control and have raw access to the storage device (e.g., to
specified disk sectors, to specified blocks).
T.KEYING_MATERIA
L_COMPROMISE
Possession of any of the keys, authorization factors, submasks, and
random numbers or any other values that contribute to the creation of
keys or authorization factors could allow an unauthorized user to
defeat the encryption. The cPP considers possession of keying
material of equal importance to the data itself. Threat agents may look
for keying material in unencrypted sectors of the storage device and
on other peripherals in the operating environment (OE), e.g. BIOS
configuration, SPI flash, or TPMs.
T.AUTHORIZATION_
GUESSING
Threat agents may exercise host software to repeatedly guess
authorization factors, such as passwords and PINs. Successful
guessing of the authorization factors may cause the TOE to release
DEKs or otherwise put it in a state in which it discloses protected data
to unauthorized users.
T.KEYSPACE_
EXHAUST
Threat agents may perform a cryptographic exhaust against the key
space. Poorly chosen encryption algorithms and/or parameters allow
attackers to exhaust the key space through brute force and give them
unauthorized access to the data.
T.KNOWN_
PLAINTEXT
Threat agents know plaintext in regions of storage devices, especially
in uninitialized regions (all zeroes) as well as regions that contain well
known software such as operating systems. A poor choice of
encryption algorithms, encryption modes, and initialization vectors
along with known plaintext could allow an attacker to recover the
effective DEK, thus providing unauthorized access to the previously
unknown plaintext on the storage device.
T.CHOSEN_
PLAINTEXT
Threat agents may trick authorized users into storing chosen plaintext
on the encrypted storage device in the form of an image, document, or
some other file. A poor choice of encryption algorithms, encryption
modes, and initialization vectors along with the chosen plaintext could
allow attackers to recover the effective DEK, thus providing
unauthorized access to the previously unknown plaintext on the
storage device.
DIGISTOR Security Target
Page 14 of 33
Identifier Description
T.UNAUTHORIZED_
UPDATE
Threat agents may attempt to perform an update of the product which
compromises the security features of the TOE. Poorly chosen update
protocols, signature generation and verification algorithms, and
parameters may allow attackers to install software that bypasses the
intended security features and provides them unauthorized access to
data.
T.UNAUTHORIZED_
FIRMWARE_
UPDATE
An attacker attempts to replace the firmware on the SED via a
command from the AA or from the host platform with a malicious
firmware update that may compromise the security features of the
TOE.
T.UNAUTHORIZED_
FIRMWARE_MODIFY
An attacker attempts to modify the firmware in the SED via a
command from the AA or from the host platform that may compromise
the security features of the TOE.
3.2 Assumptions
Table 7: Assumptions
Identifier Description
A.TRUSTED_
CHANNEL
Communication among and between product components (e.g., AA
and EE) is sufficiently protected to prevent information disclosure. In
cases in which a single product fulfils both cPPs, then the
communication between the components does not extend beyond the
boundary of the TOE (e.g., communication path is within the TOE
boundary). In cases in which independent products satisfy the
requirements of the AA and EE, the physically close proximity of the
two products during their operation means that the threat agent has
very little opportunity to interpose itself in the channel between the two
without the user noticing and taking appropriate actions.
A.INITIAL_DRIVE_
STATE
Users enable Full Drive Encryption on a newly provisioned storage
device free of protected data in areas not targeted for encryption. It is
also assumed that data intended for protection should not be on the
targeted storage media until after provisioning. The cPP does not
intend to include requirements to find all the areas on storage devices
that potentially contain protected data. In some cases, it may not be
possible - for example, data contained in “bad” sectors. While
inadvertent exposure to data contained in bad sectors or unpartitioned
space is unlikely, one may use forensics tools to recover data from
such areas of the storage device. Consequently, the cPP assumes
bad sectors, un-partitioned space, and areas that must contain
unencrypted code (e.g., MBR and AA/EE pre-authentication software)
contain no protected data.
DIGISTOR Security Target
Page 15 of 33
Identifier Description
A.TRAINED_USER Users follow the provided guidance for securing the TOE and
authorization factors. This includes conformance with authorization
factor strength, using external token authentication factors for no other
purpose and ensuring external token authorization factors are securely
stored separately from the storage device and/or platform. The user
should also be trained on how to power off their system.
A.PLATFORM_STATE The platform in which the storage device resides (or an external
storage device is connected) is free of malware that could interfere
with the correct operation of the product.
A.POWER_DOWN The user does not leave the platform and/or storage device
unattended until the device is in a Compliant power saving state or has
fully powered off. This properly clears memories and locks down the
device. Authorized users do not leave the platform and/or storage
device in a mode where sensitive information persists in non-volatile
storage (e.g., lock screen or sleep state). Users power the platform
and/or storage device down or place it into a power managed state,
such as a “hibernation mode”.
A.STRONG_CRYPTO All cryptography implemented in the Operational Environment and
used by the product meets the requirements listed in the cPP. This
includes generation of external token authorization factors by a RBG.
A.PHYSICAL The platform is assumed to be physically protected in its Operational
Environment and not subject to physical attacks that compromise the
security and/or interfere with the platform’s correct operation.
3.3 Organizational Security Policies
14 None defined.
DIGISTOR Security Target
Page 16 of 33
4 Security Objectives
15 The security objectives are reproduced from the CPP_FDE_EE.
Table 8: Security Objectives for the Operational Environment
Identifier Description
OE.TRUSTED_
CHANNEL
Communication among and between product components (i.e., AA
and EE) is sufficiently protected to prevent information disclosure.
OE.INITIAL_DRIVE_
STATE
The OE provides a newly provisioned or initialized storage device free
of protected data in areas not targeted for encryption.
OE.PASSPHRASE_
STRENGTH
An authorized administrator will be responsible for ensuring that the
passphrase authorization factor conforms to guidance from the
Enterprise using the TOE.
OE.POWER_DOWN Volatile memory is cleared after entering a Compliant power saving
state or turned off so memory remnant attacks are infeasible.
OE.SINGLE_USE_ET External tokens that contain authorization factors will be used for no
other purpose than to store the external token authorization factor.
OE.STRONG_
ENVIRONMENT_
CRYPTO
The Operating Environment will provide a cryptographic function
capability that is commensurate with the requirements and capabilities
of the TOE and Appendix A.
OE.TRAINED_USERS Authorized users will be properly trained and follow all guidance for
securing the TOE and authorization factors.
OE.PHYSICAL The Operational Environment will provide a secure physical computing
space such than an adversary is not able to make modifications to the
environment or to the TOE itself.
DIGISTOR Security Target
Page 17 of 33
5 Security Requirements
5.1 Conventions
16 This document uses the following font conventions to identify the operations defined
by the CC:
a) Assignment. Indicated with italicized text.
b) Refinement. Indicated with bold text and strikethroughs.
c) Selection. Indicated with underlined text.
d) Assignment within a Selection: Indicated with italicized and underlined text.
e) Iteration. Indicated by appending parentheses that contain a letter that is
unique for each iteration, e.g. (a), (b), (c) and/or with a slash (/) followed by a
descriptive string for the SFR’s purpose, e.g. /Server.
17 Note: Operations performed within the Security Target are denoted within brackets
[]. Operations shown without brackets are reproduced from the PP.
5.2 Extended Components Definition
18 The following Extended Components are defined in Appendix C.2 of the
CPP_FDE_EE:
Table 9: Extended Components
Requirement Title
FCS_CKM_EXT.4(a) Cryptographic Key and Key Material Destruction (Destruction Timing)
FCS_CKM_EXT.4(b) Cryptographic Key and Key Material Destruction (Power Management)
FCS_CKM_EXT.6 Cryptographic Key Destruction Types
FCS_KYC_EXT.2 Key Chaining (Recipient)
FCS_SNI_EXT.1 Cryptographic Operation (Salt, Nonce, and Initialization Vector Generation)
FCS_VAL_EXT.1 Validation
FDP_DSK_EXT.1 Protection of Data on Disk
FPT_KYP_EXT.1 Protection of Key and Key Material
FPT_PWR_EXT.1 Power Saving States
FPT_PWR_EXT.2 Timing of Power Saving States
FPT_TST_EXT.1 TSF Testing
FPT_TUD_EXT.1 Trusted Update
DIGISTOR Security Target
Page 18 of 33
Requirement Title
Selection based
FCS_KDF_EXT.1 Cryptographic Key Derivation
FCS_RBG_EXT.1 Random Bit Generation
FPT_FUA_EXT.1 Firmware Update Authentication
5.3 Functional Requirements
Table 10: Summary of SFRs
Requirement Title
FCS_CKM.1(c) Cryptographic Key Generation (Data Encryption Key)
FCS_CKM.4(a) Cryptographic Key Destruction (Power Management)
FCS_CKM_EXT.4(a) Cryptographic Key and Key Material Destruction (Destruction Timing)
FCS_CKM_EXT.4(b) Cryptographic Key and Key Material Destruction (Power Management)
FCS_CKM_EXT.6 Cryptographic Key Destruction Types
FCS_KYC_EXT.2 Key Chaining (Recipient)
FCS_SNI_EXT.1 Cryptographic Operation (Salt, Nonce, and Initialization Vector Generation)
FCS_VAL_EXT.1 Validation
FDP_DSK_EXT.1 Protection of Data on Disk
FMT_SMF.1 Specification of Management Functions
FPT_KYP_EXT.1 Protection of Key and Key Material
FPT_PWR_EXT.1 Power Saving States
FPT_PWR_EXT.2 Timing of Power Saving States
FPT_TST_EXT.1 TSF Testing
FPT_TUD_EXT.1 Trusted Update
Selection based
FCS_CKM.1(b) Cryptographic Key Generation (Symmetric Keys)
FCS_CKM.4(b) Cryptographic Key Destruction (TOE-Controlled Hardware)
DIGISTOR Security Target
Page 19 of 33
Requirement Title
FCS_COP.1(a) Cryptographic Operation (Signature Verification)
FCS_COP.1(b) Cryptographic Operation (Hash Algorithm)
FCS_COP.1(c) Cryptographic Operation (Message Authentication)
FCS_COP.1(d) Cryptographic Operation (Key Wrapping)
FCS_COP.1(f) Cryptographic Operation (AES Data Encryption/Decryption)
FCS_KDF_EXT.1 Cryptographic Key Derivation
FCS_RBG_EXT.1 Random Bit Generation
FPT_FUA_EXT.1 Firmware Update Authentication
5.3.1 Cryptographic Support (FCS)
FCS_CKM.1(b) Cryptographic Key Generation (Symmetric Keys)
FCS_CKM.1.1(b) Refinement: The TSF shall generate symmetric cryptographic keys
using a Random Bit Generator as specified in FCS_RBG_EXT.1 and
specified cryptographic key sizes [256 bit] that meet the following: [no
standard].
FCS_CKM.1(c) Cryptographic Key Generation (Data Encryption Key)
FCS_CKM.1.1(c) Refinement: The TSF shall generate cryptographic keys in accordance
with a specified cryptographic key generation algorithm method [
• generate a DEK using the RBG as specified in FCS_RBG_EXT.1,]
and specified cryptographic key sizes [256 bits] that meet the following:
[assignment: list of standards].
FCS_CKM.4(a) Cryptographic Key Destruction (Power Management)
FCS_CKM.4.1(a) Refinement: The TSF shall [erase] cryptographic keys and key
material from volatile memory when transitioning to a Compliant
power saving state as defined by FPT_PWR_EXT.1 that meets the
following: [a key destruction method specified in FCS_CKM_EXT.6].
DIGISTOR Security Target
Page 20 of 33
FCS_CKM.4(b) Cryptographic Key Destruction (TOE-Controlled Hardware)
FCS_CKM.4.1(b) Refinement: The TSF shall destroy cryptographic keys in accordance
with a specified cryptographic key destruction method [
• For volatile memory, the destruction shall be executed by a [
o single overwrite consisting of [
▪ zeroes],
o removal of power to the memory];
• For non-volatile memory [
o that employs a wear-leveling algorithm, the destruction
shall be executed by a [
▪ single overwrite consisting of zeroes,
▪ overwrite with a new value of a key of the same
size,
▪ block erase];
and if the read-verification of the overwritten data fails, the process
shall be repeated again up to [zero] times, whereupon an error is
returned.]
] that meets the following: [no standard].
FCS_CKM_EXT.4(a) Cryptographic Key and Key Material Destruction (Destruction
Timing)
FCS_CKM_EXT.4.1(a) The TSF shall destroy all keys and key material when no longer needed.
FCS_CKM_EXT.4(b) Cryptographic Key and Key Material Destruction (Power
Management)
FCS_CKM_EXT.4.1(b) The TSF shall destroy all key material, BEV, and authentication factors
stored in plaintext when transitioning to a Compliant power saving state
as defined by FPT_PWR_EXT.1.
FCS_CKM_EXT.6 Cryptographic Key Destruction Types
FCS_CKM_EXT.6.1 The TSF shall use [FCS_CKM.4(b)] key destruction methods.
DIGISTOR Security Target
Page 21 of 33
FCS_COP.1(a) Cryptographic Operation (Signature Verification)
FCS_COP.1.1(a) Refinement: The TSF shall perform [cryptographic signature services
(verification)] in accordance with a [
• RSA Digital Signature Algorithm with a key size (modulus) of
[2048-bit];
]
that meet the following: [
• FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section
5.5, using PKCS #1 v2.1 Signature Schemes RSASSA-PSS
and/or RSASSA-PKCS1-v1_5; ISO/IEC 29 9796-2, Digital
signature scheme 2 or Digital Signature scheme 3, for RSA
schemes]
FCS_COP.1(b) Cryptographic Operation (Hash Algorithm)
FCS_COP.1.1(b) Refinement: The TSF shall perform [cryptographic hashing services] in
accordance with a specified cryptographic algorithm [SHA-256] and
cryptographic key sizes [assignment: cryptographic key sizes] that meet
the following [ISO/IEC 10118-3:2004].
FCS_COP.1(c) Cryptographic Operation (Message Authentication)
FCS_COP.1.1(c) Refinement: The TSF shall perform cryptographic [message
authentication] in accordance with a specified cryptographic algorithm
[HMAC-SHA-256] and cryptographic key sizes [256 bits [HMAC]] that
meet the following: [ISO/IEC 9797-2:2011, Section 7 “MAC Algorithm 2”].
FCS_COP.1(d) Cryptographic Operation (Key Wrapping)
FCS_COP.1.1(d) Refinement: The TSF shall perform [key wrapping] in accordance with a
specified cryptographic algorithm [AES] in the following modes [KW]
and the cryptographic key size [256 bits] that meet the following: [AES
as specified in ISO/IEC 18033-3, [NIST SP 800-38F]].
FCS_COP.1(f) Cryptographic Operation (AES Data Encryption/Decryption)
FCS_COP.1.1(f) Refinement: The TSF shall perform [data encryption and decryption] in
accordance with a specified cryptographic algorithm [AES used in [XTS]
mode] and cryptographic key sizes [256 bits] that meet the following:
[AES as specified in ISO/IEC 18033-3, [XTS as specified in IEEE
1619]].
DIGISTOR Security Target
Page 22 of 33
FCS_KDF_EXT.1 Cryptographic Key Derivation
FCS_KDF_EXT.1.1 The TSF shall accept [a conditioned password submask] to derive an
intermediate key, as defined in [
• NIST SP 800-132],
using the keyed-hash functions specified in FCS_COP.1(c), such that the
output is at least of equivalent security strength (in number of bits) to the
BEV.
FCS_KYC_EXT.2 Key Chaining (Recipient)
FCS_KYC_EXT.2.1 The TSF shall accept a BEV of at least [256 bits] from [the AA].
FCS_KYC_EXT.2.2 The TSF shall maintain a chain of intermediary keys originating from the
BEV to the DEK using the following method(s): [
• symmetric key generation as specified in FCS_CKM.1(b),
• key derivation as specified in FCS_KDF_EXT.1,
• key wrapping as specified in FCS_COP.1(d)]
while maintaining an effective strength of [256 bits] for symmetric keys
and an effective strength of [not applicable] for asymmetric keys.
FCS_RBG_EXT.1 Cryptographic Operation (Random Bit Generation)
FCS_RBG_EXT.1.1 The TSF shall perform all deterministic random bit generation services in
accordance with [[NIST SP 800-90A]] using [HMAC_DRBG (any)].
FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by at least one entropy source
that accumulates entropy from [
• [1] hardware-based noise source(s),]
with a minimum of [256 bits] of entropy at least equal to the greatest
security strength, according to ISO/IEC 18031:2011 Table C.1 “Security
Strength Table for Hash Functions”, of the keys and hashes that it will
generate.
FCS_SNI_EXT.1 Cryptographic Operation (Salt, Nonce, and Initialization
Vector Generation)
FCS_SNI_EXT.1.1 The TSF shall [use salts that are generated by a [DRBG as specified in
FCS_RBG_EXT.1]].
FCS_SNI_EXT.1.2 The TSF shall use [unique nonces with a minimum size of [64] bits].
FCS_SNI_EXT.1.3 The TSF shall create IVs in the following manner [
• XTS: No IV. Tweak values shall be non-negative integers, assigned
consecutively and starting at an arbitrary non-negative integer].
DIGISTOR Security Target
Page 23 of 33
FCS_VAL_EXT.1 Validation
FCS_VAL_EXT.1.1 The TSF shall perform validation of the [BEV] using the following
method(s): [
• Key wrap as specified in FCS_COP.1(d)]
FCS_VAL_EXT.1.2 The TSF shall require validation of the [BEV] prior to [allowing access to
TSF data after exiting a Compliant power saving state].
FCS_VAL_EXT.1.3 The TSF shall [
• require power cycle/reset the TOE after [an administrator
configurable number between 1 and 20] of consecutive failed
validation attempts].
5.3.2 User Data Protection (FDP)
FDP_DSK_EXT.1 Protection of Data on Disk
FDP_DSK_EXT.1.1 The TSF shall perform Full Drive Encryption in accordance with
FCS_COP.1(f), such that the drive contains no plaintext protected data.
FDP_DSK_EXT.1.2 The TSF shall encrypt all protected data without user intervention.
5.3.3 Security Management (FMT)
FMT_SMF.1 Specification of Management Functions
FMT_SMF.1.1 Refinement: The TSF shall be capable of performing the following
management functions: [
a) change the DEK, as specified in FCS_CKM.1, when re-provisioning
or when commanded,
b) erase the DEK, as specified in FCS_CKM.4(a),
c) initiate TOE firmware/software updates,
d) [no other functions]].
5.3.4 Protection of the TSF (FPT)
FPT_FUA_EXT.1 Firmware Update Authentication
FPT_FUA_EXT.1.1 The TSF shall authenticate the source of the firmware update using the
digital signature algorithm specified in FCS_COP.1(a) using the RTU that
contains [hash value of the public key as specified in FCS_COP.1(b)].
FPT_FUA_EXT.1.2 The TSF shall only allow installation of update if the digital signature has
been successfully verified as specified in FCS_COP.1(a).
FPT_FUA_EXT.1.3 The TSF shall only allow modification of the existing firmware after the
successful validation of the digital signature, using a mechanism as
described in FPT_TUD_EXT.1.2.
DIGISTOR Security Target
Page 24 of 33
FPT_FUA_EXT.1.4 The TSF shall return an error code if any part of the firmware update
process fails.
FPT_KYP_EXT.1 Protection of Key and Key Material
FPT_KYP_EXT.1.1 The TSF shall [
• only store keys in non-volatile memory when wrapped, as specified
in FCS_COP.1(d), or encrypted, as specified in FCS_COP.1(g) or
FCS_COP.1(e)].
FPT_PWR_EXT.1 Power Saving States
FPT_PWR_EXT.1.1 The TSF shall define the following Compliant power saving states: [D3].
FPT_PWR_EXT.2 Timing of Power Saving States
FPT_PWR_EXT.2.1 For each Compliant power saving state defined in FPT_PWR_EXT.1.1,
the TSF shall enter the Compliant power saving state when the following
conditions occur: user-initiated request, [no other conditions].
FPT_TST_EXT.1 TSF Testing
FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests [during initial start-up
(on power on)] to demonstrate the correct operation of the TSF: [
• Firmware integrity
• DRBG health
• Known Answer Tests (KATs):
o AES XTS encrypt/decrypt
o AES key wrap/unwrap
o DRBG
o SHA-2
o HMAC
o PBKDF2
]
DIGISTOR Security Target
Page 25 of 33
FPT_TUD_EXT.1 Trusted Update
FPT_TUD_EXT.1.1 Refinement: The TSF shall provide [authorized users] the ability to
query the current version of the TOE [firmware] software/firmware.
FPT_TUD_EXT.1.2 Refinement: The TSF shall provide [authorized users] the ability to
initiate updates to TOE [firmware] software/firmware.
FPT_TUD_EXT.1.3 Refinement: The TSF shall verify updates to the TOE [firmware] using
a [authenticated firmware update mechanism as described in
FPT_FUA_EXT.1] by the manufacturer prior to installing those updates.
DIGISTOR Security Target
Page 26 of 33
5.4 Assurance Requirements
19 The TOE security assurance requirements are summarized in Table 11.
Table 11: Assurance Requirements
Assurance Class Components Description
Security Target
Evaluation
ASE_CCL.1 Conformance Claims
ASE_ECD.1 Extended Components Definition
ASE_INT.1 ST Introduction
ASE_OBJ.1 Security Objectives for the operational environment
ASE_REQ.1 Stated Security Requirements
ASE_SPD.1 Security Problem Definition
ASE_TSS.1 TOE Summary Specification
Development ADV_FSP.1 Basic Functional Specification
Guidance Documents AGD_OPE.1 Operational User Guidance
AGD_PRE.1 Preparative Procedures
Life Cycle Support ALC_CMC.1 Labelling of the TOE
ALC_CMS.1 TOE CM Coverage
Tests ATE_IND.1 Independent Testing - sample
Vulnerability Assessment AVA_VAN.1 Vulnerability Survey
20 In accordance with section 6.1 of the CPP_FDE_EE, the following refinement is
made to ASE:
a) ASE_TSS.1.1C Refinement: The TOE summary specification shall describe
how the TOE meets each SFR, including a proprietary Key Management
Description (Appendix E), and [Entropy Essay].
DIGISTOR Security Target
Page 27 of 33
6 TOE Summary Specification
21 The following sections describe how the TOE fulfils each SFR included in section
5.3.
6.1 Cryptographic Support (FCS)
6.1.1 FCS_CKM.1(c) Cryptographic Key Generation (Data Encryption
Key)
22 The TOE generates the Data Encryption Key (DEK) using the Change DEK option in
the GUI. The process invokes the internal HMAC_DRBG when generating the DEK.
6.1.2 FCS_CKM.1(b) Cryptographic Key Generation (Symmetric Keys)
23 The TOE generates a 256-bit AES DEK which is protected by the Key Encryption
Key (KEK) using the key wrap function.
6.1.3 FCS_CKM.4(a) Cryptographic Key Destruction (Power
Management)
24 The TOE erases cryptographic keys and key material from volatile memory when
transitioning to a Compliant power saving state. All keys in the chain (DEK, KEK,
and BEV) are erased from volatile memory by performing a single overwrite
consisting of zeroes.
25 For non-volatile memory, the DEK is erased in two stages. First, the old key is
overwritten with the new key value and then stored in a new location in memory. The
old block location (where the original key was stored) is erased using a wear-leveling
program. User KEKs are erased from non-volatile memory by performing a single
overwrite consisting of zeroes. The BEV is not stored in non-volatile memory.
26 Additional information on key usage, storage, and destruction can be found in Table
12 below.
DIGISTOR Security Target
Page 28 of 33
6.1.4 FCS_CKM.4(b) Cryptographic Key Destruction (TOE-Controlled
Hardware)
27 The following table describes the how cryptographic keys are used, stored and
destroyed.
Table 12: Cryptographic Key Usage, Storage, and Destruction
Key Key Type/Length Initialization Usage Storage Destruction Destruction Timing
DEK XTS-AES-256 TOE
configuration
Data
encryption/
decryption
Encrypted by KEK
and stored in
NAND.
Plaintext keys
stored in DRAM
and registers.
Replaced by
new key
followed by a
Block erase.
Zeroization
All keys are
destroyed when the
following occurs:
• When a user
password
change occurs
• After the user
session ends
• After a power off
• When the TOE is
uninstalled
• When the
Change DEK
option is
executed via the
GUI
KEK AES Key Wrap 256 TOE
configuration
Protected,
wrapped
DEK
Encrypted by user
password-based
key with AES key
wrap and stored
in NAND.
Plaintext keys
stored in DRAM
and registers.
Zeroization
BEV PBKDF Output of
PBKDF
Unwrap of
KEK
Plaintext keys
stored in DRAM
and registers.
Zeroization
28 Note: The TOE includes both volatile memory (DRAM) and non-volatile memory
(NAND). In both cases, the memory is accessed using standard microcontroller
memory interface controllers and addressing schemes. The DRAM is bit-level
addressable, and NAND flash is block-level readable and writable. The TOE does
not persistently store plaintext keys. Only protected keys and copies are persistently
stored in NAND with parity bits. All protected keys used for the microcontroller are
stored in a single block of NAND that is inaccessible to the host.
6.1.5 FCS_CKM_EXT.4(a) Cryptographic Key and Key Material
Destruction (Destruction Timing)
29 Details regarding the timing of key and key material destruction can be found in
Table 12.
6.1.6 FCS_CKM_EXT.4(b) Cryptographic Key and Key Material
Destruction (Power Management)
30 Details regarding key destruction when entering a Compliant power saving state are
provided in sections 6.1.3 and 6.1.4 above.
6.1.7 FCS_CKM_EXT.6 Cryptographic Key Destruction Types
31 All keys are destroyed as per the methods described in FCS_CKM.4(b). The TOE’s
key chain is described in the KMD.
DIGISTOR Security Target
Page 29 of 33
6.1.8 FCS_COP.1(a) and FCS_COP.1(b) Cryptographic Operation
(Signature Verification and Hash Algorithm)
32 All firmware binaries are signed by Phison. Phison is the primary developer of the
TOE firmware and is the only authorized source for code signing. Phison assigns a
dedicated code signing key for each customer. Code signing key “A” is used for
Digistor firmware and code signing key “B” is used for Cigent firmware. Regardless
of the key used for signing, the security related features and algorithms are identical
as claimed in the evaluated configuration.
33 As per Table 5 above, only the Digistor C series drives supporting FW version
ECPM13.1 are signed with “B” (Cigent). All other drives and FW versions are signed
with “A” (Digistor).
34 The TOE performs signature verification using RSA 2048 with SHA-256 for trusted
updates as follows:
a) TOE updates are signed with the code signing private key.
b) The obfuscated public key is embedded in the TOE binary.
c) When the user triggers the TOE update, the TOE compares a hash of the
public key with the stored hash of the public key, and then verifies the digital
signature.
d) If the digital signature verification succeeds, the upgrade process is carried
out.
e) If the digital signature verification fails, the upgrade process is aborted, and an
error is displayed to the user.
6.1.9 FCS_COP.1(c) Cryptographic Operation (Keyed Hash Algorithm)
35 The TOE implements HMAC-SHA-256 with the following characteristics:
a) Key length. 256 bits.
b) Block size. 512 bits.
c) MAC length. 256 bits.
6.1.10 FCS_COP.1(d) Cryptographic Operation (Key Wrapping)
36 The TOE key wrap function is used to protect the DEK using AES-256.
6.1.11 FCS_COP.1(f) Cryptographic Operation (AES Data
Encryption/Decryption)
37 The TOE performs data encryption/decryption using AES-XTS with 256-bit keys.
6.1.12 FCS_KDF_EXT.1 Cryptographic Key Derivation
38 Passwords are conditioned via PBKDF2 using HMAC-SHA-256 with 1,000 iterations,
resulting in a 256-bit key in accordance with NIST SP 800-132.
6.1.13 FCS_KYC_EXT.2 Key Chaining (Recipient)
39 The TOE key chain is described in the KMD.
DIGISTOR Security Target
Page 30 of 33
6.1.14 FCS_RBG_EXT.1 Cryptographic Operation (Random Bit
Generation)
40 The TOE uses a hardware-based deterministic random bit generator (DRBG) that
complies with NIST SP 800-90A for all cryptographic operations. The DRBG is
seeded with at least 256-bits of entropy from thermal noise generated by the
complementary metal-oxide semiconductor (CMOS).
6.1.15 FCS_SNI_EXT.1 Cryptographic Operation (Salt, Nonce, and
Initialization Vector Generation)
41 The TOE generates 32 byte salts using RAND_bytes at the time of encryption which
are then stored in a database for use during decryption. Salts are generated using
the DRBG as described in FCS_RBG_EXT.1.
42 Unique 16 byte nonces are generated using the hardware Random Number
Generator (RNG) and are appended to the encrypted data.
43 The Logical Block Address (LBA) of the SSD is used as the tweak value. Tweak
values are non-negative integers, assigned consecutively, and start at an arbitrary
non-negative integer. The tweak value is converted to a little‐endian byte array,
where encryption of the tweak is done using AES-XTS.
6.1.16 FCS_VAL_EXT.1 Validation
44 The TOE will validate a BEV using key wrap as specified in FCS_COP.1(d). As per
the application note in the CPP_FDE_PP, when the key wrap in FCS_COP.1(d) is
used, the validation is performed inherently.
45 Successful validation of the BEV per above is required prior to allowing decryption of
the drive and granting access to any TSF data after exiting a compliant power saving
state.
46 After a configurable number of failed authentication attempts is reached, the system
will stop responding until it is rebooted at which point the counter is reset. An
administrator can set this threshold to a value between 1 and 20 failed attempts.
6.2 User Data Protection (FDP)
6.2.1 FDP_DSK_EXT.1 Protection of Data on Disk
47 The first 128MB of media data on the drive (Shadow MBR data) and the disk
partition tables are read only and not encrypted. Once provisioned, all other data
written to disk is encrypted without user intervention using AES-XTS. Data being
written to disk is encrypted before being programmed to NAND storage.
48 The following initialization activities ensure the encryption function works when first
provisioning the drive:
1. Examine the tamper evidence and check the module has not been
tampered.
2. StartSession SID of AdminSP with MSID password, and then set new
password for SID password. The new password shall be at least 20 bytes.
3. Disable AdminSP “Makers” Authority.
4. Execute TCG activate command to have the module enter TCG active
mode.
DIGISTOR Security Target
Page 31 of 33
5. StartSession Admin1 of LockingSP with new password of SID in Step2,
and then set new password for Admin1-4 passwords and User1-9
passwords of LockingSP. The new passwords shall be at least 20 bytes.
6. Configure all LockingRanges of LockinSP by setting ReadLockEnabled
and WriteLockEnabled columns to TRUE.
7. Power cycle the module.
8. Check if the module is in the FIPS approved mode by using the Identify
command response data byte 506 bit1 (SATA) or the Identify controller
command response data byte 4093 bit1 (NVMe). The bit1 shall be set to 1.
9. Check the module’s firmware version using the Identify command response
data dword 23-26 (SATA) or the Identify controller command response
data byte 64-71 (NVME).
49 Once provisioned, the following boot initialization process is performed each time the
TOE transitions from a power saving state:
1. CTL ROM code conducts KAT of SHA-256bit/RSA 2048 bit as listed in
FPT_TST_EXT.1, Table 13.
2. FW code is loaded from NAND.
3. CTL ROM code conducts firmware integrity check of the FW binary via
RSA 2048 SHA256 PSS Signature Verification.
4. FW code is executed (only if integrity check is successful).
5. FW code conducts all firmware power-on self-test as listed in
FPT_TST_EXT.1, Table 13.
6. When all self-tests have passed, the module enters a ready state awaiting
host/use commands.
6.3 Security Management (FMT)
6.3.1 FMT_SMF.1 Specification of Management Functions
50 The DEK can only be changed by generating a new one. DEKs are generated by
using the Change DEK option via the GUI. DEKs are erased as per FCS_CKM.4(a)
described in section 6.1.3 above.
51 Users of the TOE must contact the vendor to obtain firmware updates. Firmware
updates are manually installed by authorized administrators.
6.4 Protection of the TSF (FPT)
6.4.1 FPT_FUA_EXT.1 Firmware Update Authentication
52 Firmware running on the TOE exists in ROM. The RTU uses a SHA-256 hash of the
public key, as specified in FCS_COP.1(b), to authenticate the source of firmware
updates. The public key hash is stored in one-time programmable (OTP) memory.
The ROM code loads the firmware update and checks the hash of the public key
embedded in the firmware binary. ROM code is hardcoded in the controller hardware
and cannot be modified post-production.
6.4.2 FPT_KYP_EXT.1 Protection of Key and Key Material
53 Keys stored in non-volatile memory are wrapped, as specified in FCS_COP.1(d).
DIGISTOR Security Target
Page 32 of 33
6.4.3 FPT_PWR_EXT.1 Power Saving States
54 The TOE supports the following Compliant power saving states:
a) D3. Powered Off – user initiated, dependent on the OS parameters.
6.4.4 FPT_PWR_EXT.2 Timing of Power Saving States
55 The TOE enters a Compliant power saving state as prompted by the protected OS
and user-initiated requests as described in Section 6.4.3 above.
6.4.5 FPT_TST_EXT.1 TSF Testing
56 The following self-tests are performed by the TOE:
Table 13: TSF Self-Tests
Self Test Description
Rom Code SHA 256 bit KAT
Rom Code RSA 2048 bit KAT
Boot Loader Integrity Firmware integrity test
Firmware AES XTS 256 bit Encrypt KAT
Firmware AES XTS 256 bit Decrypt KAT
Firmware SHA 256 bit KAT
Firmware HMAC SHA 256 KAT
Firmware AES Key Wrap KAT
Firmware AES Key Unwrap KAT
Firmware DRBG KAT
Firmware DRBG Health Tests SP 800-90A Section 11.3 Health Tests
Firmware SP 800-132 PBKDF2 KAT
DRBG Continuous RNG test for DRBG
NDRNG Continuous RNG test for NDRNG
6.4.6 FPT_TUD_EXT.1 Trusted Update
57 Update files are digitally signed (RSA per FCS_COP.1(a)) by Phison and verified
prior to installation. Additional process details are described in Section 6.1.8 above.
DIGISTOR Security Target
Page 33 of 33
7 Rationale
7.1 Conformance Claim Rationale
58 The following rationale is presented with regard to the PP conformance claims:
a) TOE type. As identified in section 2.1, the TOE is consistent with the
CPP_FDE_EE.
b) Security problem definition. As shown in section 3, the threats, OSPs and
assumptions are reproduced directly from the CPP_FDE_EE.
c) Security objectives. As shown in section 0, the security objectives are
reproduced directly from the CPP_FDE_EE.
d) Security requirements. As shown in section 5, the security requirements are
reproduced directly from the CPP_FDE_EE. No additional requirements have
been specified.
7.2 Security Objectives Rationale
59 All security objectives are drawn directly from the CPP_FDE_EE.
7.3 Security Requirements Rationale
60 All security requirements are drawn directly from the CPP_FDE_EE. No optional
SFRs are included in the ST. The following selection based SFRs have been
included:
a) FCS_CKM.1(b)
b) FCS_CKM.4(b)
c) FCS_COP.1(a)
d) FCS_COP.1(b)
e) FCS_COP.1(c)
f) FCS_COP.1(d)
g) FCS_COP.1(f)
h) FCS_KDF_EXT.1
i) FCS_RBG_EXT.1
j) FPT_FUA_EXT.1