Huawei A800 Series Routers
Security Target
Issue V1.4
Date 2023-06-08
HUAWEI TECHNOLOGIES CO., LTD.
Security Target of Huawei A800 Series Routers
Change History
Changes between document issues are cumulative. The latest document issue contains all
the changes made in earlier issues.
Date Version Change Description Author
2022-11-26 1.0 Initial Draft xiaxin
2022-12-26 1.1 External review completed. xiaxin
2023-1-6 1.2 External review completed. xiaxin
2023-04-13 1.3 External review completed. Huang Qiang
2023-06-08 1.4 External review completed. Chen Peng
Security Target of Huawei A800 Series Routers Contents
Contents
1 Introduction ...................................................................................................................................1
1.1 ST reference and TOE Reference .................................................................................................................................1
1.2 TOE overview...............................................................................................................................................................1
1.2.1 TOE usage..................................................................................................................................................................2
1.2.2 TOE type....................................................................................................................................................................2
The TOE type is a network device that is connected to the network and has an infrastructure role within the network. .2
1.2.3 Non TOE Hardware and Software .............................................................................................................................2
1.3 TOE description............................................................................................................................................................3
1.4 Physical scope...............................................................................................................................................................3
1.5 Logical Scope of the TOE.............................................................................................................................................5
1.6 Standalone TOE............................................................................................................................................................6
2 PP conformance claims ................................................................................................................7
2.1 CC Conformance Claim................................................................................................................................................7
2.2 Protection Profile Conformance ...................................................................................................................................7
2.3 Conformance Rationale ................................................................................................................................................8
2.3.1 TOE Appropriateness.................................................................................................................................................8
2.3.2 TOE Security Problem Definition Consistency .........................................................................................................8
2.3.3 Statement of Security Objectives Consistency ..........................................................................................................8
2.3.4 Statement of Security Requirements Consistency .....................................................................................................8
3 Security Problem Definition .......................................................................................................9
3.1 Assets............................................................................................................................................................................9
3.2 Threats ........................................................................................................................................................................10
3.2.1 T.UNAUTHORIZED_ADMINISTRATOR_ACCESS ........................................................................................... 10
3.2.2 T.WEAK_CRYPTOGRAPHY ................................................................................................................................ 10
3.2.3 T.UNTRUSTED_COMMUNICATION_CHANNELS ........................................................................................... 11
3.2.4 T.WEAK_AUTHENTICATION_ENDPOINTS...................................................................................................... 11
3.2.5 T.UPDATE_COMPROMISE................................................................................................................................... 11
3.2.6 T.UNDETECTED_ACTIVITY............................................................................................................................... 12
3.2.7 T.SECURITY_FUNCTIONALITY_COMPROMISE ............................................................................................ 12
3.2.8 T.PASSWORD_CRACKING ..................................................................................................................................12
3.2.9 T.SECURITY_FUNCTIONALITY_FAILURE ......................................................................................................13
Security Target of Huawei A800 Series Routers Contents
3.3 Assumptions................................................................................................................................................................ 13
3.3.1 A.PHYSICAL_PROTECTION ............................................................................................................................... 13
3.3.2 A.LIMITED_FUNCTIONALITY ........................................................................................................................... 13
3.3.3 A.NO_THRU_TRAFFIC_PROTECTION..............................................................................................................13
3.3.4 A.TRUSTED_ADMINISTRATOR ......................................................................................................................... 14
3.3.5 A.REGULAR_UPDATES .......................................................................................................................................14
3.3.6 A.ADMIN_CREDENTIALS_SECURE..................................................................................................................14
3.3.7 A.RESIDUAL_INFORMATION............................................................................................................................. 14
3.4 Organizational Security Policies.................................................................................................................................14
3.4.1 P.ACCESS_BANNER.............................................................................................................................................14
4 Security Objectives......................................................................................................................16
4.1 Security Objectives for the Operational Environment ................................................................................................ 16
4.1.1 OE.PHYSICAL .......................................................................................................................................................16
4.1.2 OE.NO_GENERAL_PURPOSE ............................................................................................................................. 16
4.1.3 OE.NO_THRU_TRAFFIC_PROTECTION ...........................................................................................................16
4.1.4 OE.TRUSTED_ADMIN..........................................................................................................................................16
4.1.5 OE.UPDATES ......................................................................................................................................................... 16
4.1.6 OE.ADMIN_CREDENTIALS_SECURE ...............................................................................................................17
4.1.7 OE.RESIDUAL_INFORMATION.......................................................................................................................... 17
5 Extended Components Definition ............................................................................................18
6 Security Functional Requirements ..........................................................................................19
6.1 Functional Security Requirements.............................................................................................................................. 20
6.1.1 Security Audit (FAU)...............................................................................................................................................20
6.1.1.1 FAU_GEN.1 Audit data generation ......................................................................................................................20
6.1.1.2 FAU_GEN.2 User identity association .................................................................................................................22
6.1.1.3 FAU_STG_EXT.1 Protected Audit Event Storage ............................................................................................... 22
6.1.1.4 FAU_STG_EXT.3/LocSpace Action in case of possible audit data loss .............................................................. 23
6.1.1.5 FAU_STG.1 Protected audit trail storage .............................................................................................................23
6.1.2 Cryptographic Support (FCS)..................................................................................................................................23
6.1.2.1 FCS_CKM.1 Cryptographic Key Generation (Refinement).................................................................................23
6.1.2.2 FCS_CKM.2 Cryptographic Key Establishment (Refinement) ............................................................................23
6.1.2.3 FCS_CKM.4 Cryptographic Key Destruction ......................................................................................................23
6.1.2.4 FCS_COP.1/DataEncryption Cryptographic Operation (AES Data Encryption/ Decryption).............................. 24
6.1.2.5 FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and Verification) .....................................24
6.1.2.6 FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm)............................................................................24
6.1.2.7 FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm) ......................................................24
6.1.2.8 FCS_RBG_EXT.1 Random Bit Generation..........................................................................................................25
6.1.2.9 FCS_SSHC_EXT.1 SSH Client Protocol .............................................................................................................25
6.1.2.10 FCS_SSHS_EXT.1 SSH Server Protocol ...........................................................................................................25
6.1.2.11 FCS_TLSC_EXT.1 TLS Client Protocol............................................................................................................26
Security Target of Huawei A800 Series Routers Contents
6.1.3 Identification and Authentication (FIA)...................................................................................................................26
6.1.3.1 FIA_AFL.1 Authentication Failure Management (Refinement)...........................................................................26
6.1.3.2 FIA_PMG_EXT.1 Password Management...........................................................................................................27
6.1.3.3 FIA_UIA_EXT.1 User Identification and Authentication ....................................................................................27
6.1.3.4 FIA_UAU_EXT.2 Password-based Authentication Mechanism ..........................................................................27
6.1.3.5 FIA_UAU.7 Protected Authentication Feedback..................................................................................................27
6.1.3.6 FIA_X509_EXT.1/Rev X.509 Certificate Validation ........................................................................................... 27
6.1.3.7 FIA_X509_EXT.2 X.509 Certificate Authentication............................................................................................ 28
6.1.4 Security Management (FMT) ..................................................................................................................................28
6.1.4.1 FMT_MOF.1/ManualUpdate Management of security functions behaviour........................................................28
6.1.4.2 FMT_MOF.1/Functions Management of security functions behaviour................................................................ 28
6.1.4.3 FMT_MOF.1/Services Management of security functions behaviour ..................................................................28
6.1.4.4 FMT_MTD.1/CoreData Management of TSF Data.............................................................................................. 28
6.1.4.5 FMT_MTD.1/CryptoKeys Management of TSF data........................................................................................... 28
6.1.4.6 FMT_SMF.1 Specification of Management Functions......................................................................................... 28
6.1.4.7 FMT_SMR.2 Restrictions on security roles .........................................................................................................29
6.1.5 Protection of the TSF (FPT) ....................................................................................................................................29
6.1.5.1 FPT_SKP_EXT.1 Protection of TSF Data (for reading of all pre-shared, symmetric and private keys)..............29
6.1.5.2 FPT_APW_EXT.1 Protection of Administrator Passwords..................................................................................29
6.1.5.3 FPT_TST_EXT.1 TSF Testing (Extended)...........................................................................................................30
6.1.5.4 FPT_TUD_EXT.1 Trusted Update .......................................................................................................................30
6.1.5.5 FPT_STM_EXT.1 Reliable Time Stamps.............................................................................................................30
6.1.6 TOE Access (FTA)...................................................................................................................................................30
6.1.6.1 FTA_SSL_EXT.1 TSF-initiated Session Locking ................................................................................................ 30
6.1.6.2 FTA_SSL.3 TSF-initiated Termination (Refinement)........................................................................................... 30
6.1.6.3 FTA_SSL.4 User-initiated Termination (Refinement).......................................................................................... 30
6.1.6.4 FTA_TAB.1 Default TOE Access Banners (Refinement).....................................................................................30
6.1.7 Trusted path/channels (FTP)....................................................................................................................................31
6.1.7.1 FTP_ITC.1 Inter-TSF Trusted Channel (Refinement) .......................................................................................... 31
6.1.7.2 FTP_TRP.1/Admin Trusted Path (Refinement) ....................................................................................................31
6.2 Assurance Security Requirements............................................................................................................................... 31
6.3 SFR Rationale............................................................................................................................................................. 32
7 TOE Summary Specification ......................................................................................................35
7.1 Security Audit (FAU)..................................................................................................................................................35
7.1.1 FAU_GEN.1 Audit data generation......................................................................................................................... 35
7.1.2 FAU_GEN.2 User identity association ....................................................................................................................35
7.1.3 FAU_STG.1 Protected audit trail storage ................................................................................................................36
7.1.4 FAU_STG_EXT.1 Protected audit event storage.....................................................................................................36
7.1.5 FAU_STG_EXT.3/LocSpace Action in case of possible audit data loss .............................................................. 36
7.2 Cryptographic Support (FCS).....................................................................................................................................37
7.2.1 FCS_CKM.1 Cryptographic Key Generation..........................................................................................................37
Security Target of Huawei A800 Series Routers Contents
7.2.2 FCS_CKM.2 Cryptographic Key Establishment .....................................................................................................37
7.2.3 FCS_CKM.4 Cryptographic Key Destruction.........................................................................................................38
7.2.4 FCS_COP.1/DataEncryption Cryptographic Operation (AES Data Encryption/ Decryption).................................39
7.2.5 FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and Verification) ........................................39
7.2.6 FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm)...............................................................................40
7.2.7 FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm) ......................................................... 40
7.2.8 FCS_RBG_EXT.1 Random Bit Generation.............................................................................................................40
7.2.9 FCS_SSHC_EXT.1 SSH Client Protocol ................................................................................................................41
7.2.9.1 FCS_SSHC_EXT.1.1............................................................................................................................................41
7.2.9.2 FCS_SSHC_EXT.1.2............................................................................................................................................41
7.2.9.3 FCS_SSHC_EXT.1.3............................................................................................................................................41
7.2.9.4 FCS_SSHC_EXT.1.4............................................................................................................................................41
7.2.9.5 FCS_SSHC_EXT.1.5............................................................................................................................................42
7.2.9.6 FCS_SSHC_EXT.1.6............................................................................................................................................42
7.2.9.7 FCS_SSHC_EXT.1.7............................................................................................................................................42
7.2.9.8 FCS_SSHC_EXT.1.8............................................................................................................................................42
7.2.9.9 FCS_SSHC_EXT.1.9............................................................................................................................................42
7.2.10 FCS_SSHS_EXT.1 SSH Server Protocol ..............................................................................................................43
7.2.10.1 FCS_SSHS_EXT.1.1 ..........................................................................................................................................43
7.2.10.2 FCS_SSHS_EXT.1.2 ..........................................................................................................................................43
7.2.10.3 FCS_SSHS_EXT.1.3 ..........................................................................................................................................43
7.2.10.4 FCS_SSHS_EXT.1.4 ..........................................................................................................................................43
7.2.10.5 FCS_SSHS_EXT.1.5 ..........................................................................................................................................44
7.2.10.6 FCS_SSHS_EXT.1.6 ..........................................................................................................................................44
7.2.10.7 FCS_SSHS_EXT.1.7 ..........................................................................................................................................44
7.2.10.8 FCS_SSHS_EXT.1.8 ..........................................................................................................................................44
7.2.11 FCS_TLSC_EXT.1 TLS Client Protocol...............................................................................................................45
7.2.11.1 FCS_TLSC_EXT.1.1 ..........................................................................................................................................45
7.2.11.2 FCS_TLSC_EXT.1.2 ..........................................................................................................................................45
7.2.11.3 FCS_TLSC_EXT.1.3 ..........................................................................................................................................45
7.2.11.4 FCS_TLSC_EXT.1.4 ..........................................................................................................................................45
7.3 Identification and Authentication (FIA)......................................................................................................................45
7.3.1 FIA_AFL.1 Authentication Failure Management....................................................................................................45
7.3.2 FIA_PMG_EXT.1 Password Management..............................................................................................................46
7.3.3 FIA_UIA_EXT.1 User Identification and Authentication .......................................................................................46
7.3.4 FIA_UAU_EXT.2 Password-based Authentication Mechanism .............................................................................46
7.3.5 FIA_UAU.7 Protected Authentication Feedback.....................................................................................................47
7.3.6 FIA_X509_EXT.1/Rev X.509 Certificate Validation .............................................................................................. 47
7.3.7 FIA_X509_EXT.2 X.509 Certificate Authentication............................................................................................... 48
7.4 Security management (FMT)......................................................................................................................................48
7.4.1 FMT_MOF.1/ManualUpdate...................................................................................................................................48
Security Target of Huawei A800 Series Routers Contents
7.4.2 FMT_MOF.1/Functions Management of security functions behaviour...................................................................49
7.4.3 FMT_MOF.1/Services Management of security functions behaviour .....................................................................49
7.4.4 FMT_MTD.1/CoreData Management of TSF Data.................................................................................................49
7.4.5 FMT_MTD.1/CryptoKeys Management of TSF data.............................................................................................. 49
7.4.6 FMT_SMF.1 Specification of Management Functions............................................................................................ 49
7.4.7 FMT_SMR.2 Restrictions on security roles ............................................................................................................50
7.5 Protection of the TSF (FPT) .......................................................................................................................................50
7.5.1 FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric keys) ......................................................50
7.5.2 FPT_APW_EXT.1 Protection of Administrator Passwords.....................................................................................51
7.5.3 FPT_TST_EXT.1 TSF testing..................................................................................................................................51
7.5.4 FPT_TUD_EXT.1 Trusted Update .......................................................................................................................... 51
7.5.5 FPT_STM_EXT.1 Reliable Time Stamps................................................................................................................52
7.6 TOE Access (FTA)......................................................................................................................................................52
7.6.1 FTA_SSL_EXT.1 TSF-initiated Session Locking ...................................................................................................52
7.6.2 FTA_SSL.3 TSF-initiated Termination....................................................................................................................52
7.6.3 FTA_SSL.4 User-initiated Termination ...................................................................................................................53
7.6.4 FTA_TAB.1 Default TOE Access Banners..............................................................................................................53
7.7 Trusted path/channels (FTP).......................................................................................................................................53
7.7.1 FTP_ITC.1 Inter-TSF Trusted Channel ...................................................................................................................53
7.7.2 FTP_TRP.1/Admin Trusted Path ............................................................................................................................. 53
8 Crypto Disclaimer........................................................................................................................55
9 Abbreviations Terminology and References..........................................................................59
9.1 Abbreviations.............................................................................................................................................................. 59
9.2 Terminology................................................................................................................................................................ 60
9.3 References ..................................................................................................................................................................61
Security Target of Huawei A800 Series Routers 1 Introduction
1 Introduction
1.1 ST reference and TOE Reference
Name Description
ST Title
Security Target of Huawei A800 Series Routers
ST version 1.4
Vendor and ST author Huawei Technologies Co., Ltd
TOE Name Huawei A800 Series Routers
TOE Hardware Models
A811 and A821
TOE software version V800R022C00SPC600
1.2 TOE overview
The Huawei A800 Series Routers TOE are used to satisfy the requirements for networks of various
scales. They are deployed at the edge of MANs or at access sites that process heavy traffic to implement
multi-service access. The TOE includes the hardware models as defined in Table 1-2 in section 1.3.
The TOE is comprised of several security features. as identified below:
(1) Security audit
(2) Cryptographic support
(3) Identification and authentication
(4) Secure Management
(5) Protection of the TSF
Security Target of Huawei A800 Series Routers 1 Introduction
(6) TOE access through user authentication
(7) Trusted path and channels for device authentication.
1.2.1 TOE usage
1. The TOE supports username/password, or public-key authentication mode and only users that are
authenticated can access the TOE and its command line interface.
2. The TOE is accessed by CLI locally or a Network Management Server (NMS) remotely over SSH
so that a secure channel is established to protect the data between TOE and NMS.
3. For secure transmission of audit information between the TOE and the Syslog server a secure TLS
channel is used.
4. The TOE supports digital signature verification for software. Each of the software package or
patch package released by Huawei includes a unique digital signature. When an NMS distributes
the package to router, the TOE will verify the online digital signature before updating. The
verification of the digital signature demonstrates the integrity and authenticity of the package. The
package is only processed further after successful verification of the digital signature, otherwise
the package will be discarded without processing.
The TOE provides security services onto a single and secure device. It supports (in some cases
optionally) the following hardware, software, and firmware in its environment when the TOE is
configured in Figure 1-1 (NTP: Network Time Protocol; NMS: Network Management Server).
Figure 1-1 IT Entities which connect with TOE
1.2.2 TOE type
The TOE type is a network device that is connected to the network and has an infrastructure role within
the network.
1.2.3 Non TOE Hardware and Software
The TOE supports the following hardware, software, and firmware components in its operational
environment. All of the following environment components are supported by all TOE evaluated
configurations.
Security Target of Huawei A800 Series Routers 1 Introduction
Table 1-1 IT Environment Components
Component Required Usage/Purpose Description for TOE performance
Network
Management Server
YES This includes any Management workstation with a SSH
client installed that is used to establish a protected channel
with the TOE.
Local Console YES This includes any Console that is directly connected to the
TOE via the Serial Console Port and is used by the TOE
administrator to support TOE administration.
Syslog Server YES This includes any syslog server to which the TOE would
transmit syslog messages.
The administrator should only connect to known trusted
Syslog server
Open PGP YES The Open PGP is used to verify the integrity of software
package that is necessary to perform the installation of the
TOE.
1.3 TOE description
The TOE is A800 Series Routers comprised of both software and hardware. The TOE scope consists of
the software running in the router device. The hardware is comprise of the following: A811 and A821.
TSF relevant functions depend on software implementation. Table 1-2 below describes the models that
have been claimed within this evaluation.
Table 1-2 Hardware Scope
Hardware Configuration Processor Interface
A811
A811 Integrated Chassis, Fixed
interfaces.
ARM
Based on TOE's I/O
modules
A821
A821 Integrated Chassis, Fixed
interfaces.
ARM
Based on TOE's I/O
modules
1.4 Physical scope
This section will define the physical scope (table 1-3) of the Huawei A800 series routers to be evaluated.
Security Target of Huawei A800 Series Routers 1 Introduction
Table 1-3 Physical scope
Type Delivery Item Version Date
Hardware A811 and A821
The Hardware will be delivered by air, ship, train or automobile
NA
Software A800 Router V800R022C00SPC600
Format:
A811:NetEngine-A81X-A82X_V800R022C00SPC600.cc
Info:
Users can login the HUAWEI support website to download the software packet
in accordance to the version of the TOE.
Users can verify the software by digital signature(The digital signature is also
published on HUAWEI support website)
A821: NetEngine-A81X-A82X_V800R022C00SPC600.cc
Info:
Users can login the HUAWEI support website to download the software packet
in accordance to the version of the TOE.
Users can verify the software by digital signature(The digital signature is also
published on HUAWEI support website)
V800R022
C00SPC600
2022-11-
14
Product
guidance
Huawei NetEngine A800 Series Routers V800R022C00 Operational User
Guidance
Info:
The documentation is delivered by email.
1.3 2023-06-
08
Huawei NetEngine A800 Series Routers V800R022C00 Preperation Procedure
Info:
The documentation is delivered by email.
1.3 2023-04-
13
NetEngine A800 V800R022C00SPC600 Upgrade Guide
Info:
Users can obtain documents from Huawei engineers by email.
1.0 2022-10-
31
NetEngine A821 E, A821, A811 M, A811 and A810 V800R022C00 Product
Documentation
Info:
Users can obtain documents from Huawei engineers by email. The document
format is *.chm.
1.0 2022-10-
31
Security Target of Huawei A800 Series Routers 1 Introduction
1.5 Logical Scope of the TOE
The TOE is comprised of several security features. Each of the security features identified above
consists of several security functionalities, as identified below.
(1) Security audit
The log module of the host software records operations on a device and events that occur to a
device. The recorded operations and events are log messages. Log messages provide evidence for
diagnosing and maintaining a system. Log messages reflect the operating status of a device and
are used to analyze the conditions of a network and to find out the causes of network failure or
faults.
Key elements of log messages include timestamp, host name, Huawei identity, version, module
name, severity, brief description, etc.
IC component are the module processing, outputting log records. Information hierarchy is
designed to help the user roughly differentiate between information about normal operation and
information about faults. Since the information center needs to output information to the terminal,
console, log buffer, and log file.
(2) Cryptographic support
The TOE provides cryptography in support of secure connections that includes remote
administrative management.
The cryptographic services provided by the TOE are described in table below.
Table 1-4 Cryptography provided by TOE
Cryptography Function Use in the TOE
DRBG Used in session establishment of TLS and SSH
ECDSA Used in the authentication of SSH
ECDH Used in session establishment of SSH
RSA Used in the authentication of TLS
DHE Used in session establishment of TLS
SHA Used to provide cryptographic hashing services
HMAC-SHA Used to provide integrity and authentication verification
AES Used to encrypt traffic transmitted through TLS and SSH
(3) Identification and authentication
The authentication functionality provides validation by user’s account name and password. Public
key authentication is supported for SSH users. Detailed functionalities, for example max
idle-timeout period, max log-in attempts, UI lock, user kick out, can be applied by administrator
according to networking environment, customized security considerations, differential user role on
Security Target of Huawei A800 Series Routers 1 Introduction
TOE, and/or other operational concerns.
(4) Secure Management
The TOE restricts the ability to determine the behavior of and modify the behavior of the functions
transmission of audit data to the security administrator. Only the security administrator can manage
the cryptographic keys. Only the security administrator has the right of opening/closing the security
services and creation/deletion/modification of the user accounts.
(5) Protection of the TSF
The TOE protects the pre-shared keys, symmetric keys, and private keys from reading them by an
unauthorized entity. The TOE stores the users or administrator passwords in non-plaintext form
preventing them from reading. The TOE verifies the packet before their installation and uses the
digital signature.
(6) TOE access through user authentication
The TOE provides communication security by implementing SSH protocol.
To protect the TOE from eavesdrop and to ensure data transmission security and confidentiality,
SSH implements:
 authentication by password or by public-key;
 AES encryption algorithms;
 secure cryptographic key exchange;
 Besides default TCP port 22, manually specifying a listening port is also implemented since
it can effectively reduce attacks.
(7) Trusted path and channels for device authentication
The TOE supports the trusted connections using TLS for the communication with the audit server.
1.6 Standalone TOE
[CPP_ND], chapter 3 introduces distributed TOEs, i.e. TOEs that consist of more than one
component. This does not refer to different software components running on one hardware
component but same version software components running on each hardware components.
This ST refers to a standalone TOE which is not a distributed TOE in the sense of [CPP_ND],
chapter 3. All additional requirements that are defined for distributed TOEs within [CPP_ND] are
therefore ignored in this ST. There are dedicated paragraphs in several Application Notes of
[CPP_ND] which are only applicable to distributed TOEs. These dedicated paragraphs have not
been integrated into the Application Notes in this ST since the TOE is not a distributed TOE.
Security Target of Huawei A800 Series Routers 2 PP conformance claims
2 PP conformance claims
2.1 CC Conformance Claim
As defined by the references [CC1], [CC2] and [CC3], this ST:
 conforms to the requirements of Common Criteria v3.1, Revision 5
 is Part 2 extended, Part 3 conformant
 does not claim conformance to any other PP than the one specified in chap 2.2
 does not claim conformance to any Evaluation Assurance Level as defined in [CC3], chap. 8.
2.2 Protection Profile Conformance
This security target claims “Exact Conformance” to [CPP_ND]. Note that "Exact Conformance" is
defined in [CPP_ND], chap. 2.
The methodology applied for the cPP evaluation is defined in [CEM]. In addition to [CEM], the
evaluation activities for [CPP_ND] are completed in [SD_ND].
The assurance package applicable to this ST is defined in [CPP_ND] as follows:
Table 2-1 Assurance Package
Assurance Class Assurance Components
Security Target (ASE) Conformance claims (ASE_CCL.1)
Extended components definition (ASE_ECD.1)
ST introduction (ASE_INT.1)
Security objectives for the operational environment
(ASE_OBJ.1)
Stated security requirements (ASE_REQ.1)
Security Problem Definition (ASE_SPD.1)
TOE summary specification (ASE_TSS.1)
Development (ADV) Basic functional specification (ADV_FSP.1)
Guidance documents Operational user guidance (AGD_OPE.1)
Security Target of Huawei A800 Series Routers 2 PP conformance claims
Assurance Class Assurance Components
(AGD) Preparative procedures (AGD_PRE.1)
Life cycle support (ALC) Labeling of the TOE (ALC_CMC.1)
TOE CM coverage (ALC_CMS.1)
Tests (ATE) Independent testing – sample (ATE_IND.1)
Vulnerability assessment
(AVA)
Vulnerability survey (AVA_VAN.1)
2.3 Conformance Rationale
2.3.1 TOE Appropriateness
The TOE provides all of the functionality at a level of security commensurate with that identified in the
[CPP_ND].
2.3.2 TOE Security Problem Definition Consistency
The Threats, Assumptions, and Organization Security Policies included in the Security Target represent
the Threats, Assumptions, and Organization Security Policies specified in [CPP_ND] for which
conformance is claimed verbatim. All concepts covered in the collaborative Protection Profile Security
Problem Definition are included in the Security Target.
2.3.3 Statement of Security Objectives Consistency
The security objectives included in the security target represent the security objectives specified in
[CPP_ND] for which conformance is claimed verbatim. All concepts covered in Protection Profile`s
Statement of security objectives are included in the Security Target.
2.3.4 Statement of Security Requirements Consistency
The Security Functional Requirements included in the Security Target represent the Security Functional
Requirements specified in the [CPP_ND] for which conformance is claimed verbatim. All concepts
covered the Protection Profile’s Statement of Security Requirements are included in the Security Target.
Additionally, the Security Assurance Requirements included in the Security Target are identical to the
Security Assurance Requirements included in section 6 of the [CPP_ND].
Security Target of Huawei A800 Series Routers 3 Security Problem Definition
3 Security Problem Definition
3.1 Assets
The owner of the TOE presumably places value upon the following entities as long as they are in the
scope of the TOE.
Table 3-1 TOE Assets
Asset Name Description
Audit data The data which is provided during security audit logging.
TOE Security characteristic: integrity.
Authentication data The data which is used to identify and authenticate the external
entities such as account, password, certificate, etc.
TOE Security characteristic: confidentiality, integrity.
Cryptography data The data which is used for digital signature and
encryption/decryption such as key.
TOE Security characteristic: confidentiality, integrity.
Management data The data which is used for software updates, and software integrity
checking.
TOE Security characteristic: integrity.
Configuration data TOE Security characteristic: integrity.
Software &firm ware device firmware; software;
TOE Security characteristic: integrity.
Critical network
traffic
Administration traffic; Authentication traffic containing
Authentication data; Audit traffic; traffic containing cryptography
data; traffic containing Management data
TOE Security characteristic: confidentiality, integrity.
Security
Functionality of the
Device
The TOE Security Functions (TSF) (Remark: In the context of this
ST the Security Functionality of the device refers to the security
functions of the TOE).
TOE Security characteristic: integrity.
Security Target of Huawei A800 Series Routers 3 Security Problem Definition
Network on which
the device resides
The network on which the device resides.
TOE Security characteristic: integrity.
Network device The network device itself.
TOE Security characteristic: integrity.
Trust relations with
other network devices
Trust relations of the TOE with other network devices.
TOE Security characteristic: integrity, authenticity.
3.2 Threats
The threats for the Network Device are grouped according to functional areas of the device in the
sections below.
3.2.1 T.UNAUTHORIZED_ADMINISTRATOR_ACCESS
Threat agents may attempt to gain Administrator access to the Network Device by nefarious means such
as masquerading as an Administrator to the device, masquerading as the device to an Administrator,
replaying an administrative session (in its entirety, or selected portions), or performing
man-in-the-middle attacks, which would provide access to the administrative session, or sessions
between Network Devices. Successfully gaining Administrator access allows malicious actions that
compromise the security functionality of the device and the network on which it resides.
SFR Rationale:
 The Administrator role is defined in FMT_SMR.2 and the relevant administration capabilities
are defined in FMT_SMF.1 and FMT_MTD.1/CoreData, with optional additional capabilities
in FMT_MOF.1/Services and FMT_MOF.1/Functions
 The actions allowed before authentication of an Administrator are constrained by
FIA_UIA_EXT.1, and include the advisory notice and consent warning message displayed
according to FTA_TAB.1
 The requirement for the Administrator authentication process is described in
FIA_UAU_EXT.2
 Locking of Administrator sessions is ensured by FTA_SSL_EXT.1 (for local sessions),
FTA_SSL.3 (for remote sessions), and FTA_SSL.4 (for all interactive sessions)
 The secure channel used for remote Administrator connections is specified in
FTP_TRP.1/Admin
 (Malicious actions carried out from an Administrator session are separately addressed by
T.UNDETECTED_ACTIVITY)
 (Protection of the Administrator credentials is separately addressed by
T.PASSWORD_CRACKING).
3.2.2 T.WEAK_CRYPTOGRAPHY
Threat agents may exploit weak cryptographic algorithms or perform a cryptographic exhaust against
the key space. Poorly chosen encryption algorithms, modes, and key sizes will allow attackers to
compromise the algorithms, or brute force exhaust the key space and give them unauthorized access
allowing them to read, manipulate and/or control the traffic with minimal effort.
SFR Rationale:
Security Target of Huawei A800 Series Routers 3 Security Problem Definition
 Requirements for key generation and key distribution are set in FCS_CKM.1 and
FCS_CKM.2 respectively
 Requirements for use of cryptographic schemes are set in FCS_COP.1/DataEncryption,
FCS_COP.1/SigGen, FCS_COP.1/Hash, and FCS_COP.1/KeyedHash
 Requirements for random bit generation to support key generation and secure protocols
(see SFRs resulting from T.UNTRUSTED_COMMUNICATION_CHANNELS) are set in
FCS_RBG_EXT.1
 Management of cryptographic functions is specified in FMT_SMF.1
3.2.3 T.UNTRUSTED_COMMUNICATION_CHANNELS
Threat agents may attempt to target Network Devices that do not use standardized secure tunneling
protocols to protect the critical network traffic. Attackers may take advantage of poorly designed
protocols or poor key management to successfully perform man-in-the-middle attacks, replay attacks,
etc. Successful attacks will result in loss of confidentiality and integrity of the critical network traffic,
and potentially could lead to a compromise of the Network Device itself.
SFR Rationale:
 The general use of secure protocols for identified communication channels is described at
the top level in FTP_ITC.1 and FTP_TRP.1/Admin
 Requirements for the use of secure communication protocols are set for all the allowed
protocols in FCS_SSHC_EXT.1, FCS_SSHS_EXT.1, FCS_TLSC_EXT.1
 Optional and selection-based requirements for use of public key certificates to support
secure protocols are defined in FIA_X509_EXT.1/Rev, FIA_X509_EXT.2
3.2.4 T.WEAK_AUTHENTICATION_ENDPOINTS
Threat agents may take advantage of secure protocols that use weak methods to authenticate the
endpoints, e.g. a shared password that is guessable or transported as plaintext. The consequences are the
same as a poorly designed protocol, the attacker could masquerade as the Administrator or another
device, and the attacker could insert themselves into the network stream and perform a
man-in-the-middle attack. The result is the critical network traffic is exposed and there could be a loss
of confidentiality and integrity, and potentially the Network Device itself could be compromised.
SFR Rationale:
 The use of appropriate secure protocols to provide authentication of endpoints (as in the
SFRs addressing T.UNTRUSTED_COMMUNICATION_CHANNELS) are ensured by the
requirements in FTP_ITC.1 and FTP_TRP.1/Admin
3.2.5 T.UPDATE_COMPROMISE
Threat agents may attempt to provide a compromised update of the software or firmware which
undermines the security functionality of the device. Non-validated updates or updates validated using
non-secure or weak cryptography leave the update firmware vulnerable to surreptitious alteration.
SFR Rationale:
 Requirements for protection of updates are set in FPT_TUD_EXT.1
 Certificate-based protection of signatures is supported by the X.509 certificate processing
requirements in FIA_X509_EXT.1/Rev, FIA_X509_EXT.2
Security Target of Huawei A800 Series Routers 3 Security Problem Definition
 Requirements for management of updates are defined in FMT_SMF.1 and (for manual
updates) in FMT_MOF.1/ManualUpdate
3.2.6 T.UNDETECTED_ACTIVITY
Threat agents may attempt to access, change, and/or modify the security functionality of the Network
Device without Administrator awareness. This could result in the attacker finding an avenue (e.g.,
misconfiguration, flaw in the product) to compromise the device and the Administrator would have no
knowledge that the device has been compromised.
SFR Rationale:
 Requirements for basic auditing capabilities are specified in FAU_GEN.1 and FAU_GEN.2,
with timestamps provided according to FPT_STM_EXT.1
 Requirements for protecting audit records stored on the TOE are specified in FAU_STG.1
 Requirements for secure transmission of local audit records to an external IT entity via a
secure channel are specified in FAU_STG_EXT.1
 Additional requirements for dealing with potential loss of locally stored audit records are
specified in FAU_STG_EXT.3/LocSpace
 Configuration of the audit functionality is specified in FMT_SMF.1 and confining this
functionality to Security Administrators is required by FMT_MOF.1/Functions.
3.2.7 T.SECURITY_FUNCTIONALITY_COMPROMISE
Threat agents may compromise credentials and device data enabling continued access to the Network
Device and its critical data. The compromise of credentials includes replacing existing credentials with
an attacker’s credentials, modifying existing credentials, or obtaining the Administrator or device
credentials for use by the attacker.
SFR Rationale:
 Protection of secret/private keys against compromise is specified in FPT_SKP_EXT.1
 Secure destruction of keys is specified in FCS_CKM.4
 Management of keys is specified in FMT_SMF.1 and confining this functionality to Security
Administrators is required by FMT_MTD.1/CryptoKeys
 (Protection of passwords is separately covered under T.PASSWORD_CRACKING)
3.2.8 T.PASSWORD_CRACKING
Threat agents may be able to take advantage of weak administrative passwords to gain privileged access
to the device. Having privileged access to the device provides the attacker unfettered access to the
network traffic and may allow them to take advantage of any trust relationships with other Network
Devices.
SFR Rationale:
 Requirements for password lengths and available characters are set in FIA_PMG_EXT.1
 Protection of password entry by providing only obscured feedback is specified in
FIA_UAU.7
 Actions on reaching a threshold number of consecutive password failures are specified in
FIA_AFL.1
 Requirements for secure storage of passwords are set in FPT_APW_EXT.1.
Security Target of Huawei A800 Series Routers 3 Security Problem Definition
3.2.9 T.SECURITY_FUNCTIONALITY_FAILURE
An external, unauthorized entity could make use of failed or compromised security functionality and
might therefore subsequently use or abuse security functions without prior authentication to access,
change or modify device data, critical network traffic or security functionality of the device.
SFR Rationale:
• Requirements for running self-test(s) are defined in FPT_TST_EXT.1
3.3 Assumptions
This section describes the assumptions made in identification of the threats and security requirements
for Network Devices. The Network Device is not expected to provide assurance in any of these areas,
and as a result, requirements are not included to mitigate the threats associated.
3.3.1 A.PHYSICAL_PROTECTION
The Network Device is assumed to be physically protected in its operational environment and not
subject to physical attacks that compromise the security or interfere with the device’s physical
interconnections and correct operation. This protection is assumed to be sufficient to protect the device
and the data it contains. As a result, the ST does not include any requirements on physical tamper
protection or other physical attack mitigations. The ST does not expect the product to defend against
physical access to the device that allows unauthorized entities to extract data, bypass other controls, or
otherwise manipulate the device.
[OE.PHYSICAL]
3.3.2 A.LIMITED_FUNCTIONALITY
The device is assumed to provide networking functionality as its core function and not provide
functionality/services that could be deemed as general purpose computing. For example, the device
should not provide a computing platform for general purpose applications (unrelated to networking
functionality).
[OE.NO_GENERAL_PURPOSE]
3.3.3 A.NO_THRU_TRAFFIC_PROTECTION
A standard/generic Network Device does not provide any assurance regarding the protection of traffic
that traverses it. The intent is for the Network Device to protect data that originates on or is destined to
the device itself, to include administrative data and audit data. Traffic that is traversing the Network
Device, destined for another network entity, is not covered by the ND cPP. It is assumed that this
protection will be covered by cPPs and PP-Modules for particular types of Network Devices (e.g.,
firewall).
[OE.NO_THRU_TRAFFIC_PROTECTION]
Security Target of Huawei A800 Series Routers 3 Security Problem Definition
3.3.4 A.TRUSTED_ADMINISTRATOR
The Security Administrator(s) for the Network Device are assumed to be trusted and to act in the best
interest of security for the organization. This includes appropriately trained, following policy, and
adhering to guidance documentation. Administrators are trusted to ensure passwords/credentials have
sufficient strength and entropy and to lack malicious intent when administering the device. The
Network Device is not expected to be capable of defending against a malicious Administrator that
actively works to bypass or compromise the security of the device.
[OE.TRUSTED_ADMIN]
3.3.5 A.REGULAR_UPDATES
The Network Device firmware and software is assumed to be updated by an Administrator on a regular
basis in response to the release of product updates due to known vulnerabilities.
[OE.UPDATES]
3.3.6 A.ADMIN_CREDENTIALS_SECURE
The Administrator’s credentials (private key) used to access the Network Device are protected by the
platform on which they reside.
[OE.ADMIN_CREDENTIALS_SECURE]
3.3.7 A.RESIDUAL_INFORMATION
The Administrator must ensure that there is no unauthorized access possible for sensitive residual
information (e.g. cryptographic keys, keying material, PINs, passwords etc.) on networking equipment
when the equipment is discarded or removed from its operational environment.
[OE.RESIDUAL_INFORMATION]
3.4 Organizational Security Policies
An organizational security policy is a set of rules, practices, and procedures imposed by an organization
to address its security needs.
3.4.1 P.ACCESS_BANNER
The TOE shall display an initial banner describing restrictions of use, legal agreements, or any other
appropriate information to which users consent by accessing the TOE.
SFR Rationale:
 An advisory notice and consent warning message is required to be displayed by FTA_TAB.1
Security Target of Huawei A800 Series Routers 3 Security Problem Definition
Security Target of Huawei A800 Series Routers 4 Security Objectives
4 Security Objectives
4.1 Security Objectives for the Operational Environment
The following subsections describe security objectives for the Operational Environment.
4.1.1 OE.PHYSICAL
Physical security, commensurate with the value of the TOE and the data it contains, is provided by the
environment.
4.1.2 OE.NO_GENERAL_PURPOSE
There are no general-purpose computing capabilities (e.g., compilers or user applications) available on
the TOE, other than those services necessary for the operation, administration and support of the TOE.
4.1.3 OE.NO_THRU_TRAFFIC_PROTECTION
The TOE does not provide any protection of traffic that traverses it. It is assumed that protection of this
traffic will be covered by other security and assurance measures in the operational environment.
4.1.4 OE.TRUSTED_ADMIN
Security Administrators are trusted to follow and apply all guidance documentation in a trusted manner.
For TOEs supporting X.509v3 certificate-based authentication, the Security Administrator(s) are
assumed to monitor the revocation status of all certificates in the TOE's trust store and to remove any
certificate from the TOE’s trust store in case such certificate can no longer be trusted.
4.1.5 OE.UPDATES
The TOE firmware and software is updated by an Administrator on a regular basis in response to the
release of product updates due to known vulnerabilities.
Security Target of Huawei A800 Series Routers 4 Security Objectives
4.1.6 OE.ADMIN_CREDENTIALS_SECURE
The Administrator’s credentials (private key) used to access the TOE must be protected on any other
platform on which they reside.
4.1.7 OE.RESIDUAL_INFORMATION
The Security Administrator ensures that there is no unauthorized access possible for sensitive residual
information (e.g. cryptographic keys, keying material, PINs, passwords etc.) on networking equipment
when the equipment is discarded or removed from its operational environment.
Security Target of Huawei A800 Series Routers
5 Extended Components
Definition
5 Extended Components Definition
The extended components used in this ST are defined in [CPP_ND]. The following table provide a
chapter specific reference in which chapter of each of the extended components is defined.
Table 5-1 Definition of Extended Components - references to [CPP_ND]
Extended Component Drawn From
Mandatory Requirements
FAU_STG_EXT.1 NDcPP C.1.2.1
FCS_RBG_EXT.1 NDcPP C.2.1.1
FIA_PMG_EXT.1 NDcPP C 3.1.1
FIA_UIA_EXT.1 NDcPP C 3.2.1
FIA_UAU_EXT.2 NDcPP C 3.3.1
FPT_SKP_EXT.1 NDcPP C 4.1.1
FPT_APW_EXT.1 NDcPP C 4.2.1
FPT_TST_EXT.1 NDcPP C.4.3.1
FPT_TUD_EXT.1 NDcPP C 4.4.1
FPT_STM_EXT.1 NDcPP C 4.5.1
FTA_SSL_EXT.1 NDcPP C 5.1.1
Optional Requirements
FAU_STG_EXT.3/LocSpace NDcPP C 1.2.3
Selection-Based
Requirements
FCS_SSHC_EXT.1 NDcPP C 2.2.6
FCS_SSHS_EXT.1 NDcPP C 2.2.7
FCS_TLSC_EXT.1 NDcPP C 2.2.8
FIA_X509_EXT.1/Rev NDcPP C 3.4.1
FIA_X509_EXT.2 NDcPP C 3.4.2
Security Target of Huawei A800 Series Routers
6 Security Functional
Requirements
6 Security Functional Requirements
Conventions
The conventions used in descriptions of the SFRs are as follows:
 Unaltered SFRs are stated in the form used in [CC2] or their extended component definition
(ECD);
 Refinement made in the cPP and ST: the refinement text is indicated with bold text and
strikethroughs;
 Selection wholly or partially completed in the cPP and ST: the selection values (i.e. the
selection values adopted in the cPP or the remaining selection values available for the ST) are
indicated with underlined text
e.g. “[selection: disclosure, modification, loss of use]” in [CC2] or an ECD
might become “disclosure” (completion) or “[selection: disclosure,
modification]” (partial completion) in the PP;
 Assignment wholly or partially completed in the cPP and ST: indicated with italicized text;
 Assignment completed within a selection in the cPP and ST: the completed assignment text is
indicated with italicized and underlined text
e.g. “[selection: change_default, query, modify, delete, [assignment: other
operations]]” in [CC2] or an ECD might become “change_default, select_tag”
(completion of both selection and assignment) or “[selection: change_default,
select_tag, select_value]” (partial completion of selection, and completion of
assignment) in the PP;
 Iteration: indicated by adding a string starting with “/” (e.g. “FCS_COP.1/Hash”), or by
appending the iteration number in parenthesis, e.g. (1), (2), (3).
 Application Notes added by the ST author are called 'Additional Application Note' which are
enumerated as 'a', 'b', ... and are formatted with underline such as “Additional Application
Note a”;
 References: Indicated with [square brackets].
Security Target of Huawei A800 Series Routers
6 Security Functional
Requirements
6.1 Functional Security Requirements
6.1.1 Security Audit (FAU)
6.1.1.1 FAU_GEN.1 Audit data generation
FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events:
a) Start-up and shut-down of the audit functions;
b) All auditable events for the not specified level of audit; and
c) All administrative actions comprising:
 Administrative login and logout (name of user account shall be logged if individual
user accounts are required for administrators).
 Changes to TSF data related to configuration changes (in addition to the information
that a change occurred it shall be logged what has been changed).
 Generating/import of, changing, or deleting of cryptographic keys (in addition to the
action itself a unique key name or key reference shall be logged).
 Resetting passwords (name of related user account shall be logged).
 Starting and stopping services.
d) Specifically defined auditable events listed in Table 6-1.
Additional Application Note a: Audit functionality is enabled by default. The auditing
functionality cannot be disabled.
Additional Application Note b: The TOE does not support using reset command to reset
password directly, but it can modify password in the following way: re-create local-user or
change local-user password.
FAU_GEN.1.2 The TSF shall record within each audit record at least the following information:
a) Date and time of the event, type of event, subject identity, and the outcome (success or
failure) of the event; and
b) For each audit event type, based on the auditable event definitions of the functional
components included in the PP/ST, information specified in column three of Table 6-1.
Table 6-1 Security Functional Requirements andAuditable Events
Requirement Auditable Events Additional Audit
Record Contents
Mandatory Requirements
FAU_GEN.1 None. None.
FAU_GEN.2 None. None.
FAU_STG_EXT.1 None. None.
FCS_CKM.1 None. None.
FCS_CKM.2 None. None.
FCS_CKM.4 None. None.
FCS_COP.1/DataEncryption None. None.
FCS_COP.1/SigGen None. None.
FCS_COP.1/Hash None. None.
Security Target of Huawei A800 Series Routers
6 Security Functional
Requirements
Requirement Auditable Events Additional Audit
Record Contents
FCS_COP.1/KeyedHash None. None.
FCS_RBG_EXT.1 None. None.
FIA_AFL.1 Unsuccessful login attempts limit
is met or exceeded.
Origin of the attempt
(e.g., IP address).
FIA_PMG_EXT.1 None. None.
FIA_UIA_EXT.1 All use of the identification and
authentication mechanism.
Origin of the attempt
(e.g., IP address).
FIA_UAU_EXT.2 All use of the identification and
authentication mechanism.
Origin of the attempt (e.g.
IP address).
FIA_UAU.7 None. None.
FMT_MOF.1/ManualUpdate Any attempt to initiate a manual
update
None.
FMT_MTD.1/CoreData None. None.
FMT_SMF.1 All management activities of
TSF data.
None.
FMT_SMR.2 None. None.
FPT_SKP_EXT.1 None. None.
FPT_APW_EXT.1 None. None.
FPT_TST_EXT.1 None. None
FPT_TUD_EXT.1 Initiation of update; result of the
update attempt (success or
failure).
None
FPT_STM_EXT.1 Discontinuous changes to time -
either Administrator actuated or
changed via an automated
process. (Note that no continuous
changes to time need to be
logged.)
For discontinuous
changes to time: The old
and new values for the
time. Origin of the
attempt to change time for
success and failure (e.g.
IP address).
FTA_SSL_EXT.1 The termination of a local
session by the session locking
mechanism.
None.
FTA_SSL.3 The termination of a remote
session by the session locking
mechanism.
None.
FTA_SSL.4 The termination of an interactive
session.
None
FTA_TAB.1 None. None.
FTP_ITC.1 Initiation of the trusted channel.
Termination of the trusted
channel.
Failure of the trusted channel
functions.
Identification of the
initiator and target of
failed trusted channels
establishment attempt.
FTP_TRP.1/Admin Initiation of the trusted path.
Termination of the trusted path.
Failures of the trusted path
functions.
None
Optional Requirements
FAU_STG.1 None. None.
FAU_STG_EXT.3/LocSpace Low storage space for audit None.
Security Target of Huawei A800 Series Routers
6 Security Functional
Requirements
Requirement Auditable Events Additional Audit
Record Contents
events.
Selection-Based Requirements
FCS_SSHC_EXT.1 Failure to establish an SSH
session.
Reason for failure.
FCS_SSHS_EXT.1 Failure to establish an SSH
session.
Reason for failure.
FCS_TLSC_EXT.1 Failure to establish a TLS
Session.
Reason for failure.
FIA_X509_EXT.1/Rev Unsuccessful attempt to validate
a certificate.
Any addition, replacement or
removal of trust anchors in the
TOE's trust store
Reason for failure of
certificate validation
Identification of
certificates added,
replaced or removed as
trust anchor in the TOE's
trust store.
FIA_X509_EXT.2 None. None.
FMT_MOF.1/Services Starting and stopping of services. None.
FMT_MOF.1/Functions Modification of the behaviour of
the transmission of audit data to
an external IT entity, the
handling of audit data, the audit
functionality when Local Audit
Storage Space is full.
None.
FMT_MTD.1/CryptoKeys Management of cryptographic
keys.
None.
6.1.1.2 FAU_GEN.2 User identity association
FAU_GEN.2.1 For audit events resulting from actions of identified users, the TSF shall be able to
associate each auditable event with the identity of the user that caused the event.
6.1.1.3 FAU_STG_EXT.1 Protected Audit Event Storage
FAU_STG_EXT.1.1 The TSF shall be able to transmit the generated audit data to an external IT
entity using a trusted channel according to FTP_ITC.1.
FAU_STG_EXT.1.2 The TSF shall be able to store generated audit data on the TOE itself. In addition
The TOE shall consist of a single standalone component that stores audit data locally
FAU_STG_EXT.1.3 The TSF shall overwrite previous audit records according to the following rule:
overwrite the oldest log information always when the local storage space for audit data is full.
Security Target of Huawei A800 Series Routers
6 Security Functional
Requirements
6.1.1.4 FAU_STG_EXT.3/LocSpace Action in case of possible audit data
loss
FAU_STG_EXT.3.1/LocSpace The TSF shall generate a warning to inform the Administrator before
the audit trail exceeds the local audit trail storage capacity.
6.1.1.5 FAU_STG.1 Protected audit trail storage
FAU_STG.1.1 The TSF shall protect the stored audit records in the audit trail from unauthorized
deletion.
FAU_STG.1.2 The TSF shall be able to prevent unauthorized modifications to the stored audit
records in the audit trail.
6.1.2 Cryptographic Support (FCS)
6.1.2.1 FCS_CKM.1 Cryptographic Key Generation (Refinement)
FCS_CKM.1.1 The TSF shall generate asymmetric cryptographic keys in accordance with a
specified cryptographic key generation algorithm:
 FFC schemes using cryptographic key sizes of 2048-bit or greater that meet the
following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.1
 ECC schemes using “NIST curves” P-256, P-384, P-521 that meet the following: FIPS
PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4;
and specified cryptographic key sizes [assignment: cryptographic key sizes] that meet the following:
[assignment: list of standards].
6.1.2.2 FCS_CKM.2 Cryptographic Key Establishment (Refinement)
FCS_CKM.2.1 The TSF shall perform cryptographic key establishment in accordance with a
specified cryptographic key establishment method:
 Elliptic curve-based key establishment schemes that meet the following: NIST Special
Publication 800-56A Revision 2, “Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography”;
 Finite field-based key establishment schemes that meet the following: NIST Special
Publication 800-56A Revision 2, “Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography”;
that meets the following: [assignment: list of standards].
6.1.2.3 FCS_CKM.4 Cryptographic Key Destruction
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method:
 For plaintext keys in volatile storage, the destruction shall be executed by a single
overwrite consisting of zeroes;
Security Target of Huawei A800 Series Routers
6 Security Functional
Requirements
 For plaintext keys in non-volatile storage, the destruction shall be executed by the
invocation of an interface provided by a part of the TSF that
 logically addresses the storage location of the key and performs a single overwrite
consisting of a new value of the key
that meets the following: No Standard.
6.1.2.4 FCS_COP.1/DataEncryption Cryptographic Operation (AES
Data Encryption/ Decryption)
FCS_COP.1.1/DataEncryption The TSF shall perform encryption/decryption in accordance with a
specified cryptographic algorithm AES used in CTR, GCM mode and cryptographic key sizes 128
bits, 256 bits that meet the following: AES as specified in ISO 18033-3, CTR as specified in ISO
10116, GCM as specified in ISO 19772.
6.1.2.5 FCS_COP.1/SigGen Cryptographic Operation (Signature
Generation and Verification)
FCS_COP.1.1/SigGen The TSF shall perform cryptographic signature services (generation and
verification) in accordance with a specified cryptographic algorithm:
 RSA Digital Signature Algorithm and cryptographic key sizes (modulus): 3072 bits and
4096 bits,
 Elliptic Curve Digital Signature Algorithm and cryptographic key sizes: 256 bits, 384 bits
and 521 bits
that meet the following:
 For RSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5.5,
using PKCS #1 v2.1 Signature Schemes RSASSA-PSS and/or RSASSA-PKCS1v1_5;
ISO/IEC 9796-2, Digital signature scheme 2 or Digital Signature scheme 3,
 For ECDSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 6 and
Appendix D, Implementing “NIST curves”: P-256, P-384 and P-521; ISO/IEC 14888-3,
Section 6.4
6.1.2.6 FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm)
FCS_COP.1.1/Hash The TSF shall perform cryptographic hashing services in accordance with a
specified cryptographic algorithm: SHA-256, SHA-384, and cryptographic key sizes [assignment:
cryptographic key sizes] and message digest sizes 256, 384 bits that meet the following: ISO/IEC
10118-3:2004.
6.1.2.7 FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash
Algorithm)
FCS_COP.1.1/KeyedHash The TSF shall perform keyed-hash message authentication in accordance
with a specified cryptographic algorithm: HMAC-SHA-256 and cryptographic key sizes: 256 bits for
HMAC-SHA-256 and message digest sizes: 256 bits that meet the following: ISO/IEC 9797-2:2011,
Section 7 “MAC Algorithm 2”.
Security Target of Huawei A800 Series Routers
6 Security Functional
Requirements
6.1.2.8 FCS_RBG_EXT.1 Random Bit Generation
FCS_RBG_EXT.1.1 The TSF shall perform all deterministic random bit generation services in
accordance with ISO/IEC 18031:2011 using Hash_DRBG (any).
FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by at least one entropy source that
accumulates entropy from 1 platform-based noise source with a minimum of 256 bits of entropy at
least equal to the greatest security strength, according to ISO/IEC 18031:2011 Table C.1 “Security
Strength Table for Hash Functions”, of the keys and hashes that it will generate.
6.1.2.9 FCS_SSHC_EXT.1 SSH Client Protocol
FCS_SSHC_EXT.1.1 The TSF shall implement the SSH protocol that complies with RFC(s) 4251,
4252, 4253, 4254, 4256, 4344, 5647, 5656, 6668.
FCS_SSHC_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports the
following user authentication methods as described in RFC 4252: public key-based,
password-based.FCS_SSHC_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets
greater than 262144 bytes in an SSH transport connection are dropped.
FCS_SSHC_EXT.1.4 The TSF shall ensure that the SSH transport implementation uses the following
encryption algorithms and rejects all other encryption algorithms: aes128-ctr, aes256-ctr,
AEAD_AES_128_GCM, AEAD_AES_256_GCM, aes128-gcm@openssh.com,
aes256-gcm@openssh.com.
FCS_SSHC_EXT.1.5 The TSF shall ensure that the SSH public-key based authentication
implementation uses ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521 as its public key
algorithm(s) and rejects all other public key algorithms.
FCS_SSHC_EXT.1.6 The TSF shall ensure that the SSH transport implementation uses
hmac-sha2-256, AEAD_AES_128_GCM, AEAD_AES_256_GCM, implicit as its data integrity
MAC algorithm(s) and rejects all other MAC algorithm(s).
FCS_SSHC_EXT.1.7 The TSF shall ensure that ecdh-sha2-nistp256 and no other methods are the
only allowed key exchange methods used for the SSH protocol.
FCS_SSHC_EXT.1.8 The TSF shall ensure that within SSH connections, the same session keys are
used for a threshold of no longer than one hour, and each encryption key is used to protect no more
than one gigabyte of data. After any of the thresholds are reached, a rekey needs to be performed.
FCS_SSHC_EXT.1.9 The TSF shall ensure that the SSH client authenticates the identity of the SSH
server using a local database associating each host name with its corresponding public key and no
other methods as described in RFC 4251 section 4.1.
6.1.2.10 FCS_SSHS_EXT.1 SSH Server Protocol
FCS_SSHS_EXT.1.1 The TSF shall implement the SSH protocol that complies with RFC(s) 4251,
4252, 4253, 4254, 4256, 4344, 5647, 5656, 6668.
FCS_SSHS_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports the
following user authentication methods as described in RFC 4252: public key-based, password-based.
FCS_SSHS_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater than
262144 bytes in an SSH transport connection are dropped.
Security Target of Huawei A800 Series Routers
6 Security Functional
Requirements
FCS_SSHS_EXT.1.4 The TSF shall ensure that the SSH transport implementation uses the following
encryption algorithms and rejects all other encryption algorithms: aes128-ctr, aes256-ctr,
AEAD_AES_128_GCM, AEAD_AES_256_GCM, aes128-gcm@openssh.com,
aes256-gcm@openssh.com.
FCS_SSHS_EXT.1.5 The TSF shall ensure that the SSH public-key based authentication
implementation uses ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521 as its public key
algorithm(s) and rejects all other public key algorithms.
FCS_SSHS_EXT.1.6 The TSF shall ensure that the SSH transport implementation uses
hmac-sha2-256, AEAD_AES_128_GCM, AEAD_AES_256_GCM, implicit as its MAC algorithm(s)
and rejects all other MAC algorithm(s).
FCS_SSHS_EXT.1.7 The TSF shall ensure that ecdh-sha2-nistp256 and no other methods are the
only allowed key exchange methods used for the SSH protocol.
FCS_SSHS_EXT.1.8 The TSF shall ensure that within SSH connections, the same session keys are
used for a threshold of no longer than one hour, and each encryption key is used to protect no more
than one gigabyte of data. After any of the thresholds are reached, a rekey needs to be performed.
6.1.2.11 FCS_TLSC_EXT.1 TLS Client Protocol Without Mutual
Authentication
FCS_TLSC_EXT.1.1 The TSF shall implement TLS 1.2 (RFC 5246) and reject all other TLS and SSL
versions. The TLS implementation will support the following ciphersuites:
 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288
 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288
and no other ciphersuites
FCS_TLSC_EXT.1.2 The TSF shall verify that the presented identifier matches the reference
identifier per RFC 6125 section 6.
FCS_TLSC_EXT.1.3 When establishing a trusted channel, by default the TSF shall not establish a
trusted channel if the server certificate is invalid. The TSF shall also Not implement any administrator
override mechanism.
FCS_TLSC_EXT.1.4 The TSF shall not present the Supported Elliptic Curves Extension in the Client
Hello
6.1.3 Identification and Authentication (FIA)
6.1.3.1 FIA_AFL.1 Authentication Failure Management (Refinement)
FIA_AFL.1.1 The TSF shall detect when an Administrator configurable positive integer within 3
to 5 unsuccessful authentication attempts occur related to Administrators attempting to authenticate
remotely using a password.
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met, the
TSF shall prevent the offending Administrator from successfully establishing a remote session using
any authentication method that involves a password until action to unlock is taken by an
Administrator; prevent the offending Administrator from successfully establishing a remote session
using any authentication method that involves a password until an Administrator defined time period
has elapsed.
Security Target of Huawei A800 Series Routers
6 Security Functional
Requirements
6.1.3.2 FIA_PMG_EXT.1 Password Management
FIA_PMG_EXT.1.1 The TSF shall provide the following password management capabilities for
administrative passwords:
a) Passwords shall be able to be composed of any combination of upper and lower case letters,
numbers, and the following special characters: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“,
“)”, “-“, “+”, “=”, “[“, “]”, “{“, “}”, “|”, “\”, “,”, “.”, “/”, “<”, “>”, “;”, “:”, “””;
b) Minimum password length shall be configurable to between 8 and 128 characters.
6.1.3.3 FIA_UIA_EXT.1 User Identification and Authentication
FIA_UIA_EXT.1.1 The TSF shall allow the following actions prior to requiring the non-TOE entity
to initiate the identification and authentication process:
 Display the warning banner in accordance with FTA_TAB.1;
 ICMP echo.
FIA_UIA_EXT.1.2 The TSF shall require each administrative user to be successfully identified and
authenticated before allowing any other TSF-mediated actions on behalf of that administrative user.
6.1.3.4 FIA_UAU_EXT.2 Password-based Authentication Mechanism
FIA_UAU_EXT.2.1 The TSF shall provide a local password-based authentication mechanism to
perform local administrative user authentication.
6.1.3.5 FIA_UAU.7 Protected Authentication Feedback
FIA_UAU.7.1 The TSF shall provide only obscured feedback to the administrative user while the
authentication is in progress at the local console.
6.1.3.6 FIA_X509_EXT.1/Rev X.509 Certificate Validation
FIA_X509_EXT.1.1/Rev The TSF shall validate certificates in accordance with the following rules:
 RFC 5280 certificate validation and certification path validation supporting a minimum
path length of three certificates.
 The certification path must terminate with a trusted CA certificate designated as a trust
anchor.
 The TSF shall validate a certification path by ensuring that all CA certificates in the
certification path contain the basicConstraints extension with the CA flag set to TRUE.
 The TSF shall validate the revocation status of the certificate using a Certificate
Revocation List (CRL) as specified in RFC 5280 Section 6.3.
 The TSF shall validate the extendedKeyUsage field according to the following rules:
o Certificates used for trusted updates and executable code integrity verification shall
have the Code Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the
extendedKeyUsage field.
o Server certificates presented for TLS shall have the Server Authentication purpose (id-kp
1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field.
o Client certificates presented for TLS shall have the Client Authentication purpose (id-kp
2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field.
Security Target of Huawei A800 Series Routers
6 Security Functional
Requirements
o OCSP certificates presented for OCSP responses shall have the OCSP Signing purpose
(id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field.
FIA_X509_EXT.1.2/Rev The TSF shall only treat a certificate as a CA certificate if the
basicConstraints extension is present and the CA flag is set to TRUE.
6.1.3.7 FIA_X509_EXT.2 X.509 Certificate Authentication
FIA_X509_EXT.2.1 The TSF shall use X.509v3 certificates as defined by RFC 5280 to support
authentication for TLS and no additional uses.
FIA_X509_EXT.2.2 When the TSF cannot establish a connection to determine the validity of a
certificate; the TSF shall not accept the certificate.
6.1.4 Security Management (FMT)
6.1.4.1 FMT_MOF.1/ManualUpdate Management of security functions
behaviour
FMT_MOF.1.1/ManualUpdate The TSF shall restrict the ability to enable the functions to perform
manual updates to Security Administrators.
6.1.4.2 FMT_MOF.1/Functions Management of security functions
behaviour
FMT_MOF.1.1/Functions The TSF shall restrict the ability to determine the behaviour of, modify the
behaviour of the functions transmission of audit data to an external IT entity to Security
Administrators.
6.1.4.3 FMT_MOF.1/Services Management of security functions
behaviour
FMT_MOF.1.1/Services The TSF shall restrict the ability to start and stop the function services to
Security Administrators.
6.1.4.4 FMT_MTD.1/CoreData Management of TSF Data
FMT_MTD.1.1/CoreData The TSF shall restrict the ability to manage the TSF data to Security
Administrators.
6.1.4.5 FMT_MTD.1/CryptoKeys Management of TSF data
FMT_MTD.1.1/CryptoKeys The TSF shall restrict the ability to manage the cryptographic keys to
Security Administrators.
6.1.4.6 FMT_SMF.1 Specification of Management Functions
FMT_SMF.1.1 The TSF shall be capable of performing the following management functions:
 Ability to administer the TOE locally and remotely;
Security Target of Huawei A800 Series Routers
6 Security Functional
Requirements
 Ability to configure the access banner;
 Ability to configure the session inactivity time before session termination or locking;
 Ability to update the TOE, and to verify the updates using digital signature capability
prior to installing those updates;
 Ability to configure the authentication failure parameters for FIA_AFL.1;
 Ability to start and stop services;
 Ability to configure audit behaviour (e.g. changes to storage locations for audit; changes
to behaviour when local audit storage space is full);
 Ability to manage the cryptographic keys;
 Ability to configure thresholds for SSH rekeying;
 Ability to re-enable an Administrator account;
 Ability to set the time which is used for time-stamps;
 Ability to manage the TOE's trust store and designate X509.v3 certificates as trust
anchors;
 Ability to import X.509v3 certificates to the TOE's trust store;
 Ability to manage the trusted public keys database;
 No other capabilities
6.1.4.7 FMT_SMR.2 Restrictions on security roles
FMT_SMR.2.1 The TSF shall maintain the roles:
 Security Administrator.
FMT_SMR.2.2 The TSF shall be able to associate users with roles.
FMT_SMR.2.3 The TSF shall ensure that the conditions:
 The Security Administrator role shall be able to administer the TOE locally;
 The Security Administrator role shall be able to administer the TOE remotely
are satisfied.
6.1.5 Protection of the TSF (FPT)
6.1.5.1 FPT_SKP_EXT.1 Protection of TSF Data (for reading of all
pre-shared, symmetric and private keys)
FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys, and
private keys.
6.1.5.2 FPT_APW_EXT.1 Protection of Administrator Passwords
FPT_APW_EXT.1.1 The TSF shall store passwords in non-plaintext form.
FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext passwords.
Security Target of Huawei A800 Series Routers
6 Security Functional
Requirements
6.1.5.3 FPT_TST_EXT.1 TSF Testing (Extended)
FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests during initial start-up (on
power on) to demonstrate the correct operation of the TSF: integrity of the firmware and software
(software integrity check), the correct operation of cryptographic functions.
6.1.5.4 FPT_TUD_EXT.1 Trusted Update
FPT_TUD_EXT.1.1 The TSF shall provide Security Administrators the ability to query the currently
executing version of the TOE firmware/software and the most recently installed version of the TOE
firmware/software.
FPT_TUD_EXT.1.2 The TSF shall provide Security Administrators the ability to manually initiate
updates to TOE firmware/software and no other update mechanism.
FPT_TUD_EXT.1.3 The TSF shall provide means to authenticate firmware/software updates to the
TOE using a digital signature prior to installing those updates.
6.1.5.5 FPT_STM_EXT.1 Reliable Time Stamps
FPT_STM_EXT.1.1 The TSF shall be able to provide reliable time stamps for its own use.
FPT_STM_EXT.1.2 The TSF shall allow the Security Administrator to set the time.
6.1.6 TOE Access (FTA)
6.1.6.1 FTA_SSL_EXT.1 TSF-initiated Session Locking
FTA_SSL_EXT.1.1 The TSF shall, for local interactive sessions,
 terminate the session
after a Security Administrator-specified time period of inactivity.
6.1.6.2 FTA_SSL.3 TSF-initiated Termination (Refinement)
FTA_SSL.3.1 The TSF shall terminate a remote interactive session after a Security
Administrator-configurable time interval of session inactivity.
6.1.6.3 FTA_SSL.4 User-initiated Termination (Refinement)
FTA_SSL.4.1 The TSF shall allow Administrator-initiated termination of the Administrator’s own
interactive session.
6.1.6.4 FTA_TAB.1 Default TOE Access Banners (Refinement)
FTA_TAB.1.1 Before establishing an administrative user session the TSF shall display a Security
Administrator-specified advisory notice and consent warning message regarding use of the TOE.
Security Target of Huawei A800 Series Routers
6 Security Functional
Requirements
6.1.7 Trusted path/channels (FTP)
6.1.7.1 FTP_ITC.1 Inter-TSF Trusted Channel (Refinement)
FTP_ITC.1.1 The TSF shall be capable of using TLS to provide a trusted communication channel
between itself and authorized IT entities supporting the following capabilities: audit server, no
other capabilities that is logically distinct from other communication channels and provides assured
identification of its end points and protection of the channel data from disclosure and detection of
modification of the channel data.
FTP_ITC.1.2 The TSF shall permit the TSF or the authorized IT entities to initiate communication
via the trusted channel.
FTP_ ITC.1.3 The TSF shall initiate communication via the trusted channel for Syslog server over
TLS.
6.1.7.2 FTP_TRP.1/Admin Trusted Path (Refinement)
FTP_TRP.1.1/Admin The TSF shall be capable of using SSH to provide a communication path
between itself and authorized remote Administrators that is logically distinct from other
communication paths and provides assured identification of its end points and protection of the
communicated data from disclosure and provides detection of modification of the channel data.
FTP_TRP.1.2/Admin The TSF shall permit remote Administrators to initiate communication via the
trusted path.
FTP_TRP.1.3/Admin The TSF shall require the use of the trusted path for initial Administrator
authentication and all remote administration actions.
6.2 Assurance Security Requirements
The development and the evaluation of the TOE shall be done in accordance to the following security
assurance requirements:
Table 6-2 SecurityAssurance Requirements
Assurance Class Assurance Components
Security Target
(ASE)
Conformance claims (ASE_CCL.1)
Extended components definition (ASE_ECD.1)
ST introduction (ASE_INT.1)
Security objectives for the operational environment
(ASE_OBJ.1)
Stated security requirements (ASE_REQ.1)
Security Problem Definition (ASE_SPD.1)
TOE summary specification (ASE_TSS.1)
Security Target of Huawei A800 Series Routers
6 Security Functional
Requirements
Assurance Class Assurance Components
Development
(ADV)
Basic functional specification (ADV_FSP.1)
Guidance
documents
(AGD)
Operational user guidance (AGD_OPE.1)
Preparative procedures (AGD_PRE.1)
Life cycle
support (ALC)
Labeling of the TOE (ALC_CMC.1)
TOE CM coverage (ALC_CMS.1)
Tests (ATE) Independent testing – sample (ATE_IND.1)
Vulnerability
assessment (AVA)
Vulnerability survey (AVA_VAN.1)
This security target claims conformance with [CPP_ND]. In addition to [CEM], the
evaluation activities for [CPP_ND] are completed in [SD_ND].
6.3 SFR Rationale
The following table lists all SFRs contained in ST together with the classification whether
they are mandatory, optional or selection-based, indicates which are included in this ST and
provides a dependency rationale. Justifications for any unsupported dependencies will be
given in the table as well.
Table 6-3 Dependency rationale for SFRs
Requirement Dependencies Satisfied by
Mandatory Requirements
FAU_GEN.1 FPT_STM.1 FPT_STM_EXT.1 included (which
is hierarchic to FPT_STM.1)
FAU_GEN.2 FAU_GEN.1;
FIA_UID.1
FAU_GEN.1;
Satisfied by FIA_UIA_EXT.1,
which specifies the relevant
Administrator identification timing
FAU_STG_EXT.1 FAU_GEN.1;
FTP_ITC.1
FAU_GEN.1;
FTP_ITC.1
FCS_CKM.1 FCS_CKM.2 or FCS_COP.1;
FCS_CKM.4
FCS_CKM.2;
FCS_CKM.4
FCS_CKM.2 FTP_ITC.1 or FTP_ITC.2 or
FCS_CKM.1;
FCS_CKM.4
FCS_CKM.1 (also
FTP_ITC.1 as a secure
channel that could be used
for import);
FCS_CKM.4
FCS_CKM.4 FTP_ITC.1 or FTP_ITC.2 or
FCS_CKM.1
FCS_CKM.1 (also
FTP_ITC.1 as a secure
channel that could be used
for import)
FCS_COP.1/DataEncryption FTP_ITC.1 or FTP_ITC.2 or FCS_CKM.1 (also
Security Target of Huawei A800 Series Routers
6 Security Functional
Requirements
Requirement Dependencies Satisfied by
FCS_CKM.1;
FCS_CKM.4
FTP_ITC.1 as a secure
channel that could be used
for import);
FCS_CKM.4
FCS_COP.1/SigGen FTP_ITC.1 or FTP_ITC.2 or
FCS_CKM.1;
FCS_CKM.4
FCS_CKM.1 (also
FTP_ITC.1 as a secure
channel that could be used
for import);
FCS_CKM.4
FCS_COP.1/Hash FTP_ITC.1 or FTP_ITC.2 or
FCS_CKM.1;
FCS_CKM.4
Unsupported Dependencies: This
SFR specifies keyless hashing
operations, so initialisation and
destruction of keys are not relevant
FCS_COP.1/KeyedHash FTP_ITC.1 or FTP_ITC.2 or
FCS_CKM.1;
FCS_CKM.4
FCS_CKM.1 (also
FTP_ITC.1 as a secure
channel that could be used
for import);
FCS_CKM.4
FCS_RBG_EXT.1 None N/A
FIA_AFL.1 FIA_UAU.1 Satisfied by FIA_UIA_EXT.1,
which specifies the relevant
Administrator authentication
FIA_PMG_EXT.1 None N/A
FIA_UIA_EXT.1 FTA_TAB.1 FTA_TAB.1
FIA_UAU_EXT.2 None N/A
FIA_UAU.7 FIA_UAU.1 Satisfied by FIA_UIA_EXT.1,
which specifies the relevant
Administrator authentication
FMT_MOF.1/ManualUpdate FMT_SMR.1;
FMT_SMF.1
FMT_SMR.2;
FMT_SMF.1
FMT_MTD.1/CoreData FMT_SMR.1;
FMT_SMF.1
FMT_SMR.2;
FMT_SMF.1
FMT_SMF.1 None N/A
FMT_SMR.2 FIA_UID.1 Satisfied by FIA_UIA_EXT.1,
which specifies the relevant
Administrator identification
FPT_SKP_EXT.1 None N/A
FPT_APW_EXT.1 None N/A
FPT_TST_EXT.1 None N/A
FPT_TUD_EXT.1 FCS_COP.1/SigGen or
FCS_COP.1/Hash
FCS_COP.1/SigGen and
FCS_COP.1/Hash
FPT_STM_EXT.1 None N/A
FTA_SSL_EXT.1 FIA_UAU.1 Satisfied by FIA_UIA_EXT.1,
which specifies the relevant
Administrator identification
FTA_SSL.3 None N/A
FTA_SSL.4 None N/A
FTA_TAB.1 None N/A
FTP_ITC.1 None N/A
FTP_TRP.1/Admin None N/A
Optional Requirements
Security Target of Huawei A800 Series Routers
6 Security Functional
Requirements
Requirement Dependencies Satisfied by
FAU_STG.1 FAU_STG.3 FAU_STG_EXT.3/LocSpace
FAU_STG_EXT.3/LocSpace FAU_STG.1 FAU_STG.1
Selection-Based Requirements
FCS_SSHC_EXT.1 FCS_CKM.1;
FCS_CKM.2;
FCS_COP.1/DataEncryption;
FCS_COP.1/SigGen;
FCS_COP.1/Hash;
FCS_COP.1/KeyedHash;
FCS_RBG_EXT.1:
FCS_CKM.1;
FCS_CKM.2;
FCS_COP.1/DataEncryption;
FCS_COP.1/SigGen;
FCS_COP.1/Hash;
FCS_COP.1/KeyedHash;
FCS_RBG_EXT.1:
FCS_SSHS_EXT.1 FCS_CKM.1;
FCS_CKM.2;
FCS_COP.1/DataEncryption;
FCS_COP.1/SigGen;
FCS_COP.1/Hash;
FCS_COP.1/KeyedHash;
FCS_RBG_EXT.1:
FCS_CKM.1;
FCS_CKM.2;
FCS_COP.1/DataEncryption;
FCS_COP.1/SigGen;
FCS_COP.1/Hash;
FCS_COP.1/KeyedHash;
FCS_RBG_EXT.1:
FCS_TLSC_EXT.1 FCS_CKM.1;
FCS_CKM.2;
FCS_COP.1/DataEncryption;
FCS_COP.1/SigGen;
FCS_COP.1/Hash;
FCS_COP.1/KeyedHash;
FCS_RBG_EXT.1:
FCS_CKM.1;
FCS_CKM.2;
FCS_COP.1/DataEncryption;
FCS_COP.1/SigGen;
FCS_COP.1/Hash;
FCS_COP.1/KeyedHash;
FCS_RBG_EXT.1:
FIA_X509_EXT.1/Rev FIA_X509_EXT.2; FIA_X509_EXT.2;
FIA_X509_EXT.2 FIA_X509_EXT.1; FIA_X509_EXT.1/Rev;
FMT_MOF.1/Services FMT_SMR.1;
FMT_SMF.1
FMT_SMR.2;
FMT_SMF.1
FMT_MOF.1/Functions FMT_SMR.1;
FMT_SMF.1
FMT_SMR.2;
FMT_SMF.1
FMT_MTD.1/CryptoKeys FMT_SMR.1;
FMT_SMF.1
FMT_SMR.2;
FMT_SMF.1
Security Target of Huawei A800 Series Routers 7 TOE Summary Specification
7 TOE Summary Specification
7.1 Security Audit (FAU)
7.1.1 FAU_GEN.1 Audit data generation
The TOE generates an audit record whenever an audited event occurs. The types of events that cause
audit records to be generated include identification and authentication related events, and
administrative events (the specific events and the contents of each audit record are listed in the table
within the FAU_GEN.1 SFR, “Table 6-1 Security Functional Requirements and Auditable Events”).
Each of the events specified in the audit record is in enough detail to identify the user for which the
event is associated (e.g. user identity, MAC address, IP address), when the event occurred, where the
event occurred, the outcome of the event, and the type of event that occurred.
The audit trail consists of the individual audit records; one audit record for each event that occurred.
The audit record contains a lot of information, such as the type of event that occurred, and two
percent signs (%%), which follows the device name. As noted above, the information includes at least
all of the required information. Additional information can be configured and included if desired.
Administrators have the ability to execute CLI commands to generate/import of/delete cryptographic
keys, each command will generate a log and will be stored in log file. The log contains the user name
and IP address. The log does not contain the generated key information.
7.1.2 FAU_GEN.2 User identity association
Each auditable event is associated with the user that triggered the event and as a result, they are
traceable to a specific user. For example, a human user, user identity or related session ID would be
included in the audit record. For an IT entity or device, the IP address, MAC address, host name, or
other configured identification is presented.
Security Target of Huawei A800 Series Routers 7 TOE Summary Specification
The security log of user account management should include user name. Other types of security log
have other rules about the information.
7.1.3 FAU_STG.1 Protected audit trail storage
Only authorized administrators can monitor the logfile record, and operate the log files. The
unauthorized users have no access rights to perform these actions. All actions of the authorized
administrators will be logged. The default maximum size is 8 MB for a common log file, 4 MB for a
security log file, and 4 MB for an operation log file.
7.1.4 FAU_STG_EXT.1 Protected audit event storage
The TOE supports the export of syslog records to a specified, external syslog server. The TOE
protects communications with an external syslog server via TLS. The TOE stores audit records on
flash memory whenever it is connected with syslog server or not. The transmission of audit
information to an external syslog server can be done in real-time.
The size of an information file is configurable by the administrator with value 4M/8M/16M/32M
bytes. The default maximum size of each information file is 8 MB. When the size of an information
file exceeds the configured maximum size, the information file is compressed into a smaller file in
standard log_slot ID_time.log.zip format. The maximum quantity of compressed files is configurable
by the administrator with a value ranging from 3 to 500. A maximum of 200 files can be stored on a
device by default. The unauthorized users are disallowed to handle the audit records.
The logs are saved to flash memory so records can’t be lost in case of failures or restarts. The log
buffer is circular, so newer messages overwrite older messages after the buffer is full. Administrators
are instructed to monitor the log buffer using the show logging privileged CLI command to view the
audit records. The first message displayed is the oldest message in the buffer. There are other
associated commands to clear the buffer, to reset log buffer, etc. The size of the log buffer can be
configured by users with sufficient privileges.
When the local audit data stored in flash memory exceeds the maximum allowed size of log file
storage, it will always overwrite the oldest log information.
An administrator cannot alter audit records but can delete audit records as a whole.
7.1.5 FAU_STG_EXT.3/LocSpace Action in case of possible
audit data loss
If the log files have already occupied more than 80% of the total audit storage in CF card, or delete
Security Target of Huawei A800 Series Routers 7 TOE Summary Specification
the old log files after saving them to the other storage device, an event will be generated and sent to
management server to notice the clients of the warning information.
If the number of compressed log files generated in the system exceeded 80% of the maximum number
of compressed files, an event will also be generated to notice net-manager the warning information.
If the number of recorded compressed files reach the maximum number that the security
administrator has configured, or the storage with audit events reach the configured storage size,
another event will be generated to notice NMS.
7.2 Cryptographic Support (FCS)
7.2.1 FCS_CKM.1 Cryptographic Key Generation
The TOE supports
1) FFC schemes using cryptographic key sizes of 3072-bit or greater that meet the following: FIPS PUB
186-4, “Digital Signature Standard (DSS)”, Appendix B.1. The FFC schemes is used for TLS.
2) ECC schemes using “NIST curves” P-256, P-384, P-521 that meet the following: FIPS PUB 186-4,
“Digital Signature Standard (DSS)”, Appendix B.4. The ECC schemes is used for SSH.
7.2.2 FCS_CKM.2 Cryptographic Key Establishment
The TOE supports Elliptic curve-based key establishment schemes that meet the following: NIST Special
Publication 800-56A Revision 2, “Recommendation for Pair-Wise Key Establishment Schemes Using
Discrete Logarithm Cryptography”. The key size supports at least 256 bits. The TOE establishes a SSH
connection based on Elliptic curve-based key establishment schemes. The Elliptic curve-based key
establishment schemes is used when the TOE establishes SSH connection.
The TOE supports Finite field-based key establishment schemes that meet the following: NIST Special
Publication 800-56A Revision 2, “Recommendation for Pair-Wise Key Establishment Schemes Using
Discrete Logarithm Cryptography”. The key size supports at least 3072 bits. The Finite field-based key
establishment schemes is used when the TOE establishes TLS connection.
Scheme SFR Service
DHE FCS_TLSC_EXT.1 Audit
ECDH FCS_SSHS_EXT.1 Administration
Security Target of Huawei A800 Series Routers 7 TOE Summary Specification
ECDH FCS_SSHC_EXT.1 Administration
7.2.3 FCS_CKM.4 Cryptographic Key Destruction
The private key stored in SDRAM is used to verify the integrity of the certificate. After the device is
restarted, the private key is imported into the SDRAM from the CF card. The private key is encrypted
by the AES key and stored on the CF card. Users and administrator cannot access the private key that
is stored in the SDRAM and CF card.
Table 7-1 Key Destructions
Name Description of Key Storage Key destruction method
SSH/TLS
session
key
The key is used for
encrypting/decrypting the
traffic in a secure connection.
SDRAM
(plaintext)
Automatically after session
terminated.
Overwritten with: zeroes.
FFC key The key is used for key
establishment.
SDRAM
(plaintext)
Automatically after completion of
use of the key.
Overwritten with: zeroes.
TLS
private key
The key is used for signature
and authentication.
CF card
(AES256
cipher)
Overwritten by a command.
Overwritten with: a new value of the
key.
ECC key
pair
The ECC key pair is used for
digital signature. The ECC host
key pair is imported into the
SDRAM from the CF card,
which is the ECC key pair.
SDRAM
(plaintext)
Automatically after completion of
use of the key.
Overwritten with: zeroes.
ECC host
key pair
Using command generate a
ECC host key pair.
CF card
(AES256
cipher)
Zeroized using “ecc local-key-pair
destroy” command.
Overwritten with: zeroes.
AES key The AES key is generated by
root key. AES key is used to
encrypt ECC host key pair and
TLS private key.
Note: The root key is generated
by root key material. The root
SDRAM
(plaintext)
The AES key is stored in the
SDRAM temporarily and destroyed
after used. Overwritten with: zeroes.
Security Target of Huawei A800 Series Routers 7 TOE Summary Specification
key material is saved many
places, for example: code.
7.2.4 FCS_COP.1/DataEncryption Cryptographic Operation
(AES Data Encryption/ Decryption)
The TOE provides symmetric encryption and decryption capabilities using AES as specified in ISO
18033-3 supporting the following modes:
 CTR mode as specified in ISO 10116.
 GCM mode as specified in ISO 19772.
The TOE uses AES in the following protocols:
 SSH: CTR mode with key sizes of 128 bits and 256 bits. GCM mode with key sizes of 128 bits and
256 bits.
 TLS: GCM mode with key sizes of 128 bits and 256 bits.
7.2.5 FCS_COP.1/SigGen Cryptographic Operation
(Signature Generation and Verification)
The TOE provides cryptographic signature services using RSA with key sizes between 3072 and
4096 bits as specified in FIPS PUB 186-4 “Digital Signature Standard (DSS)”.
 The RSA with key size of 3072 to 4096 is used for signature generation and verification of
TLS.
The TOE provides cryptographic signature services using ECDSA with key sizes between 256 bits,
384 bits and 521 bits as specified in FIPS PUB 186-4 “Digital Signature Standard (DSS)”.
 The ECDSA with key size 256 bits, 384 bits and 521 bits is used for signature generation
and verification of SSH.
The TOE provides cryptographic signature services using RSA with key sizes 4096 bits as specified
in FIPS PUB 186-4 “Digital Signature Standard (DSS)”.
 The RSA with key size of 4096 is used for signature verification of Secure Update.
Security Target of Huawei A800 Series Routers 7 TOE Summary Specification
7.2.6 FCS_COP.1/Hash Cryptographic Operation (Hash
Algorithm)
The TOE provides cryptographic hashing services using SHA-256, and SHA-384 as specified in FIPS
Pub 180-3 “Secure Hash Standard.”, it also meets the ISO/IEC 10118-3:2004.
The association of the hash function with other TSF cryptographic functions is:
Table 7-2 Usage of Hash Algorithm
Cryptographic Functions Hash Function
HMAC-SHA-256 SHA-256
TLS Digital signature verification SHA-256
SHA-384
SSH Digital signature verification SHA-256
Hash_DRBG SHA-256
7.2.7 FCS_COP.1/KeyedHash Cryptographic Operation
(Keyed Hash Algorithm)
The TOE provides cryptographic keyed hash services using HMAC-SHA-256 according to RFC2104:
HMAC, it also complies with the ISO/IEC 9797-2:2011, Section 7 “MAC Algorithm 2”.
Table 7-3 Specification of Keyed Hash Algorithm
HMAC function Key length
(bits)
Hash function Block size
(bits)
Output MAC
length (bits)
HMAC-SHA-256 256 SHA-256 512 256
7.2.8 FCS_RBG_EXT.1 Random Bit Generation
The TOE implements a deterministic random bit generator (DRBG) which is conformant to
[ISO18031] using the DRBG mechanism Hash_DRBG as specified in [SP800-90A], chap. 10.1.1.
The entropy source is based on hardware (internal noise source). Random numbers from the internal
noise source are only used for seeding the DRBG.
Security Target of Huawei A800 Series Routers 7 TOE Summary Specification
Before generating random bits as the cryptographic key, the TOE sets a new seed using at least 256 of
entropy.
DRBG parameters are predefined for the TOE and cannot be modified. Prediction resistance is
disabled for the DRBG in the TOE.
7.2.9 FCS_SSHC_EXT.1 SSH Client Protocol
7.2.9.1 FCS_SSHC_EXT.1.1
The TOE implements the SSH protocol that comply with RFCs 4251, 4252, 4253, 4254, 4256, 4344,
5647, 5656, 6668.
7.2.9.2 FCS_SSHC_EXT.1.2
Both public key and password authentication modes are supported by SSH client function. Users can
use any or both of those modes to login external SSH server successfully.
The supported public key algorithms for authentication include ECC with cryptographic key size of
256-bit, 384-bit and 521-bit. These public key algorithm conforms to FCS_SSHC_EXT.1.5.
7.2.9.3 FCS_SSHC_EXT.1.3
The TOE drops packets greater than 256 KB in an SSH transport connection. Packets of size greater
than 35000 bytes and smaller than 256 KB are not dropped. Because of that the TOE may support
uncompressed big certificates.
7.2.9.4 FCS_SSHC_EXT.1.4
The SSH client supports the encryption algorithms of aes128-ctr and aes256-ctr,
AEAD_AES_128_GCM, AEAD_AES_256_GCM, aes128-gcm@openssh.com and
aes256-gcm@openssh.com.
When SSH Client establishes a connection, it will send a list of encryption algorithms to SSH server.
SSH Server will check each algorithm in the list one by one. If it finds one algorithm in the list that is
also supported by it, this algorithm will be chosen as the encryption algorithm between client and
server. If no algorithm in the list is supported by SSH server, the connection will be terminated.
After the encryption algorithm is selected, Server and Client will create a random number and
exchange. Client and Server will use their own random number to create an encryption key.
Security Target of Huawei A800 Series Routers 7 TOE Summary Specification
Then, the SSH Client will use its own encryption key to encrypt each packet, and use SSH Server’s
encryption key to decrypt each packet.
7.2.9.5 FCS_SSHC_EXT.1.5
SSH client function supports the public key algorithm of ecdsa-sha2-nistp256, ecdsa-sha2-nistp384,
ecdsa-sha2-nistp521.
Before SSHC and SSHS build a connection, they both need to configure a local key-pair that is used
for authentication. In Huawei’s device, this local key-pair is used for SSH server and SSH client.
The first step to be done/taken when a Client authenticates a Server, is to consult public key
algorithms. Client will send a list of public key algorithms to SSH server. SSH Server will check each
algorithm in the list one by one. If it finds one algorithm in the list that is also supported by it, this
algorithm will be chosen as the public key algorithm between client and server. If no algorithm in the
list is supported by SSH server, the connection will be terminated.
7.2.9.6 FCS_SSHC_EXT.1.6
SSH client supports the data integrity algorithms of hmac-sha2-256, AEAD_AES_128_GCM and
AEAD_AES_256_GCM.
AEAD_AES_128_GCM and AEAD_AES_256_GCM will be selected as MAC algorithms when the
same algorithm is being used as the encryption algorithm. When aes*-gcm@openssh.com is
negotiated as the encryption algorithm, the negotiated MAC might be decoded as “implicit”.
7.2.9.7 FCS_SSHC_EXT.1.7
SSH client supports the following key exchange algorithm of ecdh-sha2-nistp256.
7.2.9.8 FCS_SSHC_EXT.1.8
The SSH connection will be rekeyed after one hour of session time or one gigabyte of transmitted
data using that key whichever comes first.
The SSH allows either side to force another run of the key-exchange phase, changing the encryption
and integrity keys for the session. The idea is to do this periodically, after one hour of session time or
one gigabyte of transmitted data using that key whichever comes first.
7.2.9.9 FCS_SSHC_EXT.1.9
The SSH client will authenticate the identity of the SSH server using a local database associating each
Security Target of Huawei A800 Series Routers 7 TOE Summary Specification
host name with its corresponding public key.
7.2.10 FCS_SSHS_EXT.1 SSH Server Protocol
7.2.10.1 FCS_SSHS_EXT.1.1
The TOE implements the SSH protocol that complies with RFCs 4251, 4252, 4253, 4254, 4256, 4344,
5647, 5656, 6668.
7.2.10.2 FCS_SSHS_EXT.1.2
Both public key and password authentication modes are supported by SSH server function. The TOE
implements the public key algorithms of ecdsa-sha2-nistp256, ecdsa-sha2-nistp384 and
ecdsa-sha2-nistp521.
SSH users can be authenticated in eight modes: ECC, password, password-ECC, and All (any
authentication mode of ECC or password is allowed with “ALL” mode). The SSH user that is created
by administrators shall be configured to one of the modes. Then the external SSH client can login
SSH server successfully via the configured SSH user and authentication mode.
7.2.10.3 FCS_SSHS_EXT.1.3
The TOE drops packets greater than 256 KB in an SSH transport connection. Packets of size greater
than 35000 bytes and smaller than 256 KB are not dropped. Because of that the TOE may support
uncompressed big certificates.
7.2.10.4 FCS_SSHS_EXT.1.4
SSH server function supports the encryption algorithms of aes128-ctr, aes256-ctr,
AEAD_AES_128_GCM, AEAD_AES_256_GCM, aes128-gcm@openssh.com and
aes256-gcm@openssh.com.
When SSH Client establishes a connection, it will send a list of encryption algorithms to SSH server.
SSH Server will check each algorithm in the list one by one. If it finds one algorithm in the list that is
also supported by it, this algorithm will be chosen as the encryption algorithm between client and
server. If no algorithm in the list is supported by SSH server, the connection will be terminated.
After the encryption algorithm is selected, Server and Client will create a random number and
exchange. Client and Server will use their own random number to create an encryption key.
Then, the SSH server will use its own encryption key to encrypt each packet, and use SSH client’s
encryption key to decrypt each packet.
Security Target of Huawei A800 Series Routers 7 TOE Summary Specification
7.2.10.5 FCS_SSHS_EXT.1.5
SSH server function supports the public key algorithm of ecdsa-sha2-nistp256, ecdsa-sha2-nistp384,
ecdsa-sha2-nistp521.
Before SSHC and SSHS build a connection, they both need to configure a local key-pair that is used
for authentication. In Huawei’s device, this local key-pair is used for SSH server and SSH client.
The first step to be done/taken when a Client authenticates a Server, is to consult public key
algorithms. Client will send a list of public key algorithms to SSH server. SSH Server will check each
algorithm in the list one by one. If it finds one algorithm in the list that is also supported by it, this
algorithm will be chosen as the public key algorithm between client and server. If no algorithm in the
list is supported by SSH server, the connection will be terminated.
7.2.10.6 FCS_SSHS_EXT.1.6
SSH server function supports the data integrity algorithms of hmac-sha2-256 ,
AEAD_AES_128_GCM and AEAD_AES_256_GCM.
AEAD_AES_128_GCM and AEAD_AES_256_GCM will be selected as MAC algorithms when the
same algorithm is being used as the encryption algorithm. When aes*-gcm@openssh.com is
negotiated as the encryption algorithm, the negotiated MAC might be decoded as “implicit”.
7.2.10.7 FCS_SSHS_EXT.1.7
SSH server supports the following key exchange algorithm: ecdh-sha2-nistp256.
7.2.10.8 FCS_SSHS_EXT.1.8
The SSH connection will be rekeyed after one hour of session time or one gigabyte of transmitted
data using that key whichever comes first.
The SSH allows either side to force another run of the key-exchange phase, changing the encryption
and integrity keys for the session. The idea is to do this periodically, after one hour of session time or
one gigabyte of transmitted data using that key whichever comes first.
Security Target of Huawei A800 Series Routers 7 TOE Summary Specification
7.2.11 FCS_TLSC_EXT.1 TLS Client Protocol Without Mutual
Authentication
7.2.11.1 FCS_TLSC_EXT.1.1
The TLS client supports the following ciphersuites:
 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288
 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288
7.2.11.2 FCS_TLSC_EXT.1.2
The reference identifier is established by the user and by an application (a parameter of an API).
Based on a singular reference identifier’s source domain and application service type (e.g. syslog),
the client establishes all reference identifiers including DNS names(case-insensitive) for the Subject
Alternative Name field. The client then compares this list of all acceptable reference identifiers to the
presented identifiers in the TLS server’s certificate.
The TOE doesn’t support certificate pinning and use of wildcards in digital certificates. The TOE
doesn’t support to use IP addresses in digital certificates.
7.2.11.3 FCS_TLSC_EXT.1.3
When establishing a trusted channel, by default the TSF shall not establish a trusted channel if the
server certificate is invalid. The TSF shall also not implement any administrator override mechanism.
7.2.11.4 FCS_TLSC_EXT.1.4
TLS don’t support EC Extension in the Client Hello
7.3 Identification and Authentication (FIA)
7.3.1 FIA_AFL.1 Authentication Failure Management
Administrators can configure TOE’s session lock time and number of unsuccessful authentication
attempts from 3 to 5. When the defined number of unsuccessful authentication attempts has been met,
the TOE will prevent the offending remote Administrator from successfully authenticating before the
lock time or unlock is taken by a local Administrator or prevent the offending remote Administrator
from successfully authenticating until an Administrator defined time period has elapsed.
Security Target of Huawei A800 Series Routers 7 TOE Summary Specification
To ensure account and password security of the administrators, the account locking function is
enabled for administrators who fail remote authentication.
When an account logs in to the device within a specified period and the password is incorrect, the
number of login failures of the account is recorded. When the number of login failures of the account
reaches the upper limit (3 by default), the account is locked (the default locking duration is 5 minutes).
After a certain period, the account is unlocked.
7.3.2 FIA_PMG_EXT.1 Password Management
The TOE supports the local definition of users with corresponding passwords which are used for
security administrators’ authentication of local or remote administration connections. The passwords
can be composed of any combination of upper and lower case letters, numbers, and special characters
(not including spaces, question marks or single quotation mark). Minimum password length is
settable by the Authorized Administrator, and passwords 8 characters or greater (maximum 128
characters) are supported. Password composition rules specifying the types and number of required
characters that comprise the password are settable by the Authorized Administrator. Passwords have a
maximum lifetime, configurable by the Authorized Administrator.
7.3.3 FIA_UIA_EXT.1 User Identification and Authentication
The TOE requires all users to be successfully identified and authenticated before allowing execution
of any TSF mediated action except display of the banner and ICMP echo service.
Success-logon includes user-name, connect-type, IP-address, authentication-status, and so on.
The TOE supports user login over console or remote interface. Any login method needs
authentication before a successful logon.
Local access is achieved by console port. Local authentication supports password-based
authentication.
Remote access is achieved by SSH. It also supports associated identity authentication of password
and public-key. Users can also login with any of the identity authentication modes of password, and
ECC when their login mode is configured to be ‘ALL’.
7.3.4 FIA_UAU_EXT.2 Password-based Authentication
Mechanism
The TOE can be configured to require local authentication or remote authentication as defined in the
Security Target of Huawei A800 Series Routers 7 TOE Summary Specification
authentication policy for interactive (human) users.
The policy for interactive (human) users (Administrators) can be authenticated to the local user
database, or have redirection to a remote authentication server. Interfaces can be configured to try one
or more remote authentication servers, and then fail back to the local user database if the remote
authentication servers are inaccessible.
If the interactive (human) users (Administrators) password is expired, the user is required to create a
new password after correctly entering the expired password.
7.3.5 FIA_UAU.7 Protected Authentication Feedback
When a user inputs their password at the local console, the console will not display the input so that
the user password is obscured. For remote session authentication, the TOE does not echo any
characters as they are entered. The TOE does not provide any additional information to the user that
would give any indication about the authentication data.
7.3.6 FIA_X509_EXT.1/Rev X.509 Certificate Validation
The TOE supports the verification of the certificate and the certificate path by the rules specified in
RFC 5280, using algorithm RSA.
The TOE supports the verification of the revocation status by CRLs as specified in RFC 5280.When
the client receives TLS Handshake's Server Certificate message, the client will check validation of the
certificates and certificate revocation list. When an administrator imports a certificate, the TOE will
check certificate integrity and validation of the certificates.
The TOE validates a certificate path by ensuring the presence of the basicConstraints extension and
that the CA flag is set to TRUE for all CA certificates.
The TSF validates the extendedKeyUsage field according to the following rules:
 Certificates used for trusted updates and executable code integrity verification shall have the
Code Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field.
 Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with
OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field.
 Client certificates presented for TLS shall have the Client Authentication purpose (id-kp 2 with
OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field.
 OCSP certificates presented for OCSP responses shall have the OCSP Signing purpose (id-kp 9
Security Target of Huawei A800 Series Routers 7 TOE Summary Specification
with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field.
The TOE does not implements OCSP, so the id-kp-9 is not supported by the TOE. The TOE only
acts as a client which only receives Server certificates, so the id-kp-2 is not supported by the TOE.
The TOE does not use X509 certificates for the TOE updating, so the id-kp-3 is not supported by
the TOE.
7.3.7 FIA_X509_EXT.2 X.509 Certificate Authentication
The certificate used by TLS authentication is sent by the TLS server. The CRL should be loaded for
certificate validation.
The TOE will send a security log when a connection cannot be established during the validity check
of a certificate used in establishing a trusted channel. TLS only supports RSA certificate.
The check of validity of the certificates takes place at the authentication of the TLS connection. When
the certificate is valid, we can trust the peer identity and use the certificate to verify the integrity of
the message.
TOE chooses a certificate which was configured by CLI for services (such as Syslog).
When the TSF cannot establish a connection to determine the validity of a certificate; the TSF shall
not accept the certificate when all other checks pass in FIA_X509_EXT.1.
7.4 Security management (FMT)
7.4.1 FMT_MOF.1/ManualUpdate
The TSF shall restrict the ability to enable the functions to perform manual updates to Security
Administrators.
Only administrators have the right to create or delete local users. When changing the local user
privilege level, the configured new level of the local user cannot be higher than that of the login-in
user. This way, no user except administrators can change another user to be at the privilege level of
administrator. And only administrators have the ability to perform manual update. So the manual
update is restricted to administrators. The TOE uses groups to organize users. Different kinds of users
are in different groups and every group has a specific level that identifies its roles and scope of rights.
Security Target of Huawei A800 Series Routers 7 TOE Summary Specification
7.4.2 FMT_MOF.1/Functions Management of security
functions behaviour
Only administrators have the privilege to choose a trusted channel for transmitting the audit data to an
external IT entity. A user with no administrator privileges cannot configure and enable the info-center
function.
7.4.3 FMT_MOF.1/Services Management of security
functions behaviour
Only administrators have ability to enable and disable the functions and services, the other users are
disallowed to do it. The functions and services include “info-center loghost”, “undo info-center
loghost”, “info-center loghost source”, “undo info-center loghost source” , “sftp server enable”,
“undo sftp server enable”, for more please refer to the AGD.
7.4.4 FMT_MTD.1/CoreData Management of TSF Data
Only administrators have privilege to manage the TSF data, the other users are disallowed to do it.
The TOE provides the ability for authorized administrators to access TOE data, such as audit data and
configuration data. Each of the predefined and administratively configured users have different rights
to access the TOE data.
The access control mechanisms of the TOE are based on hierarchical access levels where a user level
is associated with every user and terminal on the one hand, and a command level is associated with
every command. Only if the user level is equal or higher to a specific command, authorizes the user to
execute this command. Management of security function is realized through commands. So for every
management function sufficient user level is required for the user to be able to execute the
corresponding command.
7.4.5 FMT_MTD.1/CryptoKeys Management of TSF data
Only administrators have the right to delete and/or import the cryptographic keys (such as ecc key,
rsa key), the other users are disallowed to do this.
7.4.6 FMT_SMF.1 Specification of Management Functions
The TOE provides all the capabilities necessary to securely manage the TOE. The administrative user
can connect to the TOE using the CLI to perform these functions via SSH encrypted session.
The management functionality provided by the TOE includes the following administrative functions:
Security Target of Huawei A800 Series Routers 7 TOE Summary Specification
 Ability to manage the TOE locally as well as remotely;
 Ability to configure the access banner;
 Ability to configure the session inactivity time before session termination or locking;
 Ability to update the TOE, and to verify the updates using digital signature capability
prior to installing those updates;
 Ability to configure the authentication failure parameters for FIA_AFL.1;
 Ability to start and stop services;
 Ability to configure audit behaviour (e.g. changes to storage locations for audit; changes
to behaviour when local audit storage space is full);
 Ability to manage the cryptographic keys;
 Ability to configure thresholds for SSH rekeying;
 Ability to re-enable an Administrator account;
 Ability to set the time which is used for time-stamps;
 Ability to manage the TOE's trust store and designate X509.v3 certificates as trust
anchors;
 Ability to import X.509v3 certificates to the TOE's trust store;
 Ability to manage the trusted public keys database;
 No other capabilities
7.4.7 FMT_SMR.2 Restrictions on security roles
A Security Administrator is able to administer the TOE through the local console or through a remote
mechanism.
An administrator can create, delete and modify the other users and endow them with a proper level of
rights according to the users’ roles. The TOE uses groups to organize users. Different kinds of users
are in different groups and every group has a specific level that identifies its roles and scope of rights.
Every user in one group has the same scope of rights that the group owns. The TOE has 4 default user
groups: manage-ug, system-ug, monitor-ug, and visitor-ug.
7.5 Protection of the TSF (FPT)
7.5.1 FPT_SKP_EXT.1 Protection of TSF Data (for reading of all
symmetric keys)
The TOE stores all symmetric keys, and private keys in SDRAM that can’t be read, copied or
extracted by administrators; hence no interface access.
Security Target of Huawei A800 Series Routers 7 TOE Summary Specification
7.5.2 FPT_APW_EXT.1 Protection of Administrator Passwords
The administrator passwords are stored to a configuration file in cryptographic form hashed with salt
by SHA-256, including username passwords, authentication passwords, console and virtual terminal
line access passwords.
In this manner, the TOE ensures that plaintext user passwords will not be disclosed to anyone through
normal interfaces including administrators.
7.5.3 FPT_TST_EXT.1 TSF testing
The TSF runs a suite of self-tests during initial start-up to demonstrate the correct operation of the
TSF, including software integration verification by integrity check and the correct operation of
cryptographic functions. During initial start-up, software integrity is checked at first. If integrity
check is failed, the start-up procedure will stop. Then the correct operation of cryptographic functions
is tested. If this testing fails, the start-up procedure will also stop.
Self-tests include cryptographic algorithm known answer test and software integrity test:
• AES Known Answer Test
• HMAC Known Answer Test
• DRBG Known Answer Test
• SHA256/384 Known Answer Test
• RSA Signature Known Answer Test
• DHE Known Answer Test
• ECDH Known Answer Test
• ECDSA Known Answer Test
• Software Integrity Test: The hash value of software is stored in file header, the Integrity Test
performs a hash function of the software and compares the result stored in file header.
7.5.4 FPT_TUD_EXT.1 Trusted Update
Only authenticated administrators have the ability to manually initiate an update to TOE
firmware/software. During the updating procedure, digital signature as defined at FCS_COP.1/SigGen
will be verified by the TOE at first.
Security Target of Huawei A800 Series Routers 7 TOE Summary Specification
The administrators can query the currently executing version of the TOE firmware/software as well as
the most recently installed version by a command. The currently executing patches and most recently
installed patches can also be checked out.
The validation of the firmware/software integrity is always performed before the process of replacing
a non-volatile, system resident software component with another is initiated. All discrete software
components (e.g. applications, drivers, kernel, and firmware) of the TSF are archived together into a
whole package and the single package is digitally signed. RSA as specified in FCS COP.1/SigGen
can be used for the firmware/software digital signature mechanism to authenticate it prior to
installation and that installation fails if the verification fails.
When the digital signature is successfully verified, the new software will be installed successfully and
become active when the TOE reboots.
When the digital signature verification fails, the new software will not be installed.
7.5.5 FPT_STM_EXT.1 Reliable Time Stamps
Only administrators have the ability to modify the time of TOE, and all modifications affecting time
will be recorded. Time accuracy is guaranteed by the administrator for the first time and by the CPU
in the long run.
The security functions that make use of time include:
1) The calculation of the real time for all audit data.
2) The calculation of the validation period of the certificate.
7.6 TOE Access (FTA)
7.6.1 FTA_SSL_EXT.1 TSF-initiated Session Locking
An administrator can configure maximum inactivity times for both local and remote administrative
sessions. When a session is inactive (i.e., no session input) for the configured period of time, the TOE
will terminate the session, flush the screen, and no further activity will be allowed, requiring the
administrator to log in (be successfully identified and authenticated) again to establish a new session.
The allowable range is from 0 minutes 0 seconds to 35791 minutes 59 seconds.
7.6.2 FTA_SSL.3 TSF-initiated Termination
When the remote session is inactive (i.e., no session input) for the configured period of time, the TOE
Security Target of Huawei A800 Series Routers 7 TOE Summary Specification
will terminate the session. By default, the timeout duration is 10 minutes.
7.6.3 FTA_SSL.4 User-initiated Termination
When the initiated administrator or local session is inactive (i.e., no session input) for the configured
period of time, the TOE will terminate the session.
The administrator can terminate the interactive session by closing the login window of the device.
7.6.4 FTA_TAB.1 Default TOE Access Banners
To provide some prompts or alarms to users, an Administrator can use the header command to
configure a title on the router. If a user logs in to the router, the title is displayed. An Administrator
can specify the title, or specify the title information by using the contents of a file. The same title is
displayed same for both local and remote users.
When a terminal (remote or local) connection is activated and someone attempts to log in, the
terminal displays the contents of the title that is set by using the header login command. After the
successful login, the terminal displays the contents of the title that is configured by using the header
shell command.
The local Console port and the remote Secure Telnet interface are used by an administrator to
communicate with the router.
7.7 Trusted path/channels (FTP)
7.7.1 FTP_ITC.1 Inter-TSF Trusted Channel
The TOE works as the client to protect the communications between the TOE and the Syslog server by
using a TLS protocol. When the TOE acts as a client to establish a TLS connection with the Syslog
server, the TOE uses the X.509 certificate defined by 6.1.3.7 to identify the audit server.
TLS protects the data from disclosure by encryption defined at 6.1.2.4 and ensures that the data has not
been modified by MAC defined by 6.1.2.6.
7.7.2 FTP_TRP.1/Admin Trusted Path
All remote administrative communications take place over a secure encrypted SSH session. The
remote users are able to initiate SSH communications with the TOE.
The TOE protects communications between the TOE and authorized remote administrators with SSH.
Security Target of Huawei A800 Series Routers 7 TOE Summary Specification
Security Target of Huawei A800 Series Routers 8 Crypto Disclaimer
8 Crypto Disclaimer
The following cryptographic algorithms are used by A800 Series Routers software to enforce its
security policy:
# Purpose Cryptographic
Mechanism
Standard of
Implementation
Key Size
in Bits
Standard of
Application
Comments
1 Key Generation FFC schemes - 3072-bit
or greater
FIPS PUB
186-4, “Digital
Signature
Standard
(DSS)”,
Appendix B.1
FCS_CKM.1
ECC schemes - 256 bits or
greater
FIPS PUB
186-4, “Digital
Signature
Standard
(DSS)”,
Appendix B.4
2 Key Establishment Finite field-based
key establishment
schemes
Pair-Wise Key
Establishment
Schemes Using
Discrete Logarithm
Cryptography
3072 bit
or greater
NIST Special
Publication
800-56A
Revision 2
FCS_CKM.2
Elliptic
curve-based key
establishment
schemes
Pair-Wise Key
Establishment
Schemes Using
Discrete Logarithm
Cryptography
256 bits NIST Special
Publication
800-56A
Revision 2
FCS_CKM.2
3 Confidentiality AES in GCM
mode
- 128 bits
or 256
bits
AES as
specified in
ISO 18033-3,
GCM as
specified in
ISO 19772
FCS_COP.1/
DataEncryption
AES in CTR mode - 128 bits
or 256
bits
AES as
specified in
ISO 18033-3,
CTR as
specified in
ISO 10116
Security Target of Huawei A800 Series Routers 8 Crypto Disclaimer
4 Authentication RSA signature RSA:
PKCS#1_V2.1,
RSASSA-PKCS2v1
_5
3072 bits
to 4096
bits
FIPS PUB
186-4, “Digital
Signature
Standard
(DSS)”,
Section 5.5
FCS_COP.1/
SigGen
Digital signature
scheme 2 or Digital
Signature scheme 3
ISO/IEC
9796-2, Digital
signature
scheme 2 or
Digital
Signature
scheme 3
ECDSA signature “NIST curves”
ISO/IEC 14888-3,
Section 6.4
256 bits
or greater
FIPS PUB
186-4, “Digital
Signature
Standard
(DSS)”,
Section 6 and
Appendix D
5 Secure Update RSA signature RSA:
PKCS#1_V2.1,
RSASSA-PKCS2v1
_5
4096 bits FIPS PUB
186-4, “Digital
Signature
Standard
(DSS)”,
Section 5.5
FCS_COP.1/
SigGen
6 Integrity SHA-256 and
SHA-384
- 256
bits,384
bits
ISO/IEC
10118-3:2004
FCS_COP.1/Hash
7 Cryptographic
Primitive
HMAC-SHA-256 - 256 bits ISO/IEC
9797-2:2011,
Section 7
“MAC
Algorithm 2
FCS_COP.1/
KeyedHash
8 Random Bit
Generation
Hash_DRBG
(any); DRG.2 acc.
to SP800-90A
- 256 bits SP800-90A
ISO/IEC
18031:2011
Table C.1
“Security
Strength Table
for Hash
Functions”
FCS_RBG_EXT.1
Security Target of Huawei A800 Series Routers 8 Crypto Disclaimer
9 Trusted Channel SSH V2.0 RFC 4251
RFC 4252
RFC 4253
RFC 4254
RFC 4256
RFC 4344
RFC 5647
RFC 5656
RFC 6668
- - FTP_TRP.1/ Admin
TLS1.2 RFC 5288
RFC 5246
RFC 6125
- - FTP_ITC.1
10 Cryptographic
Primitive
Generation of
prime numbers for
RSA
None - - Miller-Rabin-Test
is used as primality
test.
Referenced Documents
[FIPS 186-4] National Institute of Standards and Technology, Digital Signature
Standard (DSS), Federal Information Processing Standards Publication FIPS PUB
186-4, July 2013
[PKCS#1] RSA Cryptography Specifications Version 2.1(RFC3447)
[PKCS#3] A cryptographic protocol that allows two parties that have no prior
knowledge of each other to jointly establish a shared secret key over an insecure
communications channel.
[FIPS 198-1]The Keyed-Hash Message Authentication Code (HMAC)--2008 July
[RFC 4251]The Secure Shell (SSH) Protocol Architecture, January 2006
[RFC 4252]The Secure Shell (SSH) Authentication Protocol, January 2006
[RFC 4253]The Secure Shell (SSH) Transport Layer Protocol, January 2006
[RFC 4254]The Secure Shell (SSH) Connection Protocol, January 2006
[RFC 6668]SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport
Layer Protocol
[RFC 3268]Advanced Encryption Standard (AES) Ciphersuites for Transport Layer
Security (TLS)
[RFC 4346]The Transport Layer Security (TLS) Protocol Version 1.1
[RFC 5246]The Transport Layer Security (TLS) Protocol Version 1.2
[RFC 8446]The Transport Layer Security (TLS) Protocol Version 1.3
Security Target of Huawei A800 Series Routers 8 Crypto Disclaimer
[RFC 6125]Representation and Verification of Domain-Based Application Service
Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the
Context of Transport Layer Security (TLS)
[NIST SP 800-56A]National Institute of Standards and Technology, Recommendation
for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography,
May 2013
[NIST SP 800-56B]National Institute of Standards and Technology, Recommendation
for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography
August 2009
[ISO/IEC 18031:2011] Information technology -- Security techniques -- Random bit
generation
[ISO 18033-3] Information technology — Security techniques — Encryption
algorithms
[ISO/IEC 9796-2]Information technology -- Security techniques -- Digital signature
schemes giving message recovery
[ISO/IEC 9797-2]Information technology -- Security techniques -- Message
Authentication Codes (MACs)
[ISO/IEC 10118-3]Information technology -- Security techniques -- Hash-functions
[ISO/IEC 14888-3] Information technology -- Security techniques -- Digital signatures
with appendix
Security Target of Huawei A800 Series Routers
9 Abbreviations Terminology
and References
9 Abbreviations Terminology and
References
9.1 Abbreviations
Name Explanation
AAA Authentication Authorization Accounting
CA Certificate Authority
CC Common Criteria
CEM Common Evaluation Methodology for Information Technology
Security
CLI Command Line Interface
EAL Evaluation Assurance Level
EXEC Execute Command
GUI Graphical User Interface
IC Information Center
IP Internet Protocol
LMT Local Maintenance Terminal
MAN Metropolitan Area Network
NDcPP collaborative Protection Profile for Network Device
NMS Network Management Server
NTP Network Tiem Protocal
PP Protection Profile
Security Target of Huawei A800 Series Routers
9 Abbreviations Terminology
and References
Name Explanation
RMT Remote Maintenance Terminal
SFR Security Functional Requirement
SSH Secure Shell
SSL Secure Sockets Layer
ST Security Target
STP Spanning-Tree Protocol
TLS Transport Layer Security
TOE Target of Evaluation
TSF TOE Security Functions
9.2 Terminology
This section contains definitions of technical terms that are used with a meaning specific to
this document. Terms defined in the [CC] are not reiterated here, unless stated otherwise.
Terminology Explanation
Administrator: An administrator is a user of the TOE who may have been assigned
specific administrative privileges within the TOE. This ST may use
the term administrator occasionally in an informal context, and not
in order to refer to a specific role definition – from the TOE’s point
of view, an administrator is simply a user who is authorized to
perform certain administrative actions on the TOE and the objects
managed by the TOE. Since all user levels are assigned to
commands and users and users can only execute a command if their
associated level is equal or higher compared to the level assigned to
a command, a user might have certain administrative privileges but
lacking some other administrative privileges. So the decision
whether a user is also an administrator or not might change with the
context (e.g. might be able to change audit settings but cannot
perform user management).
Operator: See User.
Security Target of Huawei A800 Series Routers
9 Abbreviations Terminology
and References
Terminology Explanation
User: A user is a human or a product/application using the TOE which is
able to authenticate successfully to the TOE. A user is therefore
different to a subject which is just sending traffic through the device
without any authentication.
9.3 References
Name Description
[CC] Common Criteria for Information Technology Security
Evaluation. Part 1-3
April 2017
Version 3.1
Revision 5
[CC1] Common Criteria (CC)
Part 1: Introduction and general model
April 2017
Version 3.1
Revision 5
[CC2] Part 2: Security functional components
April 2017
Version 3.1
Revision 5
[CC3] Part 3: Security assurance components
April 2017
Version 3.1
Revision 5
[CEM] Common Methodology for Information Technology Security
Evaluation
Evaluation methodology
April 2017
Version 3.1
Revision 5
[CPP_ND] collaborative Protection Profile for Network Devices, Version
2.2e，23-Mar-2020
Security Target of Huawei A800 Series Routers
9 Abbreviations Terminology
and References
Name Description
[ISO18031] Information technology — Security techniques — Random bit
generation
Second edition
2011-11-15
[RFC 3526] This document defines new Modular Exponential (MODP)
Groups for the Internet Key Exchange (IKE) protocol. It
documents the well known and used 1536 bit group 5, and also
defines new 2048, 3072, 4096, 6144, and 8192 bit
Diffie-Hellman groups numbered starting at 14.
Please refer to the following link:
http://www.rfc-editor.org/info/rfc3526
[RFC 4251] This document describes the architecture of the SSH protocol, as
well as the notation and terminology used in SSH protocol
documents. It also discusses the SSH algorithm naming system
that allows local extensions.
Please refer to the following link:
http://www.rfc-editor.org/info/rfc4251
[RFC 5280] This memo profiles the X.509 v3 certificate and X.509 v2
certificate revocation list (CRL) for use in the Internet.
Please refer to the following link:
http://www.rfc-editor.org/info/rfc5280
[RFC 5759] This document specifies a base profile for X.509 v3 Certificates
and X.509 v2 Certificate Revocation Lists (CRLs) for use with
the United States National Security Agency's Suite B
Cryptography.
Please refer to the following link:
http://www.rfc-editor.org/info/rfc5759
[SD_ND] Evaluation Activities for Network Device cPP
December-2019
Version 2.2
[SP800-56A] Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography
Revision 2
May 2013
[SP800-56B] Recommendation for Pair-Wise Key Establishment Schemes
Using Integer Factorization Cryptography
Revision 1
September 2014
Security Target of Huawei A800 Series Routers
9 Abbreviations Terminology
and References
Name Description
[SP800-90A] Recommendation for Random Number Generation Using
Deterministic Random Bit Generators
Revision 1
June 2015