Security Target: CP_2014-RT-587-ST

Security Target: CP_2014-RT-587-ST
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
Security Target Lite of W75F32W 32M-bit
Secure Serial Flash Memory
Emission Date
Document Type
Version
Classification
Number of pages
:
:
:
:
:
30-July-2015
Technical report
1.2
PUBLIC
45 (including 2 header pages)
PUBLIC
Page 1/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
Table of contents
1.1
1.2
1.3
SECURITY TARGET REFERENCE............................................................................................. 5
TOE REFERENCE .............................................................................................................. 5
TOE OVERVIEW............................................................................................................... 5
1.4
TOE DESCRIPTION ........................................................................................................... 6
1.5
1.6
2.1
2.2
2.3
3.1
TOE OPERATING MODES .................................................................................................... 8
TOE LIFE CYCLE .............................................................................................................. 9
CC CONFORMANCE CLAIM .................................................................................................10
PP CLAIM ......................................................................................................................10
PACKAGE CLAIM ..............................................................................................................10
ASSETS .........................................................................................................................11
3.2
3.3
3.4
3.5
4.1
4.2
4.3
USERS / SUBJECTS...........................................................................................................11
THREATS .......................................................................................................................12
ORGANISATIONAL SECURITY POLICIES ..................................................................................13
ASSUMPTIONS ................................................................................................................13
SECURITY OBJECTIVES FOR THE TOE ...................................................................................14
SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ....................................................15
SECURITY OBJECTIVES RATIONALE.......................................................................................16
5.1
EXTENDED FAMILIES ........................................................................................................19
6.1
SECURITY FUNCTIONAL REQUIREMENTS ................................................................................23
6.2
SECURITY ASSURANCE REQUIREMENTS..................................................................................28
6.3
SECURITY REQUIREMENTS RATIONALE ..................................................................................29
7.1
7.2
TOE SUMMARY SPECIFICATION ...........................................................................................36
SFRS AND TSS...............................................................................................................39
8.1
9.1
9.2
9.3
REVISIONS ....................................................................................................................41
GLOSSARY .....................................................................................................................42
ABBREVIATIONS ..............................................................................................................42
REFERENCES ..................................................................................................................44
1.3.1
1.3.2
1.3.3
TOE Type .............................................................................................................. 5
TOE Intended Usage .............................................................................................. 6
Non-TOE Hardware/Software/Firmware ................................................................... 6
1.4.1
1.4.2
Physical Scope ....................................................................................................... 6
Logical Scope ......................................................................................................... 8
3.1.1
3.1.2
TSF data...............................................................................................................11
User data .............................................................................................................11
4.3.1
4.3.2
4.3.3
Threats ................................................................................................................16
Assumptions .........................................................................................................17
SPD and Security Objectives ..................................................................................17
5.1.1
5.1.2
Extended Family FMT_LIM - Limited capabilities and availability ...............................19
Extended Family FDP_SDC - Stored data confidentiality ...........................................21
6.1.1
6.1.2
6.1.3
6.1.4
6.1.5
6.1.6
Malfunctions .........................................................................................................23
Abuse of Functionality ...........................................................................................23
Physical Manipulation and Probing..........................................................................24
Leakage ...............................................................................................................25
Secure Data Exchange ...........................................................................................26
Protection of Binding Key.......................................................................................27
6.2.1
Refinements of the TOE Assurance Requirements ...................................................28
6.3.1
6.3.2
6.3.3
6.3.4
6.3.5
6.3.6
Objectives ............................................................................................................29
Rationale tables of Security Objectives and SFRs .....................................................31
Dependencies .......................................................................................................33
Rationale for the Security Assurance Requirements .................................................35
ALC_DVS.2 Sufficiency of security measures ...........................................................35
AVA_VAN.5 Advanced methodical vulnerability analysis ...........................................35
7.2.1
7.2.2
SFRs and TSS - Rationale ......................................................................................39
Association tables of SFRs and TSS ........................................................................39
PUBLIC
Page 2/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
Table of figures
Figure 1 TOE Architecture .............................................................................................................. 7
PUBLIC
Page 3/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
Table of tables
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
1 TOE Identification ............................................................................................................ 5
2 Operating modes .............................................................................................................. 8
3 TOE life-cycle ................................................................................................................... 9
4 Threats and Security Objectives - Coverage ......................................................................17
5 Security Objectives and Threats - Coverage ......................................................................17
6 Assumptions and Security Objectives for the Operational Environment - Coverage ..............18
7 Security Objectives for the Operational Environment and Assumptions - Coverage ..............18
8 Security Objectives and SFRs - Coverage ..........................................................................31
9 SFRs and Security Objectives ...........................................................................................32
10 SFRs Dependencies .......................................................................................................33
11 SARs Dependencies .......................................................................................................34
12 SFRs and TSS - Coverage ...............................................................................................40
13 TSS and SFRs - Coverage ...............................................................................................40
14 History of Modifications ..................................................................................................41
PUBLIC
Page 4/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
1 Security Target Introduction
This introductory chapter contains the following sections:

Security Target Reference

TOE Reference

TOE Overview

TOE Description

TOE operating modes and life-cycle
This Security Target is based on the Security IC Platform Protection Profile with
Augmentation Packages [5]. However, the Security Target does not include the Random
Generation and the IC Identification security objectives. The corresponding assumptions of
the Protection Profile are not used and replaced by other assumptions.
On the other hand, the Security Target includes additional elements which are not required
by the Protection Profile [5]. Those security elements (threats, security objectives, SFR) are
clearly identified in each Chapter of this document.
1.1 Security Target Reference
Title: Lite Security Target of W75F32W 32M-bit Secure Serial Flash Memory
Version: 1.2
Authors: Trusted Labs SAS and Winbond Technology Ltd.
Evaluator: Applus
Certified by: CCN Organismo de Certificacion
1.2 TOE Reference
The Target of Evaluation is identified as below:
Commercial Name
Product Name
Version
Reference Design
Guidance
Secure Serial Flash Memory
W75F32W
1.0
G1

Operational User Guidance [15]

Preparative Procedure [16]
Table 1 TOE Identification
1.3 TOE Overview
1.3.1 TOE Type
The Target of Evaluation is a Memory Flash IC.
PUBLIC
Page 5/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
1.3.2 TOE Intended Usage
The TOE is dedicated to be embedded into highly critical hardware devices such as smart
card, secure element, USB token, secure micro SD, etc. These devices will embed secure
applications such as financial, telecommunication, identity (e-Government), etc and will be
working in a hostile environment. In particular, the TOE is dedicated to the secure storage of
the code and data of critical applications.
The security needs for the TOE consist in:
-
-
Maintaining the integrity of the content of the memories and the confidentiality of
the content of protected memory areas as required by the critical HW products
(e.g. Security IC) the Memory Flash is built for;
Providing a secure communication with the Host device that will embed the TOE
in a secure HW product such as Security IC;
1.3.3 Non-TOE Hardware/Software/Firmware
For the present ST, the TOE is a pure storage hardware device.
The TOE does not comprise:
a) The Host device that will embed the TOE and will be needed to run the TOE in
order to stimulate the TSF
b) SPI Bus for the communication between the Host device and the TOE
The ST assumes that all components (Hardware or Software) of the Host Device are
appropriately protected in the TOE security environment.
1.4 TOE Description
1.4.1 Physical Scope
The TOE comprises:
-
All security functionality necessary to ensure the secure execution of the Memory
Flash,
The guidance for the secure usage of the TOE: Operational User Guidance [15]
and Preparative Procedure [16].
1.4.1.1 TOE Physical Characteristics
The TOE physical characteristics are described as follows.
 Capacity: 32M-bit / 4M-byte
 Performance
o 50MHz Standard/Quad/Octal SPI clocks
o 28MB/S continuous encrypted and authenticated data transfer rate
o More than 100,000 erase/program cycles
o More than 20-year data retention
PUBLIC
Page 6/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
 Efficiency
o 16-byte burst read
o Data Integrity Check
o Allows secure execution in place (S-XIP) operation
 Operating conditions
o Single 1.65 to 1.95V supply
o 2mA active current, <1μA Power-down (typ.)
o -40°C to +85°C operating range
 4KB-block Architecture
o Uniform Block Erase (4K-bytes)
o Program 1 to 16 byte in a single command
o Erase/Program Suspend & Resume
1.4.1.2 TOE Architecture
The architecture of the Memory Flash is described in Figure 1. The TOE is delimited by the
Red box.
Figure 1 TOE Architecture
The TOE consists of the following Hardware components

Auxiliary array contains the flash specific data: the binding key (and its digest
value), the failure and session counters;

Flash array stores the User data (i.e. the mass data including executable
codes) and translates SPI commands into Flash operations;

SFF (Secure Flash Front-end) which implements encrypted and authenticated
interface for Flash operation and supports Flash memories up to 4GB;

Detectors of abnormal operating conditions;
1.4.1.3 Interfaces of the TOE
 The physical interface of the TOE with the external environment is the entire
surface of the Memory Flash module.
PUBLIC
Page 7/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory

1.2
The electrical interface of the TOE with the external environment is made of the
chip’s pads including the data pins for SPI bus:
o
o
o
o
Standard SPI: CLK, /CS, DI_IO0, DO_IO1
Quad SPI: CLK, /CS, DI_IO0, DO_IO1, IO2, IO3
Octal: CLK, /CS, DI_IO0, DO_IO1, IO2, IO3, IO4, IO5,
IO6, IO7
1.4.2 Logical Scope
The main security features of the TOE are described as follows:

Secure separation between Test mode and Normal mode. More precisely,
-
The switch from Normal mode to Test mode can only be done after
completely erasing the flash content.
-
The confidentiality and the integrity of the flash content are protected in
both Test mode and Normal mode.

The Read data confidentiality and the integrity of the transmitted data from/to the
Host device are protected by a secure channel;

Integrity protection of the flash content by error detection codes (CRC-32);

Confidentiality protection of the flash content by memory scrambling with
diversified key;

Security sensors or detectors including power glitch detector and out-of-specified
operating conditions (voltage, temperature, clock frequency);

Active Shields against physical intrusive attacks (e.g. reverse-engineering,
probing);

State machine protection to counter fault injection;

Dual Flip-Flops and Path-Differential signaling to counter fault injection and sidechannel attacks;

Failure counter to detect and react to tamper attempts;
The logical interface of the TOE is made of Flash commands.
1.5 TOE operating modes
TEST mode
NORMAL mode
In TEST mode, the TOE provides access to
both the auxiliary and flash arrays. However,
there are some restrictions in the Test mode:
- The Binding Key (Kb) cannot be read
out;
- The auxiliary array can only be erased
if a complete erase has been done
after the last reset;
- The read and write commands do not
read and write effective values of the
flash;
In NORMAL mode, the access to the flash arrays is
authenticated and controlled via the flash
commands. There is no interface to access to the
auxiliary array.
TOE cannot switch back from NORMAL mode to
TEST mode without erasing all the memory.
Table 2 Operating modes
PUBLIC
Page 8/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
1.6 TOE Life cycle
The development, manufacturing and integration processes of the TOE into a composite
product can be separated into two distinct phases.
Phase
Title
Description
1
TOE
Development
2
TOE
Manufacturing
and Testing
Memory flash designer is
responsible for:
- TOE (HW)
development
Memory flash
Manufacturer is
responsible for:
- Photomask
manufacturing
-
wafer
manufacturing and
-
testing
Table 3 TOE life-cycle
The TOE is delivered as already packaged products (Known Good Die) after the phase 2.
The TOE user is responsible for developing the Host-based dedicated driver and for
generating a random and unique binding key (Kb) for binding the TOE to a unique Host.
PUBLIC
Page 9/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
2 Conformance Claim
This chapter 2 contains the following sections:

CC Conformance Claim

PP Claim

Package Claim

Conformance Claim Rationale
2.1 CC Conformance Claim
This Security target claims to be conformant to the Common Criteria version 3.1 Release 4.
Furthermore it claims to be CC Part 2 extended and CC Part 3 conformant.
2.2 PP Claim
This Security Target does not claim conformance to any Protection Profile.
2.3 Package Claim
The assurance level for this Security Target is EAL5 augmented with ALC_DVS.2 and
AVA_VAN.5 because the TOE is dedicated to store highly critical applications and data which
are submitted to advanced logical and physical attacks.
PUBLIC
Page 10/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
3 Security Problem Definition
3.1 Assets
Assets include all data stored in the TOE (including executable code of the applications).
They include:
 User data, that is typically stored in the "flash array" part of the memory chip;
 TSF data, that is relied upon for the enforcement of the TOE security functionality.
o TSF data contains sensitive data stored in registers or in the auxiliary array of the
memory chip.
o The TOE does not include any software, however the logic of the TOE security
mechanisms is still part of the TSF data. This logic is hardcoded in SFF.
3.1.1 TSF data
TSF logic
The TSF logic is the functionality of the TSF, and is hardcoded in the SFF component.
The TSF logic is protected in terms of integrity and confidentiality.
Binding key (Kb)
A unique 256-bit key that is shared between the TOE and the Host.
This key is protected in terms of integrity and confidentiality.
Runtime data
The internal runtime data necessary for the execution of the SFF: session key, memory
scrambling keys, Integrity Checking Engine register, stream-ciphering buffer, Bit mixing
key, Failure counter, session counter, etc. All runtime data shall be protected in terms of
integrity. All runtime data (except for the session counter) shall be protected in terms of
confidentiality.
3.1.2 User data
User data corresponds to all data stored inside the memory flash (including executable code
of the applications).
User Data
Mass data (including executable codes) stored in the "flash array" part of the memory
chip. User data is protected in terms of integrity and confidentiality.
3.2 Users / Subjects
U.Host-Device
The host device communicates with the TOE through a SPI Bus.
PUBLIC
Page 11/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
3.3 Threats
T.Phys-Manipulation
Physical Manipulation
An attacker may physically modify the Memory Flash in order to
o modify User Data stored in the TOE;
o modify TSF Data stored in the TOE;
o modify or deactivate the security services of the TOE (provided by TSF logic);
o modify the security mechanisms of the TOE (provided by TSF logic) to enable
attacks disclosing or manipulating User Data, for example the integrity protection
mechanism.
T.Phys-Probing
Physical Probing
An attacker may perform physical probing of the TOE in order to disclose User Data and
TSF Data while stored in Memory Flash.
T.Malfunction
Malfunction due to Environmental Stress
An attacker may cause a malfunction of TSF logic by applying environmental stress in
order to deactivate or affect security mechanisms of the TOE. This enables attacks
disclosing or manipulating User Data.
This may be achieved by operating the Memory Flash outside the normal operating
conditions.
T.Abuse-Func
Abuse of Functionality
An attacker may use functions of the TOE which may not be used after TOE Delivery in
order to
o disclose or manipulate User Data (user data or code stored in the TOE) or
o enable an attack disclosing or manipulating User Data.
T.Leak-Inherent
Inherent Information Leakage
An attacker may exploit information which is leaked from the TOE during usage of the
Memory Flash in order to disclose confidential User Data.
T.Leak-Forced
Forced Information Leakage
An attacker may exploit information which is leaked from the TOE during usage of the
Memory Flash in order to disclose confidential User Data even if the information leakage is
not inherent but caused by the attacker.
T.Abuse-Communication
Communication Probing and Manipulation
PUBLIC
Page 12/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
An attacker may probe and modify the communication between the TOE and U.HostDevice in order to manipulate User/TSF Data or disclose User/TSF Data read from the
TOE.
T.Host-Forging
Forge the functionality of an authorized Host device
An attacker may access to the User data currently stored in the TOE by:
o illegaly establishing a secure channel the with the TOE (e.g. by tampering the
Binding key or by forging the secure channel without knowing the Binding key) in
order to execute the Flash commands;
o binding the TOE with another Host device in order to execute the Flash
commands;
3.4 Organisational Security Policies
3.5 Assumptions
A.Secure-Channel
External protection during the secure channel
It is assumed that U.Host-Device supports the trusted communication channel with the
TOE by protecting the confidentiality and the integrity of the transmitted data.
In particular, U.Host-Device is assumed to correctly protect the secure channel in order
to prevent data modification, disclosure, insertion, deletion and replaying.
A.Binding-Process
Protection during Binding process
It is assumed that security procedures are used after delivery of the TOE by the TOE
Manufacturer to maintain confidentiality and integrity of the TOE (to prevent any possible
copy, modification, or unauthorised use).
This means that the binding process (i.e. generating a unique and random key Kb for
U.Host-Device and the TOE) is assumed to be done in a secure environment where the
communication between U.Host-Device and the TOE is protected.
Furthermore, U.Host-Device is assumed to provide a secure random source for
generating a fresh Binding key (Kb) for the TOE.
PUBLIC
Page 13/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
4 Security Objectives
4.1 Security Objectives for the TOE
This chapter contains the following sections:
 Security Objectives for the TOE
 Security Objectives for the operational Environment
 Security Objectives Rationale
O.Phys-Probing
Protection against Physical Probing
The TOE must provide protection against disclosure/reconstruction of User Data and TSF
Data while stored in the Flash.
This includes protection against
o measuring through galvanic contacts which is direct physical probing on the chips
surface except on pads being bonded (using standard tools for measuring voltage
and current) or
o measuring not using galvanic contacts but other types of physical interaction
between charges (using tools used in solid-state physics research and IC failure
analysis) with a prior reverse-engineering to understand the design and its
properties and functions.
The TOE must be designed and fabricated so that it requires a high combination of
complex equipment, knowledge, skill, and time to be able to derive detailed design
information or other information which could be used to compromise security through
such a physical attack.
O.Malfunction
Protection against Malfunctions
The TOE must ensure its correct operation. The TOE must indicate and prevent its
operation outside the normal operating conditions where reliability and secure operation
has not been proven or tested. This is to prevent malfunctions. Examples of
environmental conditions are voltage, and clock frequency, temperature, or external
energy fields.
O.Phys-Manipulation
Protection against Physical Manipulation
The TOE must provide protection against manipulation of User Data (the user data stored
in the TOE) and TSF data. This includes protection against
o reverse-engineering (understanding the design and its properties and functions),
o manipulation of the hardware and TSF data, as well as
o undetected manipulation of User data (i.e. Flash array).
O.Abuse-Func
Protection against Abuse of Functionality
PUBLIC
Page 14/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
The TOE must prevent that functions of the TOE which may not be used after TOE
Delivery can be abused in order to (i) disclose sensitive user data stored in the TOE, (ii)
manipulate sensitive user data stored in the TOE.
O.Leak-Inherent
Protection against Inherent Information Leakage
The TOE must provide protection against disclosure of confidential data stored and
processed in the TOE
o by measurement and analysis of the shape and amplitude of signals (for example
on the power, clock, or I/O lines) and
o by measurement and analysis of the time between events found by measuring
signals (for instance on the power, clock, or I/O lines).
O.Leak-Forced
Protection against Forced Information Leakage
The TOE must be protected against disclosure of confidential data processed in the TOE
(using methods as described under O.Leak-Inherent) even if the information leakage is
not inherent but caused by the attacker
o by forcing a malfunction (refer to "Protection against Malfunction due to
Environmental Stress O.Malfunction") and/or
o by a physical manipulation (refer to "Protection against Physical Manipulation O.Phys-Manipulation").
If this is not the case, signals which normally do not contain significant information about
secrets could become an information channel for a leakage attack.
O.Sec-Binding
Protection of residual information at Re-binding
This objective protects against the disclosure of the User data when the TOE is re-bound
to another Host device.
This includes protection against:
o integrity failure on Binding Key
o illegal modification on Binding Key
o illegal attempt to erase the Binding key
O.Trusted-Path
Trusted communication with authorized Host
The TSF provides a trusted path only with authorized U.Host-Device (based on the
shared Binding key), and protects the integrity of the User data communicated with
U.Host-Device and the confidentiality of the User data read by U.Host-Device.
4.2 Security Objectives for the Operational Environment
OE.Secure-Channel
Secure communication with the TOE
The authorized U.Host-Device shall support the trusted communication channel with the
TOE by protecting the confidentiality and the integrity of the transmitted data.
PUBLIC
Page 15/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
In particular, U.Host-Device shall correctly protect the secure channel in order to
prevent data modification, disclosure, insertion, deletion and replaying.
OE.Binding-Process
Protection during Binding process
Security procedures shall be used after the TOE delivery to maintain confidentiality and
integrity of the TOE (to prevent any possible copy, modification, retention, theft or
unauthorised use).
In addition, U.Host-Device shall provide a secure random source for generating a fresh
Binding key (Kb) for the TOE.
4.3 Security Objectives Rationale
4.3.1 Threats
T.Phys-Manipulation This threat is countered by the security objectives O.PhysManipulation. This objective ensures that the protection against manipulation of the user
data is provided by the TOE.
T.Phys-Probing This threat is countered by the security objectives O.Phys-Probing. This
objective ensures that the protection against disclosure/reconstruction of User Data and
TSF Data while stored in the Flash is provided by the TOE.
T.Malfunction This threat is countered by the security objectives O.Malfunction. This
objective ensures the correct operation of the TOE outside the normal operating
conditions.
T.Abuse-Func This threat is countered by the security objectives O.Abuse-Func. This
objective prevents that functions of the TOE which may not be used after TOE Delivery
can be abused in order to manipulate/disclose sensitive user data stored in the TOE.
T.Leak-Inherent This threat is countered by the security objectives O.Leak-Inherent. This
objective ensures the protection against disclosure of confidential data stored and
processed in the TOE.
T.Leak-Forced This threat is countered by the security objectives O.Leak-Forced. This
objective ensures the protection against disclosure of confidential data stored and
processed in the TOE even if the information leakage is not inherent but caused by the
attacker.
T.Abuse-Communication This threat is countered by the security objective O.TrustedPath. This objective protects the integrity of the User/TSF data communicated with
U.Host-Device and the confidentiality of the User/TSF data read by U.Host-Device.
T.Host-Forging This threat is countered by the security objectives:
o O.Trusted-Path to protect the integrity of the User data communicated with
U.Host-Device and the confidentiality of the User data read by U.Host-Device
PUBLIC
Page 16/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
o O.Sec-Binding to protect against the disclosure of the User data when the TOE is
re-bound to another Host device
4.3.2 Assumptions
A.Secure-Channel Since OE.Secure-Channel requires the Host device to implement the
protection assumed in A.Secure-Channel, the assumption is covered by this objective.
A.Binding-Process Since OE.Binding-Process requires the Composite Product Manufacturer
to implement those measures assumed in A.Binding-Process, the assumption is covered
by this objective.
4.3.3 SPD and Security Objectives
Threats
Security Objectives
Rationale
T.Phys-Manipulation
O.Phys-Manipulation
Section 4.3.1
T.Phys-Probing
O.Phys-Probing
Section 4.3.1
T.Malfunction
O.Malfunction
Section 4.3.1
T.Abuse-Func
O.Abuse-Func
Section 4.3.1
T.Leak-Inherent
O.Leak-Inherent
Section 4.3.1
T.Leak-Forced
O.Leak-Forced
Section 4.3.1
T.Abuse-Communication
O.Trusted-Path
Section 4.3.1
T.Host-Forging
O.Trusted-Path, O.Sec-Binding
Section 4.3.1
Table 4 Threats and Security Objectives - Coverage
Security Objectives
Threats
O.Phys-Probing
T.Phys-Probing
O.Malfunction
T.Malfunction
O.Phys-Manipulation
T.Phys-Manipulation
O.Abuse-Func
T.Abuse-Func
O.Leak-Inherent
T.Leak-Inherent
O.Leak-Forced
T.Leak-Forced
O.Sec-Binding
T.Host-Forging
O.Trusted-Path
T.Abuse-Communication, T.Host-Forging
Table 5 Security Objectives and Threats - Coverage
PUBLIC
Page 17/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
Assumptions
Security Objectives for the Operational Environment
Rationale
A.Secure-Channel
OE.Secure-Channel
Section 4.3.2
A.Binding-Process
OE.Binding-Process
Section 4.3.2
Table 6 Assumptions and Security Objectives for the Operational Environment - Coverage
Security Objectives for the Operational Environment Assumptions
OE.Secure-Channel
A.SecureChannel
OE.Binding-Process
A.BindingProcess
Table 7 Security Objectives for the Operational Environment and Assumptions - Coverage
PUBLIC
Page 18/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
5 Extended Requirements
5.1 Extended Families
5.1.1 Extended Family FMT_LIM - Limited capabilities and availability
5.1.1.1 Description
To define the IT security functional requirements of the TOE an additional family (FMT_LIM)
of the Class FMT (Security Management) is defined here. This family describes the functional
requirements for the Test Features of the TOE. The new functional requirements were
defined in the class FMT because this class addresses the management of functions of the
TSF. The examples of the technical mechanism used in the TOE (refer to Section 6.1)
appropriate to address the specific issues of preventing the abuse of functions by limiting the
capabilities of the functions and by limiting their availability.
The family "Limited capabilities and availability (FMT_LIM)" is specified as follows.
FMT_LIM Limited capabilities and availability
Family behaviour
This family defines requirements that limit the capabilities and availability of functions in a
combined manner. Note that FDP_ACF restricts the access to functions whereas the
component Limited Capability of this family requires the functions themselves to be designed
in a specific manner.
Component levelling:
FMT_LIM.1 Limited capabilities requires that the TSF is built to provide only the capabilities
(perform action, gather information) necessary for its genuine purpose.
FMT_LIM.2 Limited availability requires that the TSF restrict the use of functions (refer to
Limited capabilities (FMT_LIM.1)). This can be achieved, for instance, by removing or by
disabling functions in a specific phase of the TOE's life-cycle.
Management: FMT_LIM.1, FMT_LIM.2
There are no management activities foreseen.
Audit: FMT_LIM.1, FMT_LIM.2
PUBLIC
Page 19/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
There are no actions defined to be auditable.
5.1.1.2 Extended Components
Extended Component FMT_LIM.1
Description
Limited capabilities requires that the TSF is built to provide only the capabilities (perform
action, gather information) necessary for its genuine purpose.
Hierarchical to: No other components.
Definition
FMT_LIM.1 Limited capabilities
FMT_LIM.1.1 The TSF shall be designed and implemented in a manner that limits its
capabilities so that in conjunction with "Limited availability (FMT_LIM.2)" the following
policy is enforced [assignment: Limited capability policy].
Dependencies: (FMT_LIM.2)
Extended Component FMT_LIM.2
Description
Limited availability requires that the TSF restrict the use of functions (refer to Limited
capabilities (FMT_LIM.1)). This can be achieved, for instance, by removing or by disabling
functions in a specific phase of the TOE's life-cycle.
Hierarchical to: No other components.
Definition
FMT_LIM.2 Limited availability
FMT_LIM.2.1 The TSF shall be designed in a manner that limits its availability so that in
conjunction with "Limited capabilities (FMT_LIM.1)" the following policy is enforced
[assignment: Limited availability policy].
Dependencies: (FMT_LIM.1)
Application Note:
The functional requirements FMT_LIM.1 and FMT_LIM.2 assume that there are two types of
mechanisms (limitation of capabilities and limitation of availability) which together shall
provide protection in order to enforce the same policy or two mutual supportive policies
related to the same functionality. This allows e.g. that
PUBLIC
Page 20/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
(i) the TSF is provided without restrictions in the product in its user environment but its
capabilities are so limited that the policy is enforced or conversely
(ii) the TSF is designed with high functionality but is removed or disabled in the product in its
user environment.
5.1.2 Extended Family FDP_SDC - Stored data confidentiality
5.1.2.1 Description
To define the security functional requirements of the TOE an additional family (FDP_SDC.1)
of the Class FDP (User data protection) is defined here.
The family "Stored data confidentiality (FDP_SDC)" is specified as follows.
FDP_SDC Stored data confidentiality
Family behaviour
This family provides requirements that address protection of user data confidentiality while
these data are stored within memory areas protected by the TSF. The TSF provides access
to the data in the memory through the specified interfaces only and prevents compromise of
their information bypassing these interfaces. It complements the family Stored data integrity
(FDP_SDI) which protects the user data from integrity errors while being stored in the
memory.
Component levelling:
FDP_SDC.1 Requires the TOE to protect the confidentiality of information of the user data in
specified memory areas.
Management: FDP_SDC.1
There are no management activities foreseen.
Audit: FDP_SDC.1
There are no actions defined to be auditable.
5.1.2.2 Extended Components
Extended Component FDP_SDC.1
Description
Requires the TOE to protect the confidentiality of information of the user data in specified
memory areas.
Hierarchical to: No other components.
PUBLIC
Page 21/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
Definition
FDP_SDC.1 Stored data confidentiality
FDP_SDC.1.1 The TSF shall ensure the confidentiality of the information of the user data
while it is stored in the [assignment: memory areas].
Dependencies: No dependencies.
PUBLIC
Page 22/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
6 Security Requirements
6.1 Security Functional Requirements
6.1.1 Malfunctions
FRU_FLT.2 Limited fault tolerance
FRU_FLT.2.1 The TSF shall ensure the operation of all the TOE's capabilities when the
following failures occur: [assignment: list of type of failures].
The TSF shall ensure the operation of all the TOE's capabilities when the following failures
occur: exposure to operating conditions which are not detected according to
the
requirement
Failure
(FPT_FLS.1/Detectors).
with
preservation
of
secure
state
Application Note:
The term "failure" above means "circumstances". The TOE prevents failures for the
"circumstance" defined above.
FPT_FLS.1/Detectors Failure with preservation of secure state
FPT_FLS.1.1/Detectors The TSF shall preserve a secure state when the following types of
failures occur: [assignment: list of types of failures in the TSF].
The TSF shall preserve a secure state when the following types of failures occur:
o Out-of-specified range voltage
o Out-of-specified range temperature
o Out-of specified range clock frequency
o Power glitch.
Application Note:
The term "failure" above means "circumstances". The TOE prevents failures for the
"circumstance" defined above.
The secure state is maintained by TSF's detectors. The TSF's detectors monitor the failures.
If a failure happens, the TSF disturbs the cryptographic computations, interrupts data
interchange and inform U.Host-Device.
6.1.2 Abuse of Functionality
PUBLIC
Page 23/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
FMT_LIM.1 Limited capabilities
FMT_LIM.1.1 The TSF shall be designed and implemented in a manner that limits its
capabilities so that in conjunction with "Limited availability (FMT_LIM.2)" the following
policy is enforced [assignment: Limited capability policy].
The TSF shall be designed and implemented in a manner that limits its capabilities so that
in conjunction with "Limited availability (FMT_LIM.2)" the following policy is enforced
Deploying Test Features after TOE Delivery does not allow user data to be
disclosed or manipulated, TSF data to be disclosed or manipulated, and no
substantial information about construction of TSF to be gathered which may
enable other attacks.
Application Note:
In the Test mode, the following restrictions are enforced by the TSF:
 The Binding Key (Kb) cannot be read out by the Flash commands;
 The Binding key cannot be erased unless a complete erase has been done after the
last reset;
 The read and write commands do not read and write effective values of the flash
array;
FMT_LIM.2 Limited availability
FMT_LIM.2.1 The TSF shall be designed in a manner that limits its availability so that in
conjunction with "Limited capabilities (FMT_LIM.1)" the following policy is enforced
[assignment: Limited availability policy].
The TSF shall be designed in a manner that limits its availability so that in conjunction
with "Limited capabilities (FMT_LIM.1)" the following policy is enforced Deploying Test
Features after TOE Delivery does not allow user data to be disclosed or
manipulated, TSF data to be disclosed or manipulated, and no substantial
information about construction of TSF to be gathered which may enable other
attacks.
Application Note:
The switch from Normal mode to Test mode is allowed after TOE delivery but after the flash
array is completely erased.
6.1.3 Physical Manipulation and Probing
FDP_SDC.1 Stored data confidentiality
FDP_SDC.1.1 The TSF shall ensure the confidentiality of the information of the user data
while it is stored in the [assignment: memory areas].
The TSF shall ensure the confidentiality of the information of the user data while it is
stored in the Flash array.
PUBLIC
Page 24/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
FDP_SDI.2 Stored data integrity monitoring and action
FDP_SDI.2.1 The TSF shall monitor user data stored in containers controlled by the TSF for
[assignment: integrity errors] on all objects, based on the following attributes:
[assignment: user data attributes].
The TSF shall monitor user data stored in containers controlled by the TSF for CRC-32
error detecting code on all objects, based on the following attributes: stored in the
Flash array.
FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall [assignment: action to
be taken].
Upon detection of a data integrity error, the TSF shall inform U.Host-Device about the
error. In addition, the TSF also sends a pseudo-randomly chosen part of the
CRC-32 error detecting bits to U.Host-Device in a secure manner so that data
integrity can be independently verified by U.Host-Device.
FPT_PHP.3 Resistance to physical attack
FPT_PHP.3.1 The TSF shall resist [assignment: physical tampering scenarios] to the
[assignment: list of TSF devices/elements] by responding automatically such that the
SFRs are always enforced.
The TSF shall resist physical manipulation and physical probing to the TSF by
responding automatically such that the SFRs are always enforced.
Application Note:
The TSF will implement appropriate mechanisms to continuously counter physical
manipulation and physical probing. Due to the nature of these attacks (especially
manipulation) the TSF can by no means detect attacks on all of its elements. Therefore,
permanent protection against these attacks is required ensuring that security functional
requirements are enforced. Hence, "automatic response" means here (i) assuming that there
might be an attack at any time and (ii) countermeasures are provided at any time.
6.1.4 Leakage
FDP_ITT.1 Basic internal transfer protection
FDP_ITT.1.1 The TSF shall enforce the [assignment: access control SFP(s) and/or
information flow control SFP(s)] to prevent the [selection: disclosure, modification, loss of
use] of user data when it is transmitted between physically-separated parts of the TOE.
The TSF shall enforce the Data Processing Policy to prevent the disclosure of user
data when it is transmitted between physically-separated parts of the TOE.
Application Note:
The Flash array and the SFF are seen as physically-separated parts of the TOE.
PUBLIC
Page 25/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
FPT_ITT.1 Basic internal TSF data transfer protection
FPT_ITT.1.1 The TSF shall protect TSF data from [selection: disclosure, modification] when
it is transmitted between separate parts of the TOE.
The TSF shall protect TSF data from disclosure when it is transmitted between separate
parts of the TOE.
Application Note:
The Flash array and the SFF are seen as physically-separated parts of the TOE.
FDP_IFC.1 Subset information flow control
FDP_IFC.1.1 The TSF shall enforce the [assignment: information flow control SFP] on
[assignment: list of subjects, information, and operations that cause controlled
information to flow to and from controlled subjects covered by the SFP].
The TSF shall enforce the Data Processing Policy on User data that is processed or
transferred by the TOE or by U.Host-Device.
Application Note:
The following Security Function Policy (SFP) Data Processing Policy is defined for the
requirement "Subset information flow control (FDP_IFC.1)"
"User data and TSF data shall not be accessible from the TOE except when the U.HostDevice decides to communicate the User data via an external interface".
6.1.5 Secure Data Exchange
FDP_UCT.1 Basic data exchange confidentiality
FDP_UCT.1.1 The TSF shall enforce the [assignment: access control SFP(s) and/or
information flow control SFP(s)]to [selection: transmit, receive] user data in a manner
protected from unauthorised disclosure.
The TSF shall enforce the Data Processing Policy to transmit user data in a manner
protected from unauthorised disclosure.
FDP_UIT.1 Data exchange integrity
FDP_UIT.1.1 The TSF shall enforce the [assignment: access control SFP(s) and/or
information flow control SFP(s)]to [selection: transmit, receive] user data in a manner
protected from [selection: modification, deletion, insertion, replay] errors.
The TSF shall enforce the Data Processing Policy to transmit and receive user data
in a manner protected from modification, deletion, and insertion errors.
PUBLIC
Page 26/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
FDP_UIT.1.2 The TSF shall be able to determine on receipt of user data, whether
[selection: modification, deletion, insertion, replay] has occurred.
The TSF shall be able to determine on receipt of user data, whether modification,
deletion, and insertion has occurred.
FTP_TRP.1 Trusted path
FTP_TRP.1.1 The TSF shall provide a communication path between itself and [selection:
remote, local] users that is logically distinct from other communication paths and provides
assured identification of its end points and protection of the communicated data from
[selection: modification, disclosure, [assignment: other types of integrity or confidentiality
violation]].
The TSF shall provide a communication path between itself and remote users that is
logically distinct from other communication paths and provides assured identification of its
end points and protection of the communicated data from modification and
disclosure.
Application Note:
The protection against disclosure is only provided for data transmitted from the TSF (to
U.Host-Device). The protection against modification is provided for all communicated data.
FTP_TRP.1.2 The TSF shall permit [selection: the TSF, local users, remote users] to initiate
communication via the trusted path.
The TSF shall permit remote users to initiate communication via the trusted path.
FTP_TRP.1.3 The TSF shall require the use of the trusted path for [selection: initial user
authentication, [assignment: other services for which trusted path is required]].
The TSF shall require the use of the trusted path for any access to User data stored
in the Flash array.
6.1.6 Protection of Binding Key
FPT_FLS.1/Binding_Key Failure with preservation of secure state
FPT_FLS.1.1/Binding_Key The TSF shall preserve a secure state when the following
types of failures occur: [assignment: list of types of failures in the TSF].
The TSF shall preserve a secure state when the following types of failures occur:
integrity failure on Binding Key.
Application Note:
The secure state is defined as follows:
 if the Binding key is illegaly modified, then the TOE is locked;
 if the Binding key is erased, then the TOE User data (stored in the Flash array) is also
erased;
PUBLIC
Page 27/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
FDP_RIP.1 Subset residual information protection
FDP_RIP.1.1 [Editorially Refined] The TSF shall ensure that any previous information
content of the Flash array is made unavailable upon the [selection: allocation of the
resource to, deallocation of the resource from] the following objects: [assignment: list of
objects].
The TSF shall ensure that any previous information content of the Flash array is made
unavailable upon the allocation of the resource to and deallocation of the
resource from the following objects: the Binding key (Kb).
Application Note:
 "Object Allocation" means that a new Binding key is set in order to replace the current
Binding key.
 "Object Deallocation" means that the current Binding key is erased from the TSF (more
precisely, from the auxiliary array).
6.2 Security Assurance Requirements
The Evaluation Assurance Level is EAL5 augmented with ALC_DVS.2 and AVA_VAN.5.
6.2.1 Refinements of the TOE Assurance Requirements
6.2.1.1 Refinement regarding Vulnerability Analysis (AVA_VAN)
Application Note:
Evaluator may assess the Flash array content protection in addition to the
vulnerability analysis related to the SFR FDP_SDC.1 in order to assess effectiveness of
the security architecture if relevant security features of the TOE are identified.
Application Note:
The Vulnerability Analysis will assess the resistance against Side Channel Attacks to
meet the SFP “Data Processing Policy” defined for the SFR “Subset information flow
control (FDP_IFC.1)” and the security architecture aspect non-bypassability of the SFR
“Stored data confidentiality (FDP_SDC.1)”.
PUBLIC
Page 28/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
6.3 Security Requirements Rationale
6.3.1 Objectives
6.3.1.1 Security Objectives for the TOE
O.Phys-Probing The SFR FDP_SDC.1 requires the TSF to protect the confidentiality of the
user data stored in specified memory areas and prevent its compromise by physical
attacks bypassing the specified interfaces for memory access. The scenario of physical
probing as described for this objective is explicitly included in the assignment chosen for
the physical tampering scenarios in FPT_PHP.3. Therefore, it is clear that this security
functional requirement supports the objective.
O.Malfunction The definition of this objective shows that it covers a situation, where
malfunction of the TOE might be caused by the operating conditions of the TOE (while
direct manipulation of the TOE is covered O.Phys-Manipulation). There are two
possibilities in this situation: Either the operating conditions are inside the tolerated range
or at least one of them is outside of this range. The second case is covered by
FPT_FLS.1/Detectors, because it states that a secure state is preserved in this case. The
first case is covered by FRU_FLT.2 because it states that the TOE operates correctly
under normal (tolerated) conditions.
O.Phys-Manipulation The SFR FDP_SDI.2 requires the TSF to detect the integrity errors of
the stored user data and react in case of detected errors. More precisely, FDP_SDI.2
prevents manipulation of memory contents by ensuring detection and response from the
TSF (use of a filure counter and capability to lock the session or the TOE itself).
The scenario of physical manipulation as described for this objective is explicitly included
in the assignment chosen for the physical tampering scenarios in FPT_PHP.3. Therefore, it
is clear that this security functional requirement supports the objective.
O.Abuse-Func This objective states that abuse of functions (especially provided by the IC
Dedicated Test Software, for instance in order to read secret data) must not be possible
when TOE is used by the final user. There are two possibilities to achieve this: (i) They
cannot be used by an attacker (i. e. its availability is limited) or (ii) using them would not
be of relevant use for an attacker (i. e. its capabilities are limited) since the functions are
designed in a specific way. The first possibility is specified by FMT_LIM.2 and the second
one by FMT_LIM.1. Since these requirements are combined to support the policy, which is
suitable to fulfil O.Abuse-Func, both security functional requirements together are suitable
to meet the objective. Other security functional requirements (FPT_ITT.1, FDP_ITT.1,
FPT_PHP.3, FRU_FLT.2, FPT_FLS.1/Detectors and FDP_IFC.1) which prevent attackers
from circumventing the functions implementing these two security functional
requirements (for instance by manipulating the hardware) also support the objective. The
relevant objectives are O.Leak-Inherent, O.Phys-Probing, O.Malfunction, O.PhysManipulation, O.Leak-Forced.
O.Leak-Inherent The refinements of the security functional requirements FPT_ITT.1 and
FDP_ITT.1 together with the policy statement in FDP_IFC.1 explicitly require the
prevention of disclosure of secret data (TSF data as well as user data) when while being
processed. This includes that attackers cannot reveal such data by measurements of
PUBLIC
Page 29/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
emanations, power consumption or other behaviour of the TOE while data is processed by
TOE parts.
O.Leak-Forced This objective is directed against attacks, where an attacker wants to force
an information leakage, which would not occur under normal conditions. In order to
achieve this the attacker has to combine a first attack step, which modifies the behaviour
of the TOE (either by exposing it to extreme operating conditions or by directly
manipulating it) with a second attack step measuring and analysing some output
produced by the TOE. The first step is prevented by the same mechanisms which support
O.Malfunction (FPT_FLS.1/Detectors, FRU_FLT.2) and O.Phys-Manipulation (FPT_PHP.3),
respectively. The requirements covering O.Leak-Inherent (FPT_ITT.1, FDP_ITT.1,
FDP_IFC.1) also support O.Leak-Forced because they prevent the attacker from being
successful if he tries the second step directly.
O.Sec-Binding The security functional requirement FDP_RIP.1 ensures that the User data is
erased before the Host device is changed.
O.Trusted-Path The security functional requirement FTP_TRP.1 contribute in this
protection because it only establishes a trusted path between the TSF and authorized
U.Host-Device for the communication purpose.
The security functional requirement FPT_FLS.1/Binding_Key protects the Binding key
against the tampering.
The security functional requirements FDP_UCT.1 and FDP_UIT.1 protect against the
modification (interity) of the User Data communicated with U.Host-Device and against
the disclosure (confidentiality) of the User data read by U.Host-Device.
PUBLIC
Page 30/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
6.3.2 Rationale tables of Security Objectives and SFRs
Security
Objectives
Security Functional Requirements
O.Phys-Probing
FPT_PHP.3, FDP_SDC.1
Section
6.3.1.1
O.Malfunction
FRU_FLT.2, FPT_FLS.1/Detectors
Section
6.3.1.1
O.PhysManipulation
FDP_SDI.2, FPT_PHP.3
Section
6.3.1.1
O.Abuse-Func
FDP_ITT.1, FPT_ITT.1, FPT_PHP.3, FRU_FLT.2,
FPT_FLS.1/Detectors, FMT_LIM.1, FMT_LIM.2, FDP_IFC.1
Section
6.3.1.1
O.Leak-Inherent FDP_ITT.1, FPT_ITT.1, FDP_IFC.1
Rationale
Section
6.3.1.1
O.Leak-Forced
FDP_ITT.1, FPT_ITT.1, FRU_FLT.2, FPT_FLS.1/Detectors,
FPT_PHP.3, FDP_IFC.1
Section
6.3.1.1
O.Sec-Binding
FDP_RIP.1
Section
6.3.1.1
O.Trusted-Path
FDP_UCT.1, FDP_UIT.1, FPT_FLS.1/Binding_Key,
FTP_TRP.1
Section
6.3.1.1
Table 8 Security Objectives and SFRs - Coverage
PUBLIC
Page 31/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
Security Functional
Requirements
Security Objectives
FRU_FLT.2
O.Malfunction, O.Abuse-Func, O.Leak-Forced
FPT_FLS.1/Detectors
O.Malfunction, O.Abuse-Func, O.Leak-Forced
FMT_LIM.1
O.Abuse-Func
FMT_LIM.2
O.Abuse-Func
FDP_SDC.1
O.Phys-Probing
FDP_SDI.2
O.Phys-Manipulation
FPT_PHP.3
O.Phys-Probing, O.Phys-Manipulation,
O.Abuse-Func, O.Leak-Forced
FDP_ITT.1
O.Abuse-Func, O.Leak-Inherent, O.LeakForced
FPT_ITT.1
O.Abuse-Func, O.Leak-Inherent, O.LeakForced
FDP_IFC.1
O.Abuse-Func, O.Leak-Inherent, O.LeakForced
FDP_UCT.1
O.Trusted-Path
FDP_UIT.1
O.Trusted-Path
FTP_TRP.1
O.Trusted-Path
FPT_FLS.1/Binding_Key
O.Trusted-Path
FDP_RIP.1
O.Sec-Binding
Table 9 SFRs and Security Objectives
PUBLIC
Page 32/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
6.3.3 Dependencies
6.3.3.1 SFRs Dependencies
Requirements
CC Dependencies
Satisfied Dependencies
FRU_FLT.2
(FPT_FLS.1)
FPT_FLS.1/Detectors
FPT_FLS.1/Detectors
No Dependencies
FMT_LIM.1
(FMT_LIM.2)
FMT_LIM.2
FMT_LIM.2
(FMT_LIM.1)
FMT_LIM.1
FDP_SDC.1
No Dependencies
FDP_SDI.2
No Dependencies
FPT_PHP.3
No Dependencies
FDP_ITT.1
(FDP_ACC.1 or FDP_IFC.1)
FPT_ITT.1
No Dependencies
FDP_IFC.1
(FDP_IFF.1)
FDP_UCT.1
(FDP_ACC.1 or FDP_IFC.1) and
(FTP_ITC.1 or FTP_TRP.1)
FDP_IFC.1, FTP_TRP.1
FDP_UIT.1
(FDP_ACC.1 or FDP_IFC.1) and
(FTP_ITC.1 or FTP_TRP.1)
FDP_IFC.1, FTP_TRP.1
FTP_TRP.1
No Dependencies
FPT_FLS.1/Binding_Key
No Dependencies
FDP_RIP.1
No Dependencies
FDP_IFC.1
Table 10 SFRs Dependencies
Rationale for the exclusion of Dependencies
The dependency FDP_IFF.1 of FDP_IFC.1 is discarded. Part 2 of the Common Criteria
defines the dependency of FDP_IFC.1 (information flow control policy statement) on
FDP_IFF.1 (Simple security attributes). The specification of FDP_IFF.1 would not capture
the nature of the security functional requirement nor add any detail.
As stated in the Data Processing Policy referred to in FDP_IFC.1, there are no attributes
necessary. The security functional requirement for the TOE is sufficiently described using
FDP_ITT.1 and its Data Processing Policy (FDP_IFC.1).
PUBLIC
Page 33/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
6.3.3.2 SARs Dependencies
Requirements CC Dependencies
Satisfied Dependencies
ADV_ARC.1
(ADV_FSP.1) and (ADV_TDS.1)
ADV_FSP.5, ADV_TDS.4
ADV_FSP.5
(ADV_IMP.1) and (ADV_TDS.1)
ADV_IMP.1, ADV_TDS.4
ADV_IMP.1
(ADV_TDS.3) and (ALC_TAT.1)
ADV_TDS.4, ALC_TAT.2
ADV_INT.2
(ADV_IMP.1) and (ADV_TDS.3) and
(ALC_TAT.1)
ADV_IMP.1, ADV_TDS.4,
ALC_TAT.2
ADV_TDS.4
(ADV_FSP.5)
ADV_FSP.5
AGD_OPE.1
(ADV_FSP.1)
ADV_FSP.5
AGD_PRE.1
No Dependencies
ALC_CMC.4
(ALC_CMS.1) and (ALC_DVS.1) and
(ALC_LCD.1)
ALC_CMS.5
No Dependencies
ALC_DEL.1
No Dependencies
ALC_DVS.2
No Dependencies
ALC_LCD.1
No Dependencies
ALC_TAT.2
(ADV_IMP.1)
ADV_IMP.1
ASE_CCL.1
(ASE_ECD.1) and (ASE_INT.1) and
(ASE_REQ.1)
ASE_ECD.1, ASE_INT.1,
ASE_REQ.2
ASE_ECD.1
No Dependencies
ASE_INT.1
No Dependencies
ASE_OBJ.2
(ASE_SPD.1)
ASE_SPD.1
ASE_REQ.2
(ASE_ECD.1) and (ASE_OBJ.2)
ASE_ECD.1, ASE_OBJ.2
ASE_SPD.1
No Dependencies
ASE_TSS.1
(ADV_FSP.1) and (ASE_INT.1) and
(ASE_REQ.1)
ADV_FSP.5, ASE_INT.1,
ASE_REQ.2
ATE_COV.2
(ADV_FSP.2) and (ATE_FUN.1)
ADV_FSP.5, ATE_FUN.1
ATE_DPT.3
(ADV_ARC.1) and (ADV_TDS.4) and
(ATE_FUN.1)
ADV_ARC.1, ADV_TDS.4,
ATE_FUN.1
ATE_FUN.1
(ATE_COV.1)
ATE_COV.2
ATE_IND.2
(ADV_FSP.2) and (AGD_OPE.1) and
(AGD_PRE.1) and (ATE_COV.1) and
(ATE_FUN.1)
ADV_FSP.5, AGD_OPE.1,
AGD_PRE.1, ATE_COV.2,
ATE_FUN.1
AVA_VAN.5
(ADV_ARC.1) and (ADV_FSP.4) and
(ADV_IMP.1) and (ADV_TDS.3) and
(AGD_OPE.1) and (AGD_PRE.1) and
(ATE_DPT.1)
ADV_ARC.1, ADV_FSP.5,
ADV_IMP.1, ADV_TDS.4,
AGD_OPE.1, AGD_PRE.1,
ATE_DPT.3
ALC_CMS.5, ALC_DVS.2,
ALC_LCD.1
Table 11 SARs Dependencies
PUBLIC
Page 34/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
6.3.4 Rationale for the Security Assurance Requirements
The assurance level EAL5 and the augmentation with the requirements ALC_DVS.2, and
AVA_VAN.5 were chosen in order to meet assurance expectations explained in the following
paragraphs.
An assurance level of EAL5 with the augmentations AVA_VAN.5 and ALC_DVS.2 are required
for this type of TOE since it is intended to defend against sophisticated attacks. This
evaluation assurance package was selected to permit a developer to gain maximum
assurance from positive security engineering based on good commercial practices. In order
to provide a meaningful level of assurance that the TOE provides an adequate level of
defence against such attacks, the evaluators should have access to the low level design and
source code.
6.3.5 ALC_DVS.2 Sufficiency of security measures
Development security is concerned with physical, procedural, personnel and other technical
measures that may be used in the development environment to protect the TOE.
In the particular case of a memory flash the TOE is developed and produced within a
complex and distributed industrial process which must especially be protected. Details about
the implementation, (e.g. from design, test and development tools as well as Initialisation
Data) may make such attacks easier. Therefore, in the case of a memory flash, maintaining
the confidentiality of the design is very important.
This assurance component is a higher hierarchical component to EAL5 (which only requires
ALC_DVS.1). ALC_DVS.2 has no dependencies.
6.3.6 AVA_VAN.5 Advanced methodical vulnerability analysis
Due to the intended use of the TOE, it must be shown to be highly resistant to penetration
attacks. This assurance requirement is achieved by the AVA_VAN.5 component.
Independent vulnerability analysis is based on highly detailed technical information. The
main intent of the evaluator analysis is to determine that the TOE is resistant to penetration
attacks performed by an attacker possessing high attack potential.
AVA_VAN.5 has dependencies to ADV_ARC.1 "Security architecture description", ADV_FSP.2
"Security enforcing functional specification", ADV_TDS.3 "Basic modular design", ADV_IMP.1
"Implementation representation of the TSF", AGD_OPE.1 "Operational user guidance", and
AGD_PRE.1 "Preparative procedures". All these dependencies are satisfied by EAL5.
It has to be assumed that attackers with high attack potential try to attack memory flashes
embedded in smart cards used for digital signature applications or payment systems.
Therefore, specifically AVA_VAN.5 was chosen in order to assure that even these attackers
cannot successfully attack the TOE.
PUBLIC
Page 35/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
7 TOE Summary Specification
This Chapter describes the TSF security functionality by a set of security features and
justifies how the SFR defined in Chapter 6 are enforced by those features.
7.1 TOE Summary Specification
SF.SEC-COM
Secure communication
SF.SEC-COM protects the integrity of the communication between the TOE and U.HostDevice against probing, Man-in-the-Middle and hammering attacks. The confidentiality of
the communication is also protected when data stored in the TOE is read by U.HostDevice. In particular,
o a fresh session key is used for each session;
o for reading operation: 8 transport integrity check bits are added to each 32 bit
long word, providing a progressive authentication of the transmitted data; the
payload is encrypted using the session key.
o for update operations (write/erase): a MAC digest is added to ensure integrity;
SF.PHY-PRO
Physical protection
SF.PHY-PRO protects the TOE against physical manipulation (including the TOE probing).
SF.PHY-PRO includes the following security mechanisms:
o Failure counter: this counter is incremented after each tamper-detection and the
TOE is locked if the counter reaches a pre-defined value.
o Active Shielding: The Active Shield detection is filtered using a counter, when that
number reaches a preset threshold, the Active Shield raises a tamper alarm.
o Dual flip-flop and Path-differential signaling: A difference in the state of two joint
flip-flops indicates a fault and raises the Fault Injection Alarm output signal. This
mechanism is designed to detect perturbation attacks like Laser or ElectroMagnetic fault injections.
o State machine monitoring: The TOE implements Tamper Detectors that detects
abnormal conditions and reports a fault state.
SF.PHY-PRO also protects the TOE against the inherent or intentional leak of the TOE
operations by the following security mechanisms:
o advanced stream cipher using long linear feedback shift registers: the calculations
are protected against timing and power consumption leak;
o anti-DPA measures for the hash functions that are used for stream-ciphering and
MAC digest: masking input data and undisclosure of intermediate output values;
o session setup: the logic is protected against timing and power consumption leak;
SF.OPE-MODE
Control of Operating Modes
SF.OPE-MODE ensures that the User Data is not disclosed or manipulated via the features
avalailable in the TEST mode.
PUBLIC
Page 36/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
In particular, the Flash array is completely erased before switching to TEST mode.
Furthermore, the access to User data is also restricted in the Test mode. More precisely:
o The Binding Key (Kb) cannot be read out by the Flash commands;
o The Binding key cannot be erased unless a complete erase has been done after
the last reset;
o The read and write commands do not read and write effective values of the Fash
array;
SF.OPE-COND
Control of Operating Conditions
SF.OPE-COND detects the abnormal operation conditions (voltage, temperature, clock
frequency, power glitch) using the corresponding sensors.
If an abnormal operation condition happens, then SF.OPE-COND disturbs the
cryptographic computations, interrupts data interchange and inform U.Host-Device.
SF.SEC-MEM-INT
Storage Integrity
SF.SEC-MEM-INT protects the integrity of the User Data (including executable codes)
stored in the flash array using CRC-32 error detecting code. All User data can be
protected by CRC-32 error detecting code but the integrity verification is performed only if
the access is done via an authenticated read (i.e. AUTH_READ command).
If an inconsistency is detected between a User data and its error detecting code, then
SF.SEC-MEM-INT informs U.Host-Device about the error.
In addition, SF.SEC-MEM-INT also sends pseudo-randomly chosen of the CRC-32 error
detecting code to U.Host-Device in a secure way so that data integrity can be
independently verified by U.Host-Device.
SF.SEC-MEM-CONF
Storage Confidentiality
SF.SEC-MEM-CONF protects the confidentiality of the User Data stored in the flash array
by a memory scrambling mechanism that is based on diversified keys. Both the addresses
and the memory content are scrambled but by a key that is unique for each instance of
the TOE.
SF.KEY-PRO
Protection of Binding Key
SF.KEY-PRO protects the User data against disclosure by manipulating the binding key. In
particular, the Flash array is completely erased before
o a new Binding key is set, or
o the current Binding key is erased.
Furthermore, the current Binding key is stored in the Auxiliary array and cannot be read
out by the Flash commands. The integrity of the Binding key is protected by a digest
value: if an illegal modifcation is detected on the Binding key, then the TOE is locked and
can only be unlocked in Test mode (and the Flash array has been erased).
PUBLIC
Page 37/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
SF.SEC-AUTH
Secure Authentication
SF.SEC-AUTH ensures that only an authorized Host device (i.e. a Host device that knows
the Binding key Kb) can open a secure channel to communicate with the TOE.
More precisely, SF.SEC-AUTH provides a mutual authentication between the Host device
and the TOE by verifying that both of them share the same Binding key. A failed
authentication increases the Failure counter: if this counter reaches a pre-defined value,
then the TOE is locked.
PUBLIC
Page 38/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
7.2 SFRs and TSS
7.2.1 SFRs and TSS - Rationale
7.2.1.1 TOE Summary Specification
SF.SEC-COM SF.SEC-COM enforces the FDP_UCT.1 and FDP_UIT.1 because the the User
Data is protected while being transmitted to U.Host-Device. SF.SEC-COM enforces the
FDP_IFC.1 in particular the user data is protected in terms of confidentility when being
transferred by the TOE to U.Host-Device. Moreover, the user data is protected in terms
of intergrity during the communication between the TOE and U.Host-Device.
SF.PHY-PRO SF.PHY-PRO enforces the TOE resistance against physical attacks
(FPT_PHP.3). SF.PHY-PRO contributes to the integrity and confidentiality protection of the
User data stored in the TOE (FDP_SDI.2 and FDP_SDC.1): the failure counter is increased
when a data inconsistency is detected; the cryptographic services are also protected
against the physical attacks. SF.PHY-PRO protects against some attacks on the
cryptographic services used for the transmission of the User data (FPT_ITT.1, FDP_ITT.1
and FDP_IFC.1).
SF.OPE-MODE SF.OPE-MODE enforces the restriction of the TSF capabilities and availabily
during the deployment of the test features after the TOE delivery (respectively FMT_LIM.1
and FMT_LIM.2).
SF.OPE-COND SF.OPE-COND enforces the TOE fault-tolerance and fail-secure (respectively
FRU_FLT.2 and FPT_FLS.1/Detectors).
SF.SEC-MEM-INT By definition, SF.SEC-MEM-INT enforces FDP_SDI.2.
SF.SEC-MEM-CONF By definition, SF.SEC-MEM-CONF enforces FDP_SDC.1. SF.SEC-MEMCONF also enforces the FDP_IFC.1 in particular the User data and TSF data are protected
in terms of confidentility when being stored, processed or transferred between two TOE
components (SFF and Flash array).
SF.KEY-PRO SF.KEY-PRO enforces FDP_RIP.1 because it erases the Flash content before a
new Binding key is set or the current Binding key is erased. SF.KEY-PRO also detects the
failure and put the TOE in a secure state (i.e. locked state) due to an illegal modification
of the current Binding key. In other words, SF.BIND-KEY-PRO enforces
FPT_FLS.1/Binding_Key.
SF.SEC-AUTH SF.SEC-AUTH enforces the FTP_TRP.1 because only an authorized U.HostDevice can open a trusted channel with the TOE.
7.2.2 Association tables of SFRs and TSS
Security Functional Requirements
TOE Summary Specification
FRU_FLT.2
SF.OPE-COND
PUBLIC
Page 39/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
Security Functional Requirements
TOE Summary Specification
FPT_FLS.1/Detectors
SF.OPE-COND
FMT_LIM.1
SF.OPE-MODE
FMT_LIM.2
SF.OPE-MODE
FDP_SDC.1
SF.PHY-PRO, SF.SEC-MEM-CONF
FDP_SDI.2
SF.PHY-PRO, SF.SEC-MEM-INT
FPT_PHP.3
SF.PHY-PRO
FDP_ITT.1
SF.PHY-PRO
FPT_ITT.1
SF.PHY-PRO
FDP_IFC.1
SF.SEC-MEM-CONF, SF.SEC-COM, SF.PHY-PRO
FDP_UCT.1
SF.SEC-COM
FDP_UIT.1
SF.SEC-COM
FTP_TRP.1
SF.SEC-AUTH
FPT_FLS.1/Binding_Key
SF.KEY-PRO
FDP_RIP.1
SF.KEY-PRO
Table 12 SFRs and TSS - Coverage
TOE Summary
Specification
Security Functional Requirements
SF.SEC-COM
FDP_IFC.1, FDP_UCT.1, FDP_UIT.1
SF.PHY-PRO
FDP_SDC.1, FDP_SDI.2, FPT_PHP.3, FDP_ITT.1, FPT_ITT.1,
FDP_IFC.1
SF.OPE-MODE
FMT_LIM.1, FMT_LIM.2
SF.OPE-COND
FRU_FLT.2, FPT_FLS.1/Detectors
SF.SEC-MEM-INT
FDP_SDI.2
SF.SEC-MEM-CONF
FDP_SDC.1, FDP_IFC.1
SF.KEY-PRO
FPT_FLS.1/Binding_Key, FDP_RIP.1
SF.SEC-AUTH
FTP_TRP.1
Table 13 TSS and SFRs - Coverage
PUBLIC
Page 40/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
8 Notice
This document has been generated with TL SET version 3.1.1-Full (for CC3). For more
information about the security editor tool of Trusted Labs visit our website at www.trustedlabs.com.
8.1 Revisions
Modification Comment
1.0
First version
1.1
Update following ST v1.13
1.2
Update following ST v1.14
Table 14 History of Modifications
PUBLIC
Page 41/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
9 ANNEX
9.1
Glossary
SFI
Secure Flash Interface is the SPI interface on the Host device (i.e. SPI Master).
SFF
Secure Flash Front-end is the SPI interface on the memory chip (i.e. SPI Slave).
SPI
Serial Peripheral Interface is a synchronous serial data link, a de facto standard, that
operates in full duplex mode.
9.2
Abbreviations
CC
Common Criteria
EAL
Evaluation Assurance Level
IT
Information Technology
PP
Protection Profile
ST
Security Target
TOE
Target of Evaluation
TSC
TSF Scope of Control
PUBLIC
Page 42/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
TSF
TOE Security Functionality
TSFI
TSF Interface
TSP
TOE Security Policy
PUBLIC
Page 43/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
9.3 References
[1] Common Criteria, Part 1: Common Criteria for Information Technology Security
Evaluation, Part 1: Introduction and General Model, Version 3.1, Revision 4, September
2012, CCMB-2012-09-001
[2] Common Criteria, Part 2: Common Criteria for Information Technology Security
Evaluation, Part 2: Security Functional Components, Version 3.1, Revision 4, September
2012, CCMB-2012-09-002
[3] Common Criteria, Part 3: Common Criteria for Information Technology Security
Evaluation, Part 3: Security Assurance Components, Version 3.1, Revision 4, September
2012, CCMB-2012-09-003
[4] Common Methodology for Information Technology Security Evaluation, Evaluation
Methodology, Version 3.1, Revision 4, September 2012, CCMB-2012-09-004
[5] Eurosmart, Security IC Platform with Augmentation Packages, Version 1.0, February
2014, BSI-PP-0084.
[6] Joint Interpretation Library: Application of Attack Potential to Smartcards, January 2013,
Version 2.9
[7] Supporting Document, Mandatory Technical Document: The Application of CC to
Integrated Circuits, March 2009, Version 3.0, Revision 1, CCDB-2009-03-002
[8] Supporting Document Guidance: Smartcard Evaluation, February 2010, Version 2.0,
CCDB-2010-03-001
[9] Supporting Document Guidance Security Architecture requirements (ADV_ARC) for smart
cards and similar devices, April 2012, Version 2.0, CCDB-2012-04-003
[10] Joint Interpretation Library: Application of Attack Potential to Smartcards, January 2013,
Version 2.9
[11] Supporting Document Mandatory Technical Document: Application of Attack Potential to
Smartcards April 2012, Version 2.8, CCDB-2012-04-002
[12] Supporting Document: Composite product evaluation for Smart Cards and similar
devices, April 2012, Version 2.1, CCDB-2012-04-001
[13] Joint Interpretation Library: Minimum Site Security Requirements (For trial use), 2013
[14] ISO/IEC 7816-3. Identification cards — integrated circuit cards. Part 3: Cards with
contacts Electrical interface and transmission protocols.
[15] Winbond Technology Ltd., SpiFlash 1.8V 32M-bit secure serial flash memory with octal
SPI interface, Operational User Guidance, 2014.
[16] Winbond Technology Ltd., SpiFlash 1.8V 32M-bit secure serial flash memory with octal
SPI interface, Preparative Procedure, 2014.
PUBLIC
Page 44/45
Security Target Lite of W75F32W 32M-bit Secure Serial Flash Memory
1.2
Index
A
A.Binding-Process ............................................... 14
A.Secure-Channel ................................................ 14
O.Sec-Binding...................................................... 16
O.Trusted-Path ..................................................... 16
OE.Binding-Process ............................................. 17
OE.Secure-Channel .............................................. 16
R
B
Binding__key__(Kb) ........................................... 12
Runtime__data ..................................................... 12
S
F
FDP_IFC.1 ........................................................... 27
FDP_ITT.1 ........................................................... 26
FDP_RIP.1 ........................................................... 28
FDP_SDC.1 ......................................................... 25
FDP_SDI.2 ........................................................... 25
FDP_UCT.1 ......................................................... 27
FDP_UIT.1........................................................... 27
FMT_LIM.1 ......................................................... 24
FMT_LIM.2 ......................................................... 25
FPT_FLS.1/Binding_Key .................................... 28
FPT_FLS.1/Detectors .......................................... 24
FPT_ITT.1 ........................................................... 26
FPT_PHP.3 .......................................................... 26
FRU_FLT.2 .......................................................... 24
FTP_TRP.1 .......................................................... 28
O
O.Abuse-Func ...................................................... 15
O.Leak-Forced ..................................................... 16
O.Leak-Inherent ................................................... 16
O.Malfunction ...................................................... 15
O.Phys-Manipulation ........................................... 15
O.Phys-Probing .................................................... 15
PUBLIC
SF.KEY-PRO ....................................................... 38
SF.OPE-COND .................................................... 38
SF.OPE-MODE ................................................... 38
SF.PHY-PRO ....................................................... 37
SF.SEC-AUTH .................................................... 39
SF.SEC-COM ...................................................... 37
SF.SEC-MEM-CONF .......................................... 38
SF.SEC-MEM-INT .............................................. 38
T
T.Abuse-Communication ..................................... 13
T.Abuse-Func ...................................................... 13
T.Host-Forging .................................................... 14
T.Leak-Forced ...................................................... 13
T.Leak-Inherent ................................................... 13
T.Malfunction ...................................................... 13
T.Phys-Manipulation ........................................... 13
T.Phys-Probing .................................................... 13
TSF__logic........................................................... 12
U
U.Host-Device ..................................................... 12
User__Data .......................................................... 12
Page 45/45
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement