Huawei BaseBIOS Security Target
Huawei Technologies Co., Ltd
All rights reserved
Huawei BaseBIOS Security Target
2020-10-06 2/26
No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Huawei Technologies Co., Ltd.
Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People’s Republic of China
Website: http://www.huawei.com
Huawei BaseBIOS Security Target
2020-10-06 3/26
Change History
Date Version Description
2020-04-15 1.0 Initial version
2020-06-16 1.1 Change version number
2020-07-09 1.2 Clarify the intended device type and correct table numbers
2020-07-15 1.3 Removal of FCS_COP.1 instances.
Correction on CC claims.
Editorial changes.
2020-07-28 1.4 Add descriptions about debug function
2020-09-04 1.5 Correction on version references, delivery format, CC claims
2020-10-06 1.6 Correction on required non-TOE parts, logical scope
Huawei BaseBIOS Security Target
2020-10-06 4/26
Content
Huawei BaseBIOS Security Target ........................................................................................1
1 Introduction.......................................................................................................................8
1.1 ST Reference and TOE Reference...........................................................................................8
1.1.1 ST Reference .....................................................................................................................................8
1.1.2 TOE Reference ..................................................................................................................................8
1.2 TOE Overview.........................................................................................................................8
1.2.1 TOE Type ..........................................................................................................................................8
1.2.2 TOE Usage and Major Security Features ..........................................................................................8
1.2.3 Required non-TOE hardware/software/firmware ..............................................................................9
1.3 TOE Description....................................................................................................................10
1.3.1 Physical Scope of TOE....................................................................................................................10
1.3.2 Logical Scope of TOE .....................................................................................................................10
1.3.3 TOE Life Cycle................................................................................................................................10
2 Conformance Claims ......................................................................................................12
2.1 CC Conformance Claim ........................................................................................................12
2.2 PP Conformance Claim .........................................................................................................12
2.3 Conformance Claim Rationale...............................................................................................12
3 Security Problem Definition...........................................................................................13
3.1 Assets.....................................................................................................................................13
3.2 Threats ...................................................................................................................................13
3.3 Assumptions ..........................................................................................................................13
4 Security Objectives .........................................................................................................15
4.1 Security Objectives for the TOE............................................................................................15
4.2 Security Objectives for the Operational Environment...........................................................15
4.3 Security Objective Rationale .................................................................................................16
4.3.1 Overview .........................................................................................................................................16
4.3.2 Threats .............................................................................................................................................17
4.3.3 Assumptions ....................................................................................................................................18
5 Extended Components Definition..................................................................................19
5.1 Definition of the Family FMT_LIM......................................................................................19
6 Security Requirements ...................................................................................................21
6.1 Statement of Security Requirements......................................................................................21
Huawei BaseBIOS Security Target
2020-10-06 5/26
6.1.1 Notation ...........................................................................................................................................21
6.1.2 Security Functional Requirements...................................................................................................21
6.1.3 Security Assurance Requirements ...................................................................................................22
6.2 Security Requirements Rationale...........................................................................................22
6.2.1 Security Functional Requirements...................................................................................................22
6.2.2 Security Assurance Requirements ...................................................................................................23
7 TOE summary specification...........................................................................................25
7.1 SF.Boot..................................................................................................................................25
7.1 SF.Debug ...............................................................................................................................25
8 Bibliography....................................................................................................................26
8.1 Evaluation Documents...........................................................................................................26
8.2 Developer Documents ...........................................................................................................26
8.3 Other Documents...................................................................................................................26
Huawei BaseBIOS Security Target
2020-10-06 6/26
List of tables
Table 1 Components of the TOE scope ................................................................................................10
Table 2 Actors in the TOE Life Cycle ..................................................................................................10
Table 3 Tracing from Security Objectives to Threats and Assumption................................................17
Table 4 Security Functional Requirements dependencies.....................................................................22
Table 5 Tracing from Security Functional Requirements to Security Objectives ................................23
Table 6 Security Assurance Requirements dependencies for augmentations.......................................23
Huawei BaseBIOS Security Target
2020-10-06 7/26
Abbreviations
Abbreviation Full Name Description
BSBC Boot-rom Secure Boot Code The chiprom boot code.
ST Security Target
TOE Target Of Evaluation
SP Secure Partition Secure Partition
eFUSE Electrically Programmable Fuse
SEC Secure Engine for Symmetric
Algorithm
Hardware accelerator for AES Algorithm
CER Certification Engine for
asymmetric algorithm
Hardware accelerator for SHA Algorithm and RSA
Algorithm
KM Key management
AES Advanced Encryption Standard The symetric key cryptography algorithm
RSA Rivest Shamir Adleman The public key cryptography algorithm invented by
Rivest、Shamir and Adleman.
Huawei BaseBIOS Security Target
2020-10-06 8/26
1 Introduction
This introduction chapter contains the following sections:
1.1 ST Reference and TOE Reference
1.2 TOE Overview
1.3 TOE Description
1.1 ST Reference and TOE Reference
1.1.1 ST Reference
Title: Huawei BaseBIOS Security Target
Author: Huawei Hardware Trusted Technology and Engineering Lab
Version: 1.6
CC Version: Version 3.1, Revision 5
Assurance Level: EAL4+
ITSEF: Brightsight
Certification Body: Netherlands Scheme for Certification in the Area of IT Security (NSCIB)
1.1.2 TOE Reference
Name: BaseBIOS
Developers: Huawei Hardware Trusted Technology and Engineering Lab
Version: 1.5
1.2 TOE Overview
1.2.1 TOE Type
The TOE is BaseBIOS which is a secure bootloader, it is the second piece of software codes that is used in
the start-up process of a secure embedded hardware product, such as an integrated secure element or SoC,
to ensure the product securely initializes into a secure state.
1.2.2 TOE Usage and Major Security Features
The TOE is used by integrating it into a software stack running on a compatible hardware platform. As part
of the initialization procedure of this hardware and software stack, the TOE will be used to ensure that the
higher layers of software are securely loaded.
In order to support this, the TOE provides the following security features:
Huawei BaseBIOS Security Target
2020-10-06 9/26
 Boot failure handling
 Sensitive data handling
 Debug functionality (for software development)
1.2.3 Required non-TOE hardware/software/firmware
The TOE requires a hardware platform including firmware that provides the following functionality:
 One-time programmable memory
 Cryptographic operations for software image decryption and signature verification
Additionally, the TOE requires a target software image for loading, encrypted and signed using the
appropriate cryptographic schemes.
The TOE is located in Secure Partition (SP), which ensures the different layers of software are securely
loaded. The TOE is only a piece of secure bootloader code and stored in SRAM of SP. Initially, the
encrypted TOE is stored in the Flash, which is an external component that is not part of the same hardware
that contains the SP. The first stage bootloader, which is stored in the ROM of SP, decrypts and
authenticates the TOE and stores it in SRAM, where it will run. The TOE also relies on the External cache,
which is not part of the SP, but is still part of the same hardware that contains the SP (whereas the Flash is
not). Figure 1 shows the TOE in its operational environment. The following summarises the role of the
various components:
 External Cache and SRAM are used by the TOE as volatile memory.
 KM and SEC are used for image decryption.
 CER is used for image authentication (signature verification).
 eFUSE is used as one-time programmable memory.
 CPU executing the TOE.
For more details, see Section 4.2.
eFUSE
CER KM
CPU ROM External Cache
Secure Partition (SP)
SRAM
SEC
Flash
Figure 1 TOE and Operational Environment
Huawei BaseBIOS Security Target
2020-10-06 10/26
1.3 TOE Description
1.3.1 Physical Scope of TOE
The TOE consists of the following components:
Table 1 Components of the TOE scope
Type Component Version Format Delivery method
Software Huawei BaseBIOS V1.5 Binary(.bin) Encrypted file
exchange
Guidance
document
Huawei BaseBIOS CC EAL4+
Guidance Document
V1.3 Document (.pdf) Encrypted file
exchange
1.3.2 Logical Scope of TOE
The logical scope of the TOE consists of the following security features:
 SF.Boot,
which implements the boot process, including:
o the handling of hardware initialization failure and software authentication failure, and
o the clearing of sensitive data, for both a successful and unsuccessful boot.
 SF.Debug
o which implements mechanisms to disable the debug functionality after software development is
completed.
1.3.3 TOE Life Cycle
The life cycle of the TOE is divided into the following three phases:
 Phase 1 corresponds to the design of the TOE
 Phase 2 corresponds to the develop and the test of the TOE
 Phase 3 corresponds to the delivery of the TOE
Table 2 shows the whole life cycle of the TOE.
Table 2 Actors in the TOE Life Cycle
Phase Actors
1：the design of the TOE The TOE developer：design the architecture of the TOE
2：
the develop and the test of
the TOE
The TOE developer: develop and test of the TOE
Huawei BaseBIOS Security Target
2020-10-06 11/26
3：the delivery of the TOE The TOE developer: write the usage guidelines documents，
encrypt and
package the TOE
Huawei BaseBIOS Security Target
2020-10-06 12/26
2 Conformance Claims
This chapter is divided into the following sections:
2.1 CC Conformance Claim
2.2 PP Conformance Claim
2.3 Conformance Claim Rationale
2.1 CC Conformance Claim
This Security Target conforms to CC Part 2 extended and Part 3 conformant, with a claimed Evaluation
Assurance Level of EAL 4, augmented by ALC_DVS.2 and AVA_VAN.5.
This Security Target claims conformance to the following specifications：
 Common Criteria for Information Technology Security Evaluation, Part 2: Security Function
Requirements; Version 3.1, Revision 5, April 2017
 Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance
Requirements; Version 3.1, Revision 5, April 2017
2.2 PP Conformance Claim
This Security Target does not claim conformance to any PP.
2.3 Conformance Claim Rationale
This is not applicable as this Security Target, because it does not claim conformance to any PP.
Huawei BaseBIOS Security Target
2020-10-06 13/26
3 Security Problem Definition
This Security Target claims conformance to the CC version 3.1 revision 5. Assets, threats, assumptions and
organizational security policies are taken from CC. This chapter lists these assets, threats, assumptions and
organizational security policies, and describes extensions to these elements in detail.
3.1 Assets
The assets of the TOE are divided into the following:
 The user software to be loaded, which is stored in external NVM.
 User cryptographic keys, which are stored in OTP or derived from such keys.
3.2 Threats
The threats of the TOE are divided into the following:
T.Software-Confidentiality
An unauthorized external entity discloses the user software to be loaded through logical means, including
but not limited to abuse of debug functionality.
T.Software-Integrity
An unauthorized external entity loads unauthentic software through logical means, including but not
limited to changing the user software while stored in external NVM and/or abuse of debug functionality.
T.Key-Confidentiality
An unauthorized external entity discloses the user cryptographic keys (or keys that are derived from such
keys) through logical means, including but not limited to abuse of debug functionality.
3.3 Assumptions
This section states the assumptions that hold on the TOE operational environment. These assumptions have
to be satisfied.
A.Environment-Protection
It is assumed that the TOE is integrated into a hardware environment that protects against the following
attacks:
 Physical attacks, such as probing or physical manipulation.
 Malfunction attacks, where environmental stress is applied to cause a malfunction.
 Side-channel attacks, where sensitive information leaks as a result of leakage.
A.Hardware-Support
It is assumed that the TOE is integrated into a hardware environment that provides (at a minimum) the
Huawei BaseBIOS Security Target
2020-10-06 14/26
following functionality:
 One-Time Programmable (OTP) memory.
 Cryptographic functionality, which includes
o RSASSA-PKCS1-v1_5 and RSASSA-PSS as defined by [PKCS#1] with key sizes 2048 and
4096 bits,
o AES-GCM as defined by [SP800-38D] with key size 256 bits,
o SHA-256 as defined by [FIPS180-4],
o HMAC-SHA-256 as defined by [FIPS198-1], and
o PBKDF2 as defined by [SP800-132].
A.Process-Security
It is assumed that security procedures are used after delivery of the TOE by the TOE Manufacturer up to
delivery to the end-consumer to maintain confidentiality and integrity of the TOE and of its manufacturing
and test data (to prevent any possible copy, modification, retention, theft or unauthorised use).
A.Process-User-Data
All data that is considered user data from the point of view of this TOE needs to be treated according to its
security needs by the user when handled outside of the TOE. Specifically, the user software to be loaded is
assumed to be stored in the external NVM in a way that preserves its confidentiality and supports the
authentication of the user software by TOE. Additionally, the user keys are assumed to be handled securely
when outside of the control of the TOE.
Huawei BaseBIOS Security Target
2020-10-06 15/26
4 Security Objectives
This chapter contains the following sections:
4.1 Security Objectives for the TOE
4.2 Security Objectives for the Operational Environment
4.3 Security Objective Rationale
4.1 Security Objectives for the TOE
The TOE shall provide the following security objectives:
O.Authentication
The TOE shall authenticate the user software (with the support of the hardware platform as described in
the following section). In case any failure occurs during the authentication of the loaded user data, the TOE
shall preserve a secure state.
O.Data
The TOE shall restrict the access to sensitive data and keys by clearing it from memory, both when the
user data is loaded correctly and when a failure occurs.
O.Abuse-Debug
The TOE shall implement functionality for a user to limit the use of debug functionality, to prevent its use
to disclose or manipulate sensitive data in the operational environment of the Composite TOE.
4.2 Security Objectives for the Operational Environment
The following security objectives for the operational environment are specified according to the CC.
OE.Environmental-Protection
The hardware environment that the TOE is integrated into shall protect against the following attacks:
 Physical attacks, such as probing or physical manipulation
 Malfunctions, caused by deliberate environmental stress applied by an attacker
 Side-channel attacks, where sensitive information leaks through operational parameters
OE.Hardware-Support
The hardware environment that the TOE is integrated into shall provide (at a minimum) the following
functionality:
 One-Time Programmable (OTP) memory.
 Cryptographic functionality, which includes
o RSASSA-PKCS1-v1_5 and RSASSA-PSS as defined by [PKCS#1] with key sizes 2048 and
Huawei BaseBIOS Security Target
2020-10-06 16/26
4096 bits,
o AES-GCM as defined by [SP800-38D] with key size 256 bits,
o SHA-256 as defined by [FIPS180-4],
o HMAC-SHA-256 as defined by [FIPS198-1], and
o PBKDF2 as defined by [SP800-132].
OE.Process-Security
Security procedures shall be used after TOE Delivery up to delivery to the end-consumer to maintain
confidentiality and integrity of the TOE and of its manufacturing and test data (to prevent any possible
copy, modification, retention, theft or unauthorised use).
OE.Process-User-Data
All data that is considered user data from the point of view of this TOE shall be treated according to its
security needs by the user when handled outside of the TOE. Specifically, the user software to be loaded
shall be stored in the external NVM encrypted using AES-256-GCM (as defined by [SP800-38D]) and
shall be stored together with a digital signature according to RSASSA-PSS or RSA-PKCS1-v1_5 (as
defined by [PKCS#1]) with key size 2048 or 4096 bits and hash function SHA-256 (as defined by
[FIPS180-4]). Additionally, the user keys shall be handled securely when outside of the control of the
TOE.
4.3 Security Objective Rationale
4.3.1 Overview
Table 3 shows an overview of the tracing from objectives to Threats and Assumptions. In the subsequent
sections this tracing is explained in more detail.
Huawei BaseBIOS Security Target
2020-10-06 17/26
Table 3 Tracing from Security Objectives to Threats and Assumption
Security Objectives
Security Problem Definition
O.Authentication
O.Data
O.Abuse-Debug
OE.Environmental-Protection
OE.Hardware-Support
OE.Process-Security
OE.Process-User-Data
T.Software-Confidentiality √ √ √ √
T.Software-Integrity √ √ √
T.Key-Confidentiality √ √ √
A.Environmental-Protection √
A.Hardware-Support √
A.Process-Security √
A.Process-User-Data √
4.3.2 Threats
The threat T.Software-Confidentiality is countered by the authentication process (O.Authentication),
which is supported by cryptographic functionality from the hardware (OE.Hardware-Support).
Specifically, this process includes decryption of the user software that is stored in encrypted form in
external NVM. Additionally, the TOE clears all sensitive data and keys that have been stored in memory
during the authentication process before this memory is released to other processes (O.Data). Finally, the
TOE prevents an attacker from using debug functionality to disclose such data (O.Abuse-Debug), relying
on the OTP memory provided by the hardware (OE.Hardware-Support).
The threat T.Software-Integrity is countered by the authentication process (O.Authentication), which is
supported by cryptographic functionality from the hardware (OE.Hardware-Support). Specifically, this
process includes verification of the digital signature that is stored together with the user software in
external NVM. Additionally, the TOE prevents an attacker from using debug functionality to manipulate
such data (O.Abuse-Debug), relying on the OTP memory provided by the hardware
(OE.Hardware-Support).
Huawei BaseBIOS Security Target
2020-10-06 18/26
The threat T.Key-Confidentiality is countered by the fact that the TOE clears all sensitive data and keys
that have been stored in memory during the authentication process before this memory is released to other
processes (O.Data). Additionally, the TOE prevents an attacker from using debug functionality to disclose
such data (O.Abuse-Debug), relying on the OTP memory provided by the hardware
(OE.Hardware-Support).
4.3.3 Assumptions
The assumption A.Environmental-Protection is directly met by its corresponding objective for the
environment OE.Environmental-Protection.
The assumption A.Hardware-Support is directly met by its corresponding objective for the environment
OE.Hardware-Support.
The assumption A.Process-Security is directly met by its corresponding objective for the environment
OE.Process-Security.
The assumption A.Process-User-Data is directly met by its corresponding objective for the environment
OE.Process-User-Data.
Huawei BaseBIOS Security Target
2020-10-06 19/26
5 Extended Components Definition
5.1 Definition of the Family FMT_LIM
To define the IT security functional requirements of the TOE an additional family (FMT_LIM) of the
Class FMT (Security Management) is defined here, identical to its definition in PP0084. 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 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
There are no actions defined to be auditable.
The TOE Functional Requirement “Limited capabilities (FMT_LIM.1)” is specified as follows.
FMT_LIM.1 Limited capabilities
Hierarchical to: No other components.
Huawei BaseBIOS Security Target
2020-10-06 20/26
Dependencies: FMT_LIM.2 Limited availability.
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 TOE Functional Requirement “Limited availability (FMT_LIM.2)” is specified as follows.
FMT_LIM.2 Limited availability
Hierarchical to: No other components.
Dependencies: FMT_LIM.1 Limited capabilities.
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].
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
(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.
Huawei BaseBIOS Security Target
2020-10-06 21/26
6 Security Requirements
This part of the Security Target defines the detailed security requirements that shall be satisfied by the
TOE. The statement of TOE security requirements shall define the functional and assurance security
requirements that the TOE needs to satisfy in order to meet the security objectives for the TOE. This
chapter contains the following sections:
6.1 Statement of Security Requirements
6.2 Security Requirements Rationale
6.1 Statement of Security Requirements
6.1.1 Notation
The CC allows several operations to be performed on security requirements (on the component level).
Refinement, selection, assignment and iteration are defined in paragraph 8.1 of Part 1 of the CC.
The assignment operation and the selection operation are used in this Security Target, Neither the iteration
operation nor the refinement operation has been performed.
The assignment operation is used to assign a specific value to an unspecified parameter, such as the length
of a password. Assignments having been made are denoted by showing as italic text.
The selection operation is used to select one or more options provided by the CC in stating a requirement.
Selections having been made are denoted as italic text.
6.1.2 Security Functional Requirements
The security functional requirements are as follows:
FPT_FLS.1 Failure with preservation of secure state
FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of failures occur:
 Failure to initialise the hardware
 Failure to authenticate the loaded software
 An exception occurs
FDP_RIP.1 Subset residual information protection
FDP_RIP.1.1 The TSF shall ensure that any previous information content of a resource is made
unavailable upon the deallocation of the resource from the following objects: all keys
and sensitive data stored in SRAM.
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 Deploying Debug Features after Composite TOE Delivery does not allow
Huawei BaseBIOS Security Target
2020-10-06 22/26
user data of the Composite TOE to be disclosed or manipulated, TSF data to be
disclosed or manipulated, software to be reconstructed and no substantial information
about construction of TSF to be gathered which may enable other attacks.
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 Deploying
Debug Features after Composite TOE Delivery does not allow user data of the
Composite TOE to be disclosed or manipulated, TSF data to be disclosed or
manipulated, software to be reconstructed and no substantial information about
construction of TSF to be gathered which may enable other attacks.
6.1.3 Security Assurance Requirements
The claimed Security Assurance Requirements are given by the package claim in Section 2.1, and the
corresponding SARs are included here by reference to Part 3.
6.2 Security Requirements Rationale
6.2.1 Security Functional Requirements
6.2.1.1 Dependencies
Table 4 shows the dependencies of the Security Functional requirements, whether they are met, and, if not,
the justification.
Table 4 Security Functional Requirements dependencies
SFR Dependencies Met by Justification
FPT_FLS.1 - - N/A
FDP_RIP.1 - - N/A
FMT_LIM.1 FMT_LIM.2 FMT_LIM.2 N/A
FMT_LIM.2 FMT_LIM.1 FMT_LIM.1 N/A
6.2.1.2 Tracing
Table 5 shows an overview of the tracing from SFRs to the Security Objectives. The details are provided in
the following.
Huawei BaseBIOS Security Target
2020-10-06 23/26
Table 5 Tracing from Security Functional Requirements to Security Objectives
Security Functional Requirements
Security Objectives
FPT_FLS.1
FDP_RIP.1
FMT_LIM.1
FMT_LIM.2
O.Authentication √
O.Data √ √
O.Abuse-Debug √ √
The Security Objective O.Authentication is that the TOE shall authenticate the user software with the
support of the hardware. To this end, it needs to preserve a secure state in case of failures, which is directly
met by the requirement FPT_FLS.1.
The Security Objective O.Data is that the TOE shall clear sensitive data from memory when it is no longer
used, which is directly met by the requirement FDP_RIP.1, and in case of a failure, which is directly met
by the requirement FPT_FLS.1.
The Security Objective O.Abuse-Debug is that the TOE shall implement a way for a user to limit the
debug functionality such that it cannot be used by an attacker in the operational environment of the TOE to
disclose or manipulate sensitive data. This is directly met by the combination of the requirements that this
debug functionality is either not useful to an attacker, as per FMT_LIM.1, or is made unavailable to an
attacker, as per FMT_LIM.2.
6.2.2 Security Assurance Requirements
6.2.2.1 Dependencies
The dependencies of the claimed package are internally consistent. Additionally, Table 6 shows that the
dependencies for the augmentations are met as well.
Table 6 Security Assurance Requirements dependencies for augmentations
SFR Dependencies Met by Justification
AVA_VAN.5
ADV_ARC.1 ADV_ARC.1 Part of EAL4
ADV_FSP.4 ADV_FSP.4 Part of EAL4
ADV_TDS.3 ADV_TDS.3 Part of EAL4
ADV_IMP.1 ADV_IMP.1 Part of EAL4
Huawei BaseBIOS Security Target
2020-10-06 24/26
AGD_OPE.1 AGD_OPE.1 Part of EAL4
AGD_PRE.1 AGD_PRE.1 Part of EAL4
ALC_DVS.2 - - N/A
6.2.2.2 Justification
An assurance level of EAL4 with the augmentations AVA_VAN.5 and ALC_DVS.2 are required for this
TOE since it is intended to defend against sophisticated attacks. Maximum assurance can be gained 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 will
have access to the low level design and source code.
Huawei BaseBIOS Security Target
2020-10-06 25/26
7 TOE summary specification
This chapter provides information to potential users of the TOE how the TOE satisfies the Security
Functional Requirements.
7.1 SF.Boot
SF.Boot implements the boot process, including the handling of hardware initialization failure, software
authentication failure, and any other unrecoverable exception. In case such a failure occurs, SF.Boot
ensures that a secure state is maintained by
 Aborting the boot process
 Clearing any sensitive data
In case such failures do not occur, SF.Boot nevertheless clears any sensitive data, and finally cedes control
to the authenticated user software. Therefore, SF.Boot ensures that the TOE meets FPT_FLS.1 and
FDP_RIP.1.
7.2 SF.Debug
SF.Debug, which implements mechanisms to completely disable the debug functionality after software
development is completed. These mechanisms ensure that an exception is generated in case a debug access
is attempted after the debug functionality has been disabled, resulting in a boot failure. This means that an
attacker can use the debug functionality to compromise user assets, and as such SF.Debug ensures that the
TOE meets FMT_LIM.1 and FMT_LIM.2.
Huawei BaseBIOS Security Target
2020-10-06 26/26
8 Bibliography
8.1 Evaluation Documents
[1] Common Criteria for Information Technology Security Evaluation Part 1: Introduction and general
model, Version 3.1, Revision 5, April 2017
[2] Common Criteria for Information Technology Security Evaluation Part 2: Security functional
components, Version 3.1, Revision 5, April 2017
[3] Common Criteria for Information Technology Security Evaluation Part 3: Security assurance
components, Version 3.1, Revision 5, April 2017
[4] Common Methodology for Information Technology Security Evaluation: Evaluation Methodology,
Version 3.1, Revision 5, April 2017
8.2 Developer Documents
[5] Huawei BaseBIOS CC EAL4+ Guidance Document
8.3 Other Documents
[6] [FIPS180-4], FIPS Publication 180-4, Secure Hash Standard (SHS), Federal Information Processing
Standards, August 2015
[7] [FIPS198-1], FIPS Publication 198-1, The Keyed-Hash Message Authentication Code (HMAC),
Federal Information Processing Standards, July 2008
[8] [PKCS#1], PKCS #1 v2.2: RSA Cryptography Standard, RSA Laboratories, October 27, 2012
[9] [SP800-38D], NIST Special Publication 800-38D, Recommendations for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC, National Institute of Standards and Technology,
November 2007
[10] [SP800-132], NIST Special Publication 800-132, Recommendations for Password-Based Key
Derivation: Part 1: Storage Applications, December 2010