1
Brocade® G620 Fiber Channel Switch
FIPS 140-2
Non-Proprietary
Security Policy
Document Version 1.0
Brocade Communications Systems, Inc.
February 2, 2018
Copyright Brocade Communications Systems, Inc. 2018. May be reproduced only in its original entirety [without revision].
2
Document History
Version Publication Date Summary of Changes
1.0 February 2, 2018 Initial Release
3
Table of Contents
1 Module Overview .................................................................................................................................................6
1.1 Brocade G620 FC Switch ....................................................................................................................................6
2 Security Level.......................................................................................................................................................8
3 Modes of Operation.............................................................................................................................................9
3.1 FIPS Compliant State and Approved Mode of Operation...................................................................................9
3.1.1 FIPS Approved Cryptographic Algorithms ................................................................................................................................ 10
3.1.2 Creating FIPS Compliant State and Entering FIPS Approved mode ...................................................................................... 11
3.1.2.1 Notes and Guidance to Crypto-Officer................................................................................................12
3.1.2.2 Cryptographic module initialization........................................................................................................12
3.1.3 How to determine that an Approved mode of operation is selected..................................................................................... 18
3.2 Non-Approved FIPS cryptographic algorithms and services....................................................................................19
4 Ports and Interfaces..........................................................................................................................................23
4.1 LED Indicators....................................................................................................................................................23
5 Identification and Authentication Policy............................................................................................................26
5.1 Assumption of Roles..........................................................................................................................................26
6 Access Control Policy .........................................................................................................................................29
6.1 Roles and Services ............................................................................................................................................29
6.2 Unauthenticated Services .................................................................................................................................29
6.3 Definition of Critical Security Parameters (CSPs).............................................................................................30
6.4 Definition of Public Keys ...................................................................................................................................31
6.5 Definition of CSPs Modes of Access .................................................................................................................32
7 OperationalEnvironment...................................................................................................................................33
8 Security Rules ....................................................................................................................................................34
9 Physical Security Policy......................................................................................................................................36
9.1 Physical Security Mechanisms..........................................................................................................................36
9.2 Operator Required Actions ................................................................................................................................36
10 Mitigation of Other Attacks Policy.....................................................................................................................36
11 Definitions and Acronyms .................................................................................................................................37
12 Brocade Abbreviations ......................................................................................................................................38
13 Appendix A: Tamper Label Application..............................................................................................................39
13.1 Applying Tamper-Evident Seals on the Brocade G620....................................................................................39
14 Appendix B: Block Diagram...............................................................................................................................43
15 Appendix C: Critical Security Parameters and Public Keys .............................................................................44
16 Appendix D: CKG as per SP800-133................................................................................................................50
4
Table of Tables
Table 1 - Firmware Version ...................................................................................................................................................6
Table 2 – Brocade G620 FC Switches .................................................................................................................................7
Table 3 - Brocade G620 FC Switch Supported Power Supplies and Fan Assemblies.......................................................7
Table 4 - Brocade G620 FC Switch Supported Port on Demand License Information......................................................7
Table 5 - Module Security Level Specification.....................................................................................................................8
Table 6 - Algorithm certificates table for G620 FC Switch ................................................................................................10
Table 7- Non-Approved Algorithms Allowed in FIPS Mode ................................................................................................11
Table 8– Non-Approved Algorithms – post invoking Approved mode (FIPS enabled).....................................................19
Table 9 - Services in Non-Approved Mode of Operation ...................................................................................................20
Table 10 - Port/Interfaces Brocade G620.........................................................................................................................23
Table 11 - Port/Interface Quantities Brocade G620.........................................................................................................23
Table 12 - Port-side LED patterns during normal operation .............................................................................................24
Table 13 - Non-port-side LED patterns during normal operation......................................................................................25
Table 14 - Roles and Required Identification and Authentication....................................................................................26
Table 15 - Strengths of Authentication Mechanisms........................................................................................................27
Table 16 – Description of Services in Approved mode of operation................................................................................28
Table 17 - Services Authorized for Roles- Strengths of Authentication Mechanisms .....................................................29
Table 18 - CSP Access Rights within Roles and Services .................................................................................................32
Table 19 - Public Key Access Rights within Roles & Services...........................................................................................33
Table 20 - Inspection/Testing of Physical Security Mechanisms .....................................................................................36
Table 21 - Mitigation of Other Attacks ...............................................................................................................................36
Table 22 - Definitions and Acronyms .................................................................................................................................37
Table 23 - Brocade Abbreviations ......................................................................................................................................38
5
Table of Figures
Figure 1 - Brocade G620 – Front and Top Sides.................................................................................................................6
Figure 2 - Brocade G620 – Front, Left and Top Sides ........................................................................................................6
Figure 3 - Brocade G620 – Front, Right and Top Sides ......................................................................................................6
Figure 4 - Brocade G620 – Back and Top Sides (showing XBR-G250WPSAC-R) ..............................................................7
Figure 5 – Brocade G620 Right side view with tamper evident seal ...............................................................................39
Figure 6 – Brocade G620 Rear view with tamper evident seals......................................................................................40
Figure 7 – Brocade G620 Left side view with tamper evident seal .................................................................................40
Figure 8 – Brocade G620 Top view with no tamper evident seal ....................................................................................41
Figure 9 –Brocade G620 Bottom view with tamper evident seals and zoomed sections ..............................................42
Figure 10 – Block Diagram.................................................................................................................................................43
6
1 Module Overview
The Brocade G620 is a multiple-chip standalone cryptographic module, as defined by FIPS 140-2. The
cryptographic boundary of the Brocade G620 FC Switch is the outer perimeter of the metal chassis
including the removable cover. The module is a Fiber Channel and/or Gigabit Ethernet routing switch that
provides secure network services and network management.
A validated module configuration is comprised of Fabric OS v8.1.0 (P/N: 63-1001736-01) installed on, a
switch or backbone and a set of installed blades. The below platforms may be used in a validated module
configuration:
Table 1 - Firmware Version
Firmware
Fabric OS v8.1.0
1.1 Brocade G620 FC Switch
Figure below illustrates the Brocade G620 FC Switch cryptographic module.
Figure 1 - Brocade G620 – Front and Top Sides
Figure 2 - Brocade G620 – Front, Left and Top Sides
Figure 3 - Brocade G620 – Front, Right and Top Sides
7
Figure 4 - Brocade G620 – Back and Top Sides (showing XBR-G250WPSAC-R)
Table 2 – Brocade G620 FC Switches
Switch SKU Part Number Brief Description
Brocade G620 BR-G620-48-32G-F 80-1009066-02 Brocade G620, baseline 32G configuration with
non-port side air flow
- Provides 48 Ports
- 48 32G SFPs
- Quantity of 2 Power Supply and Fan Assembly
- Qty. 1 24 port POD license to upgrade to 48
ports
Brocade G620 BR-G620-48-32G-R 80-1009067-02 Brocade G620, baseline 32G configuration with
port side air flow
- Provides 48 Ports
- 48 32G SFPs
- Quantity of 2 Power Supply and Fan Assembly
- Qty. 1 24 port POD license to upgrade to 48
ports
Notes for table above:
1. Ports 25 – 48 are physically present but disabled. A POD license is required to enable ports 25 – 48
Table below lists power supply and fan assemblies supported on Brocade G620 FC Switches:
Table 3 - Brocade G620 FC Switch Supported Power Supplies and Fan Assemblies
SKU Part Number Description
XBR-G250WPSAC-F 80-1009260-01 FRU,250W,ACPS/FAN,NONPORTSIDE EXHAUST
XBR-G250WPSAC-R 80-1009261-01 FRU,250W,ACPS/FAN,PORT SIDE EXHAUST
Table below lists The Port on Demand supported on Brocade G620 FC Switches:
Table 4 - Brocade G620 FC Switch Supported Port on Demand License Information
SKU Part Number Description
SW-MIDR24PTPOD-01 80-1009038-01 P/N, S/W POD LICENSE, 24 PORT ONDEMAND
REST OF THIS PAGE WAS INTENTIONALLY LEFT BLANK.
Next page 
8
2 Security Level
The cryptographic module meets the overall requirements applicable to Level 2 security of FIPS 140-2.
Table 5 - Module Security Level Specification
Security Requirements Section Level
CryptographicModuleSpecification 2
Module Ports and Interfaces 2
Roles, Services and Authentication 2
Finite State Model 2
PhysicalSecurity 2
Operational Environment N/A
CryptographicKeyManagement 2
EMI/EMC 2
Self-Tests 2
DesignAssurance 2
Mitigation of Other Attacks N/A
REST OF THIS PAGE WAS INTENTIONALLY LEFT BLANK.
Next page 
9
3 Modes of Operation
Module State: Non-compliant FIPS state:
An uninitialized module provides an operational environment which is not a FIPS compliant state (it is a non-
compliant FIPS state). A Crypto-officer must follow the instructions in section 3.1.2 to configure the module in order
to create a FIPS compliant state.
Module State: Compliant FIPS state:
A module must be configured to provide a compliant FIPS state. Section 3.1.2 provides the required detailed
instructions on how to configure the module into a compliant FIPS state.
The Crypto-Officer must use the admin user-account to login to the module and configure the module into FIPS
compliant state (see section 3.1.2). These configuration steps, also, configure the module to use FIPS Approved
cryptographic algorithms (see Table 6 and Table 7).
Term Crypto-Officer in this document refers to the Crypto-Officer who has logged in using the admin user-account.
Mode of Operation: FIPS Approved mode
After module is configured to enter FIPS compliant state it must operate adhering to use only the FIPS approved
cryptographic algorithms (see Table 6 and Table 7) and the FIPS approved services.
NOTE: Operating the module with Non-Approved FIPS cryptographic algorithms (see Table 8) or FIPS Non-Approved
services (see Table 9) is in explicit violation of this Security Policy and implicitly toggles the module out of FIPS mode.
Mode of Operation: FIPS Non-Approved mode
NOTE: A module configured to operate in FIPS compliant state can be re-configured by the Crypto-Officer to use FIPS
Non-Approved cryptographic algorithms (see Table 8) and/or FIPS Non-Approved services (see Table 9). Operating
the module with Non-Approved FIPS cryptographic algorithms or FIPS Non-Approved services is in explicit violation of
this Security Policy and implicitly toggles the module out of FIPS mode.
3.1 FIPS Compliant State and Approved Mode of Operation
This section provides information on how to configure the module to create a FIPS compliant state. It also describes
the requirements for providing a FIPS Approved operational environment.
This section provides the following information:
A. Reference to approved algorithms and their CAVP granted certificates (section 3.1.1),
B. The initialization steps (section 3.1.2) to configure the module to operate in Approved mode of
operation (FIPS enabled), and
C. Steps and procedures (section 3.1.3) on how to examine that the module is operating in Approved
mode of operation (FIPS enabled).
Note that special attention must be paid to section, 3.2, Non-Approved mode of operation (post following steps
to enable FIPS mode), to understand additional requirements for operating in Approved mode of operation.
10
3.1.1 FIPS Approved Cryptographic Algorithms
Table 6 - Algorithm certificates table for G620 FC Switch
CAVP
Cert
Algorithm Standard Mode/ Method
Key
Lengths,
Curves or
Moduli
Use
4244 AES FIPS 197,
SP 800-38A
CBC, ECB, CTR 128, 192,
and 256
Data Encryption/Decryption
(1)
4244 AES FIPS 197,
SP 800-38A
CFB 128 Data Encryption/Decryption
994 CVL,
SSHv2
TLSv1.0/TLSv1.1
TLSv1.2
SNMPv3
SP 800-
135rev1
Key Derivation
995 CVL SP 800-
56Arev2
ECC CDH
Primitive
P-256,
P-384
Shared Secret Computation
(2)
993 CVL,
Partial DH
SP 800-
56Arev2
FFC (2048, 256) Shared Secret Computation
993 CVL,
Partial DH
SP 800-
56Arev2
ECC P-256,
P-384
Shared Secret Computation
(3)
1323 DRBG SP 800-
90Arev 1
CTR_DRBG 256 Deterministic Random Bit
Generation
1134 DSA FIPS 186-4 2048 Key Pair Generation, PQG(Gen)
and PQG(Ver)
(4)
984 ECDSA FIPS 186-4 PKG, PKV,
SigGen, SigVer
P-256,
P-384
Digital Signature Generation
and Verification
(5)
2782 HMAC FIPS 198-1 HMAC-SHA-1,
HMAC-SHA-256,
HMAC-SHA-384,
HMAC-SHA-512
160,
256,
384,
512
Message Authentication
(6)
2290 RSA FIPS 186-4 SHA-256 2048 Digital Signature Generation
and Verification
(7)
3481 SHS FIPS 180-4 SHA-1, SHA-224,
SHA-256, SHA-
384, SHA-512
Message Digest
(8)
1 AES (Cert. #4244) supports the ECB mode only as a pre-requisite for other implementations in the module.
AES ECB mode is not invoked independently by any approved service in the FIPS Approved mode.
2 CVL (Cert. #995): P-384 is latent functionality. The module does not support this mode in the FIPS Approved
mode.
3 CVL (Cert. #993): P-384 is latent functionality. The module does not support this mode in the FIPS Approved
mode.
4 DSA (Cert. #1134) is only used as a prerequisite for CVL (Cert. #993)
5 ECDSA (Cert. #984): P-384 is latent functionality. The module does not support this mode in the FIPS
Approved mode.
6 HMAC (Cert. #2782): HMAC-SHA-224 is latent functionality. The module does not support this mode in the
FIPS Approved mode.
7 RSA (Cert. #2290): The only mode utilized by the module is RSA 2048 with SHA-256. All other modes and key
sizes are latent functionality.
8 SHS (Cert. #3481): SHA-224 is latent functionality. The module does not support this mode in the FIPS
Approved mode.
11
For additional information on transitions associated with the use of cryptography refer to NIST Special Publication
SP800-131Ar1. This document can be located on the CMVP website at:
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf
The data in the tables will inform users of the risks associated with using a particular algorithm and a given
key length.
FIPS Approved mode enables:
• HTTPS TLS v1.0/1.1 and TLS v1.2
• SSHv2
• SNMPv3
The following non-Approved algorithms and protocols are allowed within the Approved mode of operation:
Table 7- Non-Approved Algorithms Allowed in FIPS Mode
Algorithm Caveat Use
Diffie-Hellman (CVL Cert. #993) Key agreement; key establishment
methodology provides 112 bits of
encryption strength.
Key establishment within SSHv2
protocol
EC Diffie-Hellman (CVL Cert. #993)
Supported curves: P-256
Key agreement; key establishment
methodology provides 128 bits of
encryption strength.
Key establishment within SSHv2
protocol
EC Diffie-Hellman (CVL Cert. #995)
Supported curves: P-256
Key agreement; key establishment
methodology provides 128 bits of
encryption strength.
Key establishment within SSHv2
protocol
HMAC-MD5 Used in RADIUS for operator
authentication only (HMAC-MD5 is
not exposed to the operator)
RADIUS authentication
HMAC-SHA-1-96 Used in SNMPv3 (HMAC-SHA-1-96 is
not exposed to the operator)
SNMPv3
MD5 Used in storage of passwords (MD5
is not exposed to the operator)
Used in store password hash
MD5 Used in TLS v1.0 KDF TLS v1.0KDF
NDRNG – entropy data Seeding for the Approved DRBG
RSA Key Wrapping Provides 112 bits of encryption
strength.
Key establishment
3.1.2 Creating FIPS Compliant State and Entering FIPS Approved mode
Physical Security:
Follow instructions provided in section 9 (Physical Security Policy) to apply the required tampered seals. Validate that
the tamper evident seals are applied and the module is untampered.
Module Configuration:
The cryptographic module IS NOT operating in the Approved mode of operation until the required configurations
steps in this section are followed to initialize the module. When the module is yet to be initialized and configured to
enter the FIPS compliant State, the module is known to be in a non-compliant FIPS state.
In such non-compliant FIPS state the module provides access to three different user accounts: root user-account,
12
admin user-account, and user user-account. The Crypto-Officer must use the admin user-account to login to the
module and configure the module as per instructions provided below to enter the Approved mode of
operation (to enable FIPS mode.)
After this configuration is complete, root user-account is permanently disabled and only admin and user user-
accounts are left available to login to the module.
Term Crypto-Officer in this document refers to the Crypto-Officer who has logged in using the admin user-
account.
3.1.2.1 Notes and Guidance to Crypto‐Officer
A. Guidance for module being upgraded to FOS 8.1.0:
1. Only a module running FOS 7.4.0 can be upgraded to FOS 8.1.0.
B. Following features and capabilities are not supported FIPS mode. Instructions listed below must be followed
by the Crypto-Officer when configuring a device to operate in FIPS mode:
1. Do not enable FC port authentication. This level of authentication is considered as plain text and
not supported in Approved mode of operation (FIPS mode). The security it provides does not meet
FIPS security requirements. This includes use of Common-Certs which are not supported in FIPS
Mode.
2. The client authentication feature for TLS clients is not supported in Approved mode of operation.
The Crypto-Officer must not configure client authentications for TLS connections as it is not
supported in Approved mode of operation (FIPS mode).
3. Do not configure access-time feature for any users in the FIPS mode.
The Crypto-Officer must not configure access-time feature. Access-time feature is not supported in
Approved mode of operation.
3.1.2.2 Cryptographic module initialization
The following is the procedure to enable FIPS mode. Ensure that notes and guidance mentioned in Section 3.1.2.1 are
reviewed and adhered to.
1. Login to the switch as an authorized user
2. Verify the firmware version using firmwareshow command
a. firmwareshow
3. User Defined roles:
User Defined role is not supported in FIPS mode. The Crypto-Officer must not use this feature. The
Crypto-Officer must delete any User Defined roles which may exist prior to placing the module in FIPS
mode.
a. Examine existing User Defined roles by issuing the following CLI command:
roleconfig --show -all
If no User Defined roles is present then the above CLI command will report the following
message:
“There are no user-defined roles on the switch.”
13
b. If User Defined roles have been configured, then ‘roleconfig --show -all’ command
will display a list of defined roles. In this case, use the following CLI command to delete all
existing User Defined roles.
roleconfig --delete <role_name>
4. Zeroize the switch
a. Execute zeroization to zeroize all the CSP on the Switch
i. fipscfg -–zeroize
b. Reboot the switch
i. Execute reboot.
5. Enable the self-tests mode using the command 'fipscfg -–enable selftests'
i. fipscfg -–enable selftests
NOTE: Once this step occurs the cryptographic module will perform power-up self-tests during all subsequent
power-ups regardless of whether the cryptographic module is in FIPS mode or non-FIPS mode. There is no service,
method, or mechanism to disable such power-up self-tests thereafter.
6. Disable the non-secure ports using ipfilter CLI. Follow the procedure outlined below for disabling a
given port. Use the same approach to disable port 80, 23 and 897 for both IPv4 and IPv6 rules
For e.g.: For IPv4
ipfilter -–clone fips_ipv4 -from default_ipv4
ipfilter -–delrule fips_ipv4 -rule 2
ipfilter -–addrule fips_ipv4 -rule 2 -sip any -dp 23 -proto tcp -act deny -type INPUT -dip any
ipfilter -–delrule fips_ipv4 -rule 3
ipfilter -–addrule fips_ipv4 -rule 3 -sip any -dp 80 -proto tcp -act deny -type INPUT -dip any
ipfilter -–addrule fips_ipv4 -rule 7 -sip any -dp 897 -proto tcp -act deny -type INPUT -dip any
ipfilter -–addrule fips_ipv4 -rule 7 -sip any -dp 897 -proto udp -act deny -type INPUT -dip any
ipfilter -–delrule fips_ipv4 -rule 10
ipfilter -–delrule fips_ipv4 -rule 9
ipfilter -–addrule fips_ipv4 -rule 9 -sip any -dp "600-896" -proto tcp -act permit -type INPUT -dip any
ipfilter -–addrule fips_ipv4 -rule 10 -sip any -dp "898-1023" -proto tcp -act permit -type INPUT -dip any
ipfilter -–addrule fips_ipv4 -rule 11triple -sip any -dp "600-896" -proto udp -act permit -type INPUT -dip any
ipfilter -–addrule fips_ipv4 -rule 12 -sip any -dp "898-1023" -proto udp -act permit -type INPUT -dip any
ipfilter -–activate fips_ipv4
REST OF THIS PAGE WAS INTENTIONALLY LEFT BLANK.
Next page 
14
For IPv6
ipfilter -–clone fips_ipv6 -from default_ipv6
ipfilter -–delrule fips_ipv6 -rule 2
ipfilter -–addrule fips_ipv6 -rule 2 -sip any -dp 23 -proto tcp -act deny -type INPUT -dip any
ipfilter -–delrule fips_ipv6 -rule 3
ipfilter -–addrule fips_ipv6 -rule 3 -sip any -dp 80 -proto tcp -act deny -type INPUT -dip any
ipfilter -–addrule fips_ipv6 -rule 7 -sip any -dp 897 -proto tcp -act deny -type INPUT -dip any
ipfilter -–addrule fips_ipv6 -rule 7 -sip any -dp 897 -proto udp -act deny -type INPUT -dip any
ipfilter -–delrule fips_ipv6 -rule 10
ipfilter -–delrule fips_ipv6 -rule 9
ipfilter -–addrule fips_ipv6 -rule 9 -sip any -dp "600-896" -proto tcp -act permit -type INPUT -dip any
ipfilter -–addrule fips_ipv6 -rule 10 -sip any -dp "898-1023" -proto tcp -act permit -type INPUT -dip any
ipfilter -–addrule fips_ipv6 -rule 11 -sip any -dp "600-896" -proto udp -act permit -type INPUT -dip any
ipfilter -–addrule fips_ipv6 -rule 12 -sip any -dp "898-1023" -proto udp -act permit -type INPUT -dip any
ipfilter -–activate fips_ipv6
7. Configure supported host keys for use for SSH:
Delete the unsupported host key for SSH i.e. DSA and RSA using sshutil delknownhost
sshutil delhostkey -rsa
sshutil delhostkey -dsa
NOTE: this action ensures that only ecdsa-sha2-nistp256 based SSHv2 host key are available for use in
Approved mode of operation
8. Configuring AAA authentication:
NOTE: TACACS+ is not supported in FIPS mode and should not be enabled.
If AAA authentication is to be used in FIPS mode, configure the preferred and supported AAA server
(LDAP/RADIUS) using aaaconfig CLI command
a. Set the initial state
i. Set the authentication to the local database
aaaconfig --authspec "local"
NOTE: By default, authentication is set using the local database.
b. Requirements for CA certificate
i. Existence of CA certificate is mandatory for RADIUS and/or LDAP services.
1. Ensure that the CA certificate are imported using seccertmgmt CLI
a. Ex: For radius:
seccertmgmt import -ca -server radius
b. Ex For LDAP:
seccertmgmt import -ca -server ldap
ii. CA certificate also must meet the requirement listed below:
1. All certificate must be of RSA 2048 key pair signed with SHA256 hash
15
c. Add the server
i. If RADIUS server is used, then issue the following CLI command and ensure only
‘peap-mschapv2’ is configured.
aaaconfig -–add <radius-serverip> -conf radius -a peap-mschapv2
ii. If LDAP server is used, then issue the following CLI command,
aaaconfig --add <ldap-serverip> -conf ldap -d <domain>
d. Set the final authentication setting
i. If setting up a RADIUS server, then issue the following CLI command:
aaaconfig --authspec “radius;local”
ii. If setting up a LDAP server, then issue the following CLI command:
aaaconfig --authspec “ldap;local”
9. If in-flight encryption feature is enabled, disable it using portcfgencrypt –disable <portnum>
10. If management IP Sec feature is enabled, disable it using ipsecconfig CLI
11. If Inband Management feature is enabled, disable it using
portcfg mgmtif <port num> disable
12. In FIPS mode http is blocked and only https is allowed. For using https in FIPS mode, configure HTTPS
using the seccertmgmt CLI with a third party certificate
seccertmgmt import -ca -server https
seccertmgmt import -cert https
13. *** CIPHER CONFIGURATION SETUP STEP ***
Configure cipher using seccryptocfg CLI to configure ciphers for SSH, TLS, RADIUS and LDAP
a. Export default_strong template from the switch.
seccryptocfg --export default_strong -server <server-ip> -name <username> -proto scp -file <filename>
b. Edit the template to include only the ciphers as mentioned in section, 3.1.1 (FIPS Approved
Cryptographic Algorithms)
c. Download the template and enable it
seccryptocfg --import <custom template name> -server <serverip> -name <username> -proto scp -file <filename>
seccryptocfg --apply <custom template name>
Next page 
16
14. Enable secure protocols using configurechassis command
configurechassis
Configure...
cfgload attributes (yes, y, no, n): [no] y
Enforce secure config Upload/Download (yes, y, no, n): [no] y
15. SNMP configurations
a. Disable SNMPv1 using the following CLI command
snmpconfig –disable snmpv1
b. If SNMPv3 is to be used in FIPS mode,
i. Enable SNMPv3 and sec level to auth and Priv
ii. Passwords for all users should be of minimum length 8
iii. Auth protocol should be SHA1
iv. Priv protocol should be AES128
NOTE: DES must not be configured for SNMPv3
Eg: snmpconfig -–set snmpv3
SNMP Informs Enabled (true, t, false, f): [false]
SNMPV3 Password Encryption Enabled (true, t, false, f): [false] true
Warning: The encrypted password cannot be decrypted. Do you want to
continue? (yes, y, no, n): [no] y
SNMPv3 user configuration(snmp user not configured in FOS user
database will have default VF context and admin role as the default):
User (rw): [snmpadmin1]
Auth Protocol [MD5(1)/SHA(2)/noAuth(3)]: (1..3) [3] 2
New Auth Passwd:
Verify Auth Passwd:
Priv Protocol [DES(1)/noPriv(2)/AES128(3)/AES256(4)]): (1..4) [2] 3
New Priv Passwd:
Verify Priv Passwd:
16. Passwords for default accounts (admin and user) must be changed after every zeroization to maintain
FIPS 140-2 compliance. Change the default password for “admin” and “user” by pressing “Enter” instead
of “Ctrl-C” after logging in as “admin”.
17. Modify the authutil policy in every VF present, to use hash sha256 and DH group 4 (setcontext to each VF
and execute below commands):
authutil -–set -h sha256
authutil -–set -g 4
18. Disable bootprom using the CLI fipscfg –disable bootprom.
a. Bootprom account can be disabled only as root.
b. Enable root account using following CLI
userconfig -–change root –e yes
17
c. Login as “root” and disable the bootprom using
fipscfg -–disable bootprom
d. Login as “admin” again and disable “root” using
userconfig -–change root –e no
19. Verify if the switch is configured to be FIPS compliant
a. Execute 'fipscfg -–verify fips'
b. Ensure that all conditions are met and the message is displayed that FIPS mode can be enabled.
Ex: (Indicates of both failure and pass example)
fipscfg -–verify fips
Standby firmware supports FIPS - PASS
SELF tests check has passed - PASS
Root account check has passed - PASS
Radius check has passed - PASS
Authentication check has passed - PASS
Inflight Encryption check has passed - PASS
IPSec check has passed - PASS
IPv6 policies FIPS compliant - PASS
IPv6 policies FIPS compliant - PASS
SNMP is in read only mode. - PASS
SNMP User password length check - PASS
SNMP Users have no MD5 auth protocol check - PASS
Bootprom access is disabled. - PASS
Secure config upload/download is enabled. - PASS
SSH DSA Keys check passed - PASS
Inband Management interface is disabled - PASS
Ipsecconfig is disabled. – PASS
FCIP validations - PASS
Certificates validation has passed - PASS
SSH host key (RSA) validation has passed - PASS
20. If all the tests are PASS in above step, then proceed to enable FIPS mode.
21. Enable FIPS Mode
 Execute 'fipscfg -–enable fips'
sw068:test> fipscfg --enable fips
FIPS mode has been set to : Enabled
 Verify that the FIPS mode has been set to ‘Enabled'' using 'fipscfg -–show'
sw068:test> fipscfg -–show
FIPS mode is : Enabled
FIPS Selftests mode/status is : Enabled/None
 Power-cycle the switch.
 Login to the node as an authorized user, and verify that the self-tests mode is set to ' Enabled/Pass'
Sw0sar068:test> fipscfg -–show
FIPS mode is : Enabled
FIPS Selftests mode/status is : Enabled/Pass
18
22. Enable the DH key size configuration using ‘fipscfg -–enable dh’
23. The tamper evident seals supplied in FIPS Kit Brocade XBR-000195 (P/N: 80-1002006-02) must be
installed as defined in section 13 (Appendix A: Tamper Label Application).
24. After successful completion of step 23, your switch is now a FIPS Validated Cryptographic Module in FIPS
Approved mode.
25. WARNING: At this point, the algorithms in Section 3.2, Table 8, are now disabled. Any use of these
algorithms, or an attempt by the operator to revert the configuration in Section 3.1.2.2, is an explicit
violation of this Security Policy and implicitly toggles the module out of FIPS mode.
NOTE: Upon successful completion of all configuration steps in Section 3.1.2.2, self-tests will
forevermore be enabled, even if the operator violates this Security Policy which implicitly toggles the
module out of FIPS mode after configuration.
3.1.3 How to determine that an Approved mode of operation is selected
After all steps specified in section 3.1.2.2 (Cryptographic module initialization) are performed, the operator shall
perform the following instructions to examine the mode of operation:
1. Check for successful status of the powerup Self-Tests. For details, see section 8, Security Rules.
2. Confirm the firmware version using firmwareshow command
a. firmwareshow
3. Check status of FIPS mode
a. fipscfg –show
4. Validate that the tamper evident seals are applied and the module is untampered (see section 9.2 for
details).
5. Do not configure the device to use any of the algorithms listed in section 3.2, Non-Approved mode of
operation
REST OF THIS PAGE WAS INTENTIONALLY LEFT BLANK.
Next page 
19
3.2 Non-Approved FIPS cryptographic algorithms and services
This section lists all non-Approved cryptographic algorithms and all Non-Approved services which MUST NOT be used.
The use of any such algorithm, and service, is an explicit violation of this Security Policy and is explicitly disallowed by
this Security Policy.
The module supports a Non-Approved mode of operation. This mode of operation exists when:
1. After the module has been initialized and configured as per Section 3.1, the Crypto-Officer reverts any of the
configuration procedures and executes the Non-Approved services in Table 9 using the Non-Approved
Algorithms in Table 8.
The algorithms marked “non-compliant” are not compliant simply because they are invoked in the Non-Approved
mode of operation, by a Non-Approved mode service.
Table 8– Non-Approved Algorithms – post invoking Approved mode (FIPS enabled)
Algorithm Use
AES 128, 192 and 256 (non-compliant) Encryption / Decryption
CAMELLIA 128 and 256 Encryption / Decryption
DES Encryption / Decryption
Diffie-Hellman (non-compliant) Key Establishment
DSA (non-compliant) Digital Signature
EC-DH (non-compliant) Key Establishment
ECDSA (FIPS 186-4; non-compliant) Digital Signature
HMAC-MD5 Message Authentication
HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512
(non-compliant)
Message Authentication
KDF (SSHv2, SNMPv3, TLS) (non-compliant) Key Derivation
PSK Key Establishment
RC-4 Encryption / Decryption
SEED Encryption/ Decryption
SHA-1, SHA-256, SHA-384 (non-compliant) Message Digest
Triple-DES (non-compliant) Encryption / Decryption
REST OF THIS PAGE WAS INTENTIONALLY LEFT BLANK.
Next page 
20
These functions and services are non-compliant and disallowed in Approved mode of operation.
Table 9 - Services in Non-Approved Mode of Operation
Crypto Function/Service User Role
Change Access
Additional Details
Ciphers, Message
Authentication Codes, Key
Exchange, Digital
Signature, and KDF
algorithms for TLS
Crypto-Officer Cipher:
aes128-cbc (non-compliant)
aes256-cbc (non-compliant)
aes128-gcm (non-compliant)
aes256-gcm (non-compliant)
camellia-128
camellia-256
des
seed
rc-4
triple-des (non-compliant)
Message Authentication Code:
hmac-sha-1
hmac-sha-256 (non-compliant)
hmac-sha-384 (non-compliant)
Key Exchange:
dh-dss
dhe-dss
dhe-rsa (non-compliant)
dh-rsa (non-compliant)
ecdh (non-compliant)
ecdhe (non-compliant)
psk
Digital Signature:
ecdsa (non-compliant)
rsa (non-compliant)
KDF:
TLSv1.0/1.1 (non-compliant)
TLSv1.2(non-compliant)
21
Crypto Function/Service User Role
Change Access
Additional Details
Ciphers, Message
Authentication Codes, Key
Exchange, and KDF
algorithms for SSHv2
Crypto-Officer Cipher:
aes128-ctr (non-compliant)
aes192-ctr (non-compliant)
aes256-ctr (non-compliant)
aes128-cbc (non-compliant)
3des-cbc (non-compliant)
aes192-cbc (non-compliant)
aes256-cbc (non-compliant)
Message Authentication Code:
hmac-md5
hmac-sha1 (non-compliant)
hmac-sha2-256 (non-compliant)
hmac-sha2-512 (non-compliant)
Key Exchange:
ecdh-sha2-nistp256(non-compliant)
ecdh-sha2-nistp384 (non-compliant)
ecdh-sha2-nistp521 (non-compliant)
diffie-hellman-group-exchange-sha256 (non-compliant)
diffie-hellman-group-exchange-sha1
diffie-hellman-group14-sha1
diffie-hellman-group1-sha1
KDF:
SSHv2 (non-compliant)
Common Certificates for
FCAP and HTTPS
Crypto-Officer FCAP and HTTPS are supported with certificates of any
size (512 to 2048 and above) signed with MD5, SHA-1
(non-compliant), SHA-256 (non-compliant)
SNMP Crypto-Officer SNMPv1 (plaintext) and SNMPv3 KDF (non-compliant);
Algorithms: AES128 (non-compliant), SHA-1 (non-
compliant) and MD5
RADIUS or LDAP Crypto-Officer PAP and CHAP authentication method for RADIUS (all
considered as plaintext)
LDAP and RADIUS is supported with CA certificates of
any size (512 to 2048 and above) signed with MD5,
SHA-1 (non-compliant), SHA-256 (non-compliant)
LDAP uses TLS connections in non-FIPS mode without
certificates
Telnet Crypto-Officer N/A – No algorithms (plaintext)
HTTP Crypto-Officer N/A – No algorithms (plaintext)
FTP Crypto-Officer Config Upload, Config Download, Support Save, FW
Download, autoftp
Management IPSec Crypto-Officer Management Interface IPSec/IKEv2 (disabled for
management interface)
In-Band Management
Interface
Crypto-Officer N/A – No algorithms (plaintext)
RSA Crypto-Officer RSA key size < 2048 bits for SSHv2 and TLS
Diffie-Hellman Crypto-Officer DH key size < 2048 bits for SSHv2
22
Crypto Function/Service User Role
Change Access
Additional Details
In-Flight Encryption Crypto-Officer DH-CHAP: Diffie Hellman with NULL DH, 1024, 1280,
1536 and 2048 keys with MD5 and SHA-1 (non-
compliant) hash algorithm
FCAP: Certificates with any key size signed by MD5,
SHA-1 (non-compliant), SHA-256 (non-compliant)
TACACS+ authspec mode Crypto-Officer PAP or CHAP authspec is supported
FC-SP Authentication Crypto-Officer DH-CHAP and FCAP for FC-SP Authentication
DH-CHAP: Diffie Hellman with NULL DH, 1024, 1280,
1536 and 2048 keys with MD5 and SHA-1 (non-
compliant) hash algorithm
FCAP supported with certificates of any size (512 to
2048 and above) signed with MD5, SHA-1 (non-
compliant), SHA-256 (non-compliant)
REST OF THIS PAGE WAS INTENTIONALLY LEFT BLANK.
Next page 
23
4 Ports and Interfaces
The G620 cryptographic module provides the following physical ports and logical interfaces:
 Fiber Channel: Data Input, Data Output, Control Input, Status Output
 1 GbE & 10 GbE: Data Input, Data Output, Control Input, Status Output
 Ethernet Ports: Control Input, Status Output
 Serial port: Control Input, Status Output
 USB: Data Input, Data Output, Status Output
 Power Supply Connectors: Power Input
 LEDs: Status Output
4.1 LED Indicators
Table 10 - Port/Interfaces Brocade G620
System component Description
System power LED One green system power status LED (upper) on the port side.
System status LED One bicolor (green/amber) system status LED (lower) on the port side.
Ethernet port link LED
One link LED on the left of the RJ45 connector. Glows green for 1000 Mbps and amber for
100/10 Mbps.
Ethernet port activity LED One activity LED on the right of the RJ45 connector.
Serial console port LED
The serial console port LEDs remain off at all times, even when a cable is inserted and the
link is active.
FC port status LED
64 bicolor (green/amber) port status LEDs. One for each SFP+ port and four for each QSFP
port on the switch.
Power supply and fan
assembly status LED
One green power supply and fan assembly status LED on each power supply and fan
assembly on the nonport-side of the switch.
Table 11 - Port/Interface Quantities Brocade G620
Model
Port/Interface Type
Fiber Channel Ports (SFP+) QSFP Ethernet Serial Port USB
Power Supply
Connectors
LED
G620-24-F/R 24 4 1 1 1 2 28
G620-24-
32G-F/R
24
4
1 1 1 2 28
BR-G620-48-
32G-F/R
48
4
1 1 1 2 64
REST OF THIS PAGE WAS INTENTIONALLY LEFT BLANK.
Next page 
24
Table 12 - Port-side LED patterns during normal operation
LED name LED color Status of hardware
Power Status No light System is off or there is an internal power supply
failure.
Steady green System is on and power supplies are functioning
properly.
System Status No light System is off or there is no power.
Steady green POST and initialization is completed. System is on
and functioning properly.
Steady amber (for more than
five seconds)—can take over a
minute to complete POST
System is going through the power-up process.
Steady amber (for more than a
few minutes)
Unknown state, boot failed, or the system is faulty.
NOTE
Once POST completes and the switch has failed,
steady amber may result.
Flashing amber/green Attention is required. A number of variables can
cause this status, including a single power supply
failure, a fan failure, or one or more environmental
ranges has been exceeded.
FC Port Status No light Indicates one of the following:
No signal or light carrier (media or cable) detected.
Blade may be currently initializing.
Connected device is configured in an offline state.
Steady green Port is online (connected to external device) but has
no traffic.
Slow-flashing green (on 1/2
second; then off 1/2 second)
Port is online but segmented because of a loopback
cable or incompatible Extension Switch connection.
Fast-flashing green (on 1/4
second; then off 1/4 second)
Port is online and an internal loopback diagnostic
test is running.
Flickering green Port is online and frames are flowing through the
port
Steady amber Port is receiving light or signal carrier, but it is not
online yet.
Slow-flashing amber (on 2
seconds; then off 2 seconds)
Port is disabled because of diagnostics or the
portDisable command.
Fast-flashing amber (on 1/2
second; then off 1/2 second)
SFP or port is faulty.
Port is offline. No activity.
Port is online and active.
25
LED name LED color Status of hardware
QSFP Port Status No light (LED is off) Indicates one of the following:
No signal or light carrier (media or cable) detected.
Device may be currently initializing.
Connected device is configured in an offline state.
Steady green Port is online (connected to external device) but has no
traffic.
Slow-flashinggreen (on1/2
second;then off 1/2 second)
Port is online but segmented because of a loopback
cable or incompatible device connection.
Fast-flashingamber(on1/4
second;thenoff1/4 second)
Port is online and an internal loopback diagnostic test is
running.
Flickering green Port is online and frames are flowing through the port.
Steady amber Port is receiving light or signal carrier, but it is not online
yet.
Slow-flashing amber (on 2
seconds; then off 2 seconds)
Port is disabled because of diagnostics or the
portDisable command.
Fast-flashingamber (on1/2
second;then off 1/2 second)
QSFP or port is faulty.
Table 13 - Non-port-side LED patterns during normal operation
LED name LED color Status of hardware
Power supply and fan input
status (one green LED)
No light Power supply is not receiving AC input voltage
or AC input voltage is below operational limit.
Steady green Power supply and fan assembly is operating
normally.
Flashing green (for more
than 5 seconds)
Power supply and fan assembly is faulty for
one of the following reasons:
The assembly is switched off (flashing for ~ 5
seconds, then off).
The power cable is disconnected (flashing for
~ 5 seconds, then off).
The power supply and fan assembly has
failed.
NOTE: When the device is first powered on,
the power supply and fan assembly status
LED flashes until POST has completed.
Next page 
26
5 Identification and Authentication Policy
5.1 Assumption of Roles
The cryptographic module supports the following operator roles listed in the table below. The cryptographic
module enforces the separation of roles using role-based operator authentication. An operator must enter a
username and its password to log in. The username is an alphanumeric string of maximum 32 characters. The
password is an alphanumeric string of 8 to 40 characters chosen from 96 printable and human-readable
characters. Upon correct authentication, the role is selected based on the username of the operator and the
context of the module. At the end of a session, the operator must log-out. The module supports a maximum of
256 operators, five Radius servers and five LDAP servers that may be allocated the following roles:
Table 14 - Roles and Required Identification and Authentication
Role Type ofAuthentication Authentication Data
Admin(Crypto-Officer) Role-basedoperator authentication Usernameand Password
User (User role) Role-basedoperator authentication Usernameand Password
SecurityAdmin Role-basedoperator authentication Usernameand Password
Fabric Admin Role-basedoperator authentication Usernameand Password
LDAP Server Certificate based server
authentication
LDAP Root CA certificate
RADIUS Server Certificate based server
authentication
RADIUSShared Secret and
RADIUS Root CA Certificate
Host/Server/Peer Switch Role-based operator authentication
PKI (FCAP) or Shared
Secret(DH-CHAP)
SNMP Role-based operator authentication "Auth" and "Priv" passwords
REST OF THIS PAGE WAS INTENTIONALLY LEFT BLANK.
Next page 
27
Table 15 - Strengths of Authentication Mechanisms
Authentication
Mechanism
Strength of Mechanism
Password
The probability that a random attempt will succeed or a false acceptance will occur is
1/96^8 which is less than 1/1,000,000.
The module can be configured to restrict the number of consecutive failed
authentication attempts. If the module is not configured to restrict failed
authentication attempts, then the maximum attempts possible within one minute is
20. The probability of successfully authenticating to the module within one minute is
20/96^8 which is less than 1/100,000.
DigitalSignature
Verification(PKI)
The probability that a random attempt will succeed or a false acceptance will occur is
1/2^112 which is less than 1/1,000,000.
The module will restrict the number of consecutive failed authentication attempts to
10. The probability of successfully authenticating to the module within one minute is
10/2^112 which is less than 1/100,000.
Knowledge of a Shared
Secret
The probability that a random attempt will succeed or a false acceptance will occur is
1/96^8 which is less than 1/1,000,000.
The maximum possible authentication attempts within a minute are 16 attempts. The
probability of successfully authenticating to the module within one minute is
16/96^8 which is less than 1/100,000.
REST OF THIS PAGE WAS INTENTIONALLY LEFT BLANK.
Next page 
28
Table 16 – Description of Services in Approved mode of operation
Service Name Description FOS Interface
FIPSCfg
Control FIPS mode operation
and related functions.
fipscfg
Zeroize Zeroize all CSPs. fipgscfg--zeroize
FirmwareManagement Controlfirmware management.
firmwarecommit firmwaredownload
firmwaredownloadstatus, firmwareshow
PKI
PKI configuration functions,
including FOS switch certificates
and SSL certificates.
seccertmgmt
RADIUS RADIUSconfigurationfunctions. aaaconfig
LDAP LDAP configuration functions. aaaconfig
UserManagement
User and password
management.
passwd passwdconfig userconfig
SSHv2 and TLS Crypto configuration seccryptocfg
SNMPv3 SNMPv3 configuration snmpconfig
REST OF THIS PAGE WAS INTENTIONALLY LEFT BLANK.
Next page 
29
6 Access Control Policy
6.1 Roles and Services
Table 17 - Services Authorized for Roles- Strengths of Authentication Mechanisms
Roles
Services
Us
e
r
Admin
(Crypto-Officer)
FabricA
dmi
n
SecurityAdmin
LDAP
Server
RADIUS
Server
SNMP
FIPSCfg X X
Zeroize X X
FirmwareManagement X X X X
PKI X X X X
RADIUS X X X
LDAP X X X
UserManagement X X X
SSHv2 and TLS X X X
SNMPv3 X X X X
6.2 Unauthenticated Services
The cryptographic module supports the following unauthenticated services:
 Self-tests: This service executes the suite of self-tests required by FIPS 140-2. Self-tests
may be initiated by power-cycling the module.
 Show Status: This service is met through the various status outputs provided by the services
provided above, as well as the LED interfaces.
REST OF THIS PAGE WAS INTENTIONALLY LEFT BLANK.
Next page 
30
6.3 Definition of Critical Security Parameters (CSPs)
DH Private Key:
 DH Private Keys for use with 2048 bit modulus
SSHv2/SCP/SFTP CSPs:
 SSHv2/SCP/SFTP Encryption Keys
 SSHv2/SCP/SFTP Authentication Key
 SSHv2 KDF Internal State
 SSHv2 DH Shared Secret Key (2048 bit)
 SSHv2 ECDH Shared Secret Key (P-256)
 SSHv2 ECDH Private Key (P-256)
 SSHv2 ECDSA Private Key (P-256)
 Value of K during SSHv2 P-256 ECDSA session
TLS CSPs:
 TLS Private Key (RSA 2048)
 TLS Pre-Master Secret
 TLS Master Secret
 TLS KDF Internal State
 TLS Session Keys - 128, 256 bit AES CBC
 TLS Authentication Key for HMAC-SHA-1 (160 bits) and HMAC-SHA-256
CP DRBG CSPs:
 CP DRBG Seed Material
 CP DRBG Internal State (V and Key)
Passwords:
 Passwords
RADIUS Secret:
 RADIUS Secret
SNMPv3 CSPs:
 SNMPv3 Auth and Priv password
 SNMPv3 KDF Internal State
 SNMPv3 Auth and Priv Secrets
31
6.4 Definition of Public Keys
DH Public Keys:
 DH Public Key (2048 bit modulus)
 DH Peer Public Key (2048 bit modulus)
TLS Public Keys:
 TLS Public Key (RSA 2048)
 TLS Peer Public Key (RSA 2048)
FW Download Public Key:
 FW Download Public Key (RSA 2048)
SSHv2 Public Keys:
 SSHv2 ECDSA Public Key (P-256)
 SSHv2 ECDSA Peer Public Key (P-256)
 SSHv2 ECDH Public Key (P-256)
 SSHv2 ECDH Peer Public Key (P-256)
LDAP ROOT CA Public Key:
 LDAP ROOT CA certificate (RSA 2048)
RADIUS ROOT CA Public Key:
 RADIUS ROOT CA certificate (RSA 2048)
REST OF THIS PAGE WAS INTENTIONALLY LEFT BLANK.
Next page 
32
6.5 Definition of CSPs Modes of Access
Table below defines the relationship between access to CSPs and the different module services. Please see Section
6.3 and Section 6.4 for explicit designation of CSPs and Public Keys. The modes of access shown in the table are
defined as follows:
 R: Read
 W: Write
 N: No Access
 Z: Zeroize (Session Termination and “fipscfg –zeroize” command)
Table 18 - CSP Access Rights within Roles and Services
CSPs
Services
S
S
H
v
2
/SCP/SFTP
CSPs
DH
Private
Keys
TL
S
C
S
P
s
C
P
D
R
B
G
S
e
e
d
M
a
t
e
r
i
a
l
/
I
n
t
e
r
n
a
l
Sta
te
P
a
s
s
w
o
r
d
s
R
A
D
I
U
S
S
e
c
r
e
t
S
N
M
P
v
3
C
S
P
s
FIPSCfg N N N N N N N
Zeroize Z Z Z Z Z Z Z
FirmwareManagement R R N N N N N
PKI RW RW N RW N N N
RADIUS N N N N RW RW N
LDAP N N N N N N N
UserManagement N N RW RW RW N N
SSHv2 and TLS RW RW RW N RW N N
SNMPv3 N N N N RW N RW
REST OF THIS PAGE WAS INTENTIONALLY LEFT BLANK.
Next page 
33
Table 19 - Public Key Access Rights within Roles & Services
Public Keys
Services
DH
Public
Keys
TLS
Public
Keys
Firmware
Download
Public
Key
SSHv2
Public
Key
s
LDAP
Root
C
A
Certificate
RADIUS
Root
C
A
Certificate
FIPSCfg N N N N N N
Zeroize N N N N N N
FirmwareManagement N N RW N N N
PKI N RW N RW N N
RADIUS N N N N N RW
LDAP N N N N RW N
UserManagement N N N N N N
SSHv2 and TLS RW RW N RW R N
SNMPv3 N N N N N
N
7 OperationalEnvironment
The FIPS 140-2 Area 6 Operational Environment requirements are not applicable because the device
supports a limited operational environment; only trusted, validated code RSA signed may be executed.
REST OF THIS PAGE WAS INTENTIONALLY LEFT BLANK.
Next page 
34
8 Security Rules
The cryptographic modules’ design corresponds to the cryptographic module’s security rules. This
section documents the security rules enforced by the cryptographic module to implement the security
requirements of this FIPS140-2 Level 2 module.
1) The cryptographic module shall provide role-based authentication.
2) When the module has not been placed in a valid role, the operator shall not have access to any
cryptographic services.
3) The cryptographic module shall perform the following tests:
a) Power up Self-Tests:
 AES (128,192 and 256) CBC Encrypt KAT
 AES (128,192 and 256) CBC Decrypt KAT
 HMAC SHA-1 KAT
 HMAC-SHA-224 KAT
 HMAC SHA-256 KAT
 HMAC SHA-384 KAT
 HMAC SHA-512 KAT
 SP800-90A DRBG KAT
 SHA-1 KAT
 SHA-256 KAT
 SHA-384 KAT
 SHA-512 KAT
 RSA 2048 SHA-256 Sign KAT
 RSA 2048 SHA-256 Verify KAT
 SP800-135 SSHv2 KDF KAT
 SP800-135 TLS 1.0 KDF KAT
 SP800-135 TLS 1.2 KDF KAT
 ECDSA KAT
 ECDH KAT (Primitive “Z” Computation KAT)
 SP800-135 SNMPv3 KDF KAT
b) Critical Functions Tests:
 RSA 2048 Encrypt/Decrypt
c) Message reporting for Status of Power-Up Self-Tests
 On Success, CP will display the status as below,
<Algorithm Detail>…..successful
 On Failure, CP will display the Power-Up Self-Tests status as shown below,
<Algorithm Detail>…..FAILED!
Next page 
35
d) Firmware Integrity Tests (128-bit EDC)
 On Failure, the following message is displayed:
Firmware integrity check failed
 On Success, the following message is displayed:
Firmware integrity test passed
e) Conditional Self-Tests
 Continuous Random Number Generator NDRNG test – Performed on non-Approved RNG.
 Continuous Random Number Generator test – performed on DRBG (CTR_DRBG, AES-
256).
 RSA 2048 SHA-256 Pairwise Consistency Test (Sign/Verify)
 RSA 2048 Pairwise Consistency Test (Encrypt/Decrypt)
 ECDSA P-256 Pairwise Consistency Test (Sign/Verify)
 Firmware Load Test (RSA 2048 with SHA-256 Signature Verification)
 Bypass Test: N/A
 Manual Key Entry Test: N/A
f) Message reporting for Status of Conditional Self-Tests
 Continuous Random Number Generator related tests
o On CP
NDRNG continuous test failed!
or
ERROR: DRBG Critical Failure! FIPS Drbg Health Check Failed
or
ERROR: DRBG Critical Failure! FIPS DRBG Init Failed
 On Failure in RSA 2048 Pairwise Consistency related Tests
Conditional tests failed at Sign/Verify
or
Conditional tests failed Encrypt/Decrypt
 On Failure in ECDSA Pairwise Consistency related Tests
ECDSA pair wise consistency test failed
 On Failure in Firmware Load Test
Firmware download failed - Failed to download RPM package
or
Firmwaredownload failed because the signature for the firmware could not be
validated.
g) At any time the cryptographic module is in an idle state, the operator shall be capable of
commanding the module to perform the power-up self-test.
4) Data output shall be inhibited during key generation, self-tests, zeroization, and error states.
5) Status information shall not contain CSPs or sensitive data that if misused could lead to a
compromise of the module.
36
6) The module does not support a maintenance role or maintenance interface.
7) The serial port may only be accessed by the Crypto-Officer when the Crypto-Officer is physically
present at the cryptographic boundary, via a direct connection without any network access or
other intervening systems.
8) The following protocols have not been reviewed or tested by the CAVP nor CMVP
i) TLS v1.0/v1.1
ii) SSHv2
iii) TLS v1.2
iv) SNMPv3
9 Physical Security Policy
9.1 Physical Security Mechanisms
The multi-chip standalone cryptographic module includes the following physical security mechanisms:
 Production-grade components and production-grade opaque enclosure with tamper evident seals.
 Tamper evident seals.
9.2 Operator Required Actions
The operator is required to inspect the tamper evident seals, periodically, per the guidance provided in the user
documentation.
Table 20 - Inspection/Testing of Physical Security Mechanisms
Physical Security Mechanisms Recommended Frequency of
Inspection / Test
Inspection / Test Guidance Details
Tamper Evident Seals 12 months Confirm that there is no visible evidence of
tampering.
Reference Appendix A for a description of
tamper label application for all validated
platforms.
10 Mitigation of Other Attacks Policy
The module has not been designed to mitigate any specific attacks beyond the scope of
FIPS 140-2 requirements.
Table 21 - Mitigation of Other Attacks
Other Attacks Mitigation Mechanism Specific Limitations
N/A N/A N/A
37
11 Definitions and Acronyms
Table 22 - Definitions and Acronyms
Definition / Acronym Description
10 GbE 10 Gigabit Ethernet
AES Advanced Encryption Standard
CBC Cipher Block Chaining
CLI Command Line interface
CSP Critical Security Parameter
DH Diffie-Hellman
FIPS Federal Information Processing Standard
FOS Fabric Operating System
FRU Field Replaceable Unit
GbE Gigabit Ethernet
HMAC Hash Message Authentication Code
HTTP Hyper Text Transfer Protocol
KAT Known Answer Test
KDF Key Derivation Function
LDAP Lightweight Directory Access Protocol
LED Light Emitting Diode
MAC Message Authentication Code
NOS Network Operating System
NTP Network Time Protocol
PKI Public Key Infrastructure
POD Ports on Demand licensing
PROM Programmable Read-Only Memory
RADIUS Remote Authentication Dial In User Service
RNG Random Number Generator
RSA Rivest Shamir and Adleman method for asymmetric
encryption
SCP Secure Copy Protocol
SHA Secure Hash Algorithm
SSHv2 Secure Shell Protocol
Triple-DES Triple Data Encryption Standard
TLS Transport Layer Security Protocol
REST OF THIS PAGE WAS INTENTIONALLY LEFT BLANK.
Next page 
38
12 Brocade Abbreviations
Table 23 - Brocade Abbreviations
Abbreviation Description
0 1/10/40GBE SFP Zero SFP devices provided
16GB 16 Gigabit
2 CORE Two core switch blades
42P 42 Ports
8GB 8 Gigabit
BR Brocade
CP8 8G Control Processor blade
FC Fiber Channel
FC8-16 8G, 16-port, Fiber Channel port blade
FCIP Fiber Channel over Internet Protocol
GBE Gigabit Ethernet
GE Gigabit Ethernet
ICL Inter-Chassis Link
LIC License
LWL Long Wave Length
MGMT Management
POD Ports on Demand, Defines the size of an upgrade license. For example, a 24-Port POD License
allows the user to enable twenty-four additional ports
SFP Small form-factor pluggable
SWL Short wave length
UPG Upgrade
WWN World Wide Name card
REST OF THIS PAGE WAS INTENTIONALLY LEFT BLANK.
Next page 
39
13 Appendix A: Tamper Label Application
Use ethyl alcohol to clean the surface area at each tamper evident seal placement location. Prior to
applying a new seal to an area that shows seal residue, use consumer strength adhesive remove to
remove the seal residue. Then use ethyl alcohol to clean off any residual adhesive remover before
applying a new seal.
For each module to operate in a FIPS approved mode of operation, the tamper evident seals supplied in FIPS
Kit Brocade XBR-000195 (P/N: 80-1002006-02) must be installed as defined in Appendix A.
The Crypto-Officer is responsible for storing and controlling the inventory of any unused seals. The unused seals
shall be stored in plastic bags in a cool, dry environment between 60° and 70° F (15° to 20° C) and less than
50% relative humidity. Rolls should be stored flat on a slit edge or suspended by the core.
The Crypto-Officer shall maintain a serial number inventory of all used and unused tamper evident seals. The
Crypto-Officer shall periodically monitor the state of all applied seals for evidence of tampering. A seal serial
number mismatch, a seal placement change, a checkerboard destruct pattern that appears in peeled film and
adhesive residue on the substrate are evidence of tampering. The Crypto-Officer shall periodically view each
applied seal under a UV light to verify the presence of a UV wallpaper pattern. The lack of a wallpaper pattern
is evidence of tampering. The Crypto-Officer is responsible for returning a module to a FIPS approved state after
any intentional or unintentional reconfiguration of the physical security measures.
13.1 Applying Tamper-Evident Seals on the Brocade G620
The Brocade G620 requires a total of seven (7) seals. See Figure 5 through Figure 9 for details on how to position
each seal. It is recommended that you perform the steps in the order described.
NOTE: DO NOT PUT A SECOND SEAL AT THE SAME LOCATION.
Step 1. Right side: One (1) tamper evident seal is required to complete this step of the procedure.
Affix a seal, which wraps from the rear to the bottom of the unit at seal location 1. The purpose of
this seal is to secure the top cover to the chassis. See Figure 5 for correct seal orientation and
positioning.
Figure 5 – Brocade G620 Right side view with tamper evident seal
Next page 
40
Step 2. Rear: Three (3) tamper evident seals are required to complete this step of the procedure.
Affix a seal, which wraps from the rear to the bottom of the unit at each of the seal locations 2, 3
and 4. The purpose of these seals is to secure the removable fan and power supply assemblies in
place. See Figure 6 for correct seal orientation and positioning.
Figure 6 – Brocade G620 Rear view with tamper evident seals
Step 3. Left side: One (1) tamper evident seal is required to complete this step of the procedure.
Affix a seal, which wraps from the rear to the bottom of the unit at seal location 5. The purpose of
this seal is to secure the top cover to the chassis. See Figure 7 for correct seal orientation and
positioning.
Figure 7 – Brocade G620 Left side view with tamper evident seal
REST OF THIS PAGE WAS INTENTIONALLY LEFT BLANK.
Next page 
41
Step 4. Top: Zero (0) tamper evident seal is required to complete this step of the procedure.
The cover for the device is secured using seals placed in the other steps and requires no seals on
top.
Figure 8 – Brocade G620 Top view with no tamper evident seal
REST OF THIS PAGE WAS INTENTIONALLY LEFT BLANK.
Next page 
42
Step 5. Bottom: Two (2) tamper evident seals are required to complete this step of the procedure.
Affix a seal each at locations 6 and 7 across the bottom side of the module and the lip of the cover
that latches onto it, to secure the front of the top cover in place.
Figure 9 –Brocade G620 Bottom view with tamper evident seals and zoomed sections
Figure 9 shows the bottom view of the device with the seals placed at all the required locations for compliance.
REST OF THIS PAGE WAS INTENTIONALLY LEFT BLANK.
Next page 
43
14 Appendix B: Block Diagram
Figure 10 – Block Diagram
REST OF THIS PAGE WAS INTENTIONALLY LEFT BLANK.
Next page 
44
15 Appendix C: Critical Security Parameters and Public Keys
The module supports the following CSPs and Public Keys:
1. DH Private Keys for use with 2048 bit modulus
- Description: Used in SSHv2 to establish a shared secret
- Generation: As per SP800-133 Section 6.2, the random value (K) needed to generate key pairs for the finite
field is the output of the SP800-90A DRBG; this is an allowed method as per FIPS 140-2 IG D.8 Scenario 4.
- Establishment: N/A
- Storage: Plaintext in RAM
- Entry: N/A
- Output: N/A
- Key-To-Entity: User
- Destruction: Session termination and "fipscfg --zeroize" command
2. SSHv2/SCP/SFTP Encryption Keys
- Description: AES (CBC or CTR mode) supporting 128, 192, and 256 Key sizes.
- Generation: N/A
- Establishment: SSHv2 DH Key Agreement and SSHv2 KDF (SP800-135 Section 5.2); allowed method as per
FIPS 140-2 IG D.8 Scenario 4
- Storage: Plaintext in RAM
- Entry: N/A
- Output: N/A
- Key-To-Entity: User
- Destruction: Session termination or "fipscfg --zeroize" command
3. SSHv2/SCP/SFTP Authentication Key
- Description: HMAC-SHA-1 (160 bits), HMAC-SHA-256 and HMAC-SHA-512 Session authentication keys used
to authenticate and provide integrity of SSHv2 session
- Generation: N/A
- Establishment: SSHv2 DH Key Agreement and SSHv2 KDF (SP800-135 Section 5.2); allowed method as per
FIPS 140-2 IG D.8 Scenario 4
- Storage: Plaintext in RAM
- Entry: N/A
- Output: N/A
- Key-To-Entity: User
- Destruction: Session termination or "fipscfg -zeroize" command
4. SSHv2 KDF Internal State
- Description: Used to generate Host encryption and authentication key
- Generation: N/A
- Establishment: SSHv2 DH Key Agreement and SSHv2 KDF (SP800-135 Section 5.2); allowed method as per
FIPS 140-2 IG D.8 Scenario 4
- Storage: Plaintext in RAM
- Entry: N/A
- Output: N/A
- Key-To-Entity: Process
- Destruction: Session termination or "fipscfg -zeroize" command
5. SSHv2 DH Shared Secret Key (2048 bit)
- Description: Shared secret from the DH Key agreement primitive - (K) and (H). Used in SSHv2 KDF to derive
(client and server) session keys.
- Generation: N/A
- Establishment: SSHv2 DH Key Agreement; allowed method as per FIPS 140-2 IG D.8 Scenario 4
- Storage: Plaintext in RAM
- Entry: N/A
45
- Output: N/A
- Key-To-Entity: Process
- Destruction: Session termination or "fipscfg -zeroize" command
6. SSHv2 ECDH Shared Secret Key (P-256)
- Description: Shared secret from the ECDH Key Agreement primitive. Used in SSHv2 KDF to derive (client and
server) session keys
- Generation: N/A
- Establishment: SSHv2 ECDH Key Agreement; allowed method as per FIPS 140-2 IG D.8 Scenario 4
- Storage: Plaintext in RAM
- Entry: N/A
- Output: N/A
- Key-To-Entity: Process
- Destruction: Session termination or "fipscfg -zeroize" command
7. SSHv2 ECDH Private Key (P-256)
- Description: ECDH private key (NIST defined P curves)
- Generation: As per SP800-133 Section 6.2, the random value (K) needed to generate key pairs for the elliptic
curve is the output of the SP800-90A DRBG; this is Approved as per SP800-56A.
- Establishment: N/A
- Storage: Plaintext in RAM
- Entry: N/A
- Output: N/A
- Key-To-Entity: Process
- Destruction: Session termination or performing the "fipscfg -zeroize" command
8. SSHv2 ECDSA Private Key (P-256)
- Description: Used to authenticate SSHv2 server to client
- Generation: As per SP800-133 Section 6.1, key generation is performed as per FIPS 186-4 which is an
Approved key generation method
- Establishment: N/A
- Storage: Plaintext in RAM and Plaintext in Compact Flash
- Entry: N/A
- Output: N/A
- Key-To-Entity: User
- Destruction: Session termination or "fipscfg -zeroize" command
9. Value of K during SSHv2 P-256 ECDSA session
- Description: Used to generate keys that sign and verify
- Generation: As per SP800-133 Section 6.2, the random value (K) needed to generate key pairs for the
elliptic curve is the output of the SP800-90A DRBG
- Establishment: N/A
- Storage: Plaintext in RAM
- Entry: N/A
- Output: N/A
- Key-To-Entity: User
- Destruction: Session termination or "fipscfg -zeroize" command
10. TLS Private Key (RSA 2048)
- Description: RSA key used to establish TLS sessions (decrypt padded TLS Pre-Master secret key block)
- Generation: As per SP800-133 Section 6.1, key generation is performed as per FIPS 186-4 which is an
Approved key generation method
- Establishment: N/A
- Storage: Plaintext in Compact Flash
- Entry: N/A
- Output: N/A
- Key-To-Entity: Process
- Destruction: "fipscfg -zeroize" command
11. TLS Pre-Master Secret
46
- Description: 48-byte secret value used to establish the Session and Authentication key
- Generation: Approved SP800-90A DRBG
- Establishment: RSA key wrapped over TLS session; allowed as per FIPS 140-2 IG D.9
- Storage: Plaintext in RAM
- Entry: RSA key wrapped (after padding to block size) during TLS handshake
- Output: RSA key wrapped (after padding to block size) during TLS handshake
- Key-To-Entity: Process
- Destruction: Session termination or "fipscfg -zeroize" command
12. TLS Master Secret
- Description: 48 bytes secret value used to establish the Session and Authentication key
- Generation: N/A
- Establishment: TLS KDF as per SP800-135 Section 4.2.1 and 4.2.2; allowed method as per FIPS 140-2 IG
D.8 Scenario 4
- Storage: Plaintext in RAM
- Entry: N/A
- Output: N/A
- Key-To-Entity: Process
- Destruction: Session termination or "fipscfg -zeroize" command
13. TLS KDF Internal State
- Description: Values of the KDF internal state.
- Generation: N/A
- Establishment: TLS KDF as per SP800-135 Section 4.2.1 & 4.2.2; allowed method as per FIPS 140-2 IG D.8
Scenario 4
- Storage: Plaintext in RAM
- Entry: N/A
- Output: N/A
- Key-To-Entity: Process
- Destruction: Session termination or "fipscfg -zeroize" command
14. TLS Session Keys - 128, 256 bit AES CBC
- Description: AES key used to secure TLS sessions
- Generation: N/A
- Establishment: TLS KDF as per SP800-135 Section 4.2.1 & 4.2.2; allowed method as per FIPS 140-2 IG D.8
Scenario 4
- Storage: Plaintext in RAM
- Entry: N/A
- Output: N/A
- Key-To-Entity: Process
- Destruction: Session termination and "fipscfg -zeroize" command
15. TLS Authentication Key for HMAC-SHA-1 (160 bits) and HMAC-SHA-256
- Description: HMAC-SHA-1 or HMAC-SHA-256 key used to provide data authentication for TLS sessions
- Generation: N/A
- Establishment: TLS KDF as per SP800-135 Section 4.2.1 & 4.2.2; allowed method as per FIPS 140-2 IG D.8
Scenario 4
- Storage: Plaintext in RAM
- Entry: N/A
- Output: N/A
- Key-To-Entity: Process
- Destruction: Session termination and "fipscfg -zeroize" command
16. CP DRBG Seed Material
- Description: Seed material for SP800-90A DRBG (AES-256-CTR DRBG)
- Generation: Internally generated; raw random data from NDRNG
- Establishment: N/A
- Storage: Plaintext in RAM
- Entry: N/A
- Output: N/A
47
- Key-To-Entity: Process
- Destruction: Session termination or "fipscfg -zeroize" command
17. CP DRBG Internal State (V and Key)
- Description: SP800-90A DRBG (AES-256-CTR DRBG) Internal State
- Generation: SP800-90A DRBG seeded by raw random data from NDRNG
- Establishment: N/A
- Storage: Plaintext in RAM
- Entry: N/A
- Output: N/A
- Key-To-Entity: Process
- Destruction: "fipscfg -zeroize" command
18. Passwords
- Description: Password used to authenticate operators (8 to 40 characters)
- Generation: N/A
- Establishment: N/A
- Storage: MD5, SHA-256 or SHA-512 digest in Compact Flash (Plaintext)
- Entry: Encrypted/Authenticated over SSHv2 session
- Output: N/A
- Key-To-Entity: User
- Destruction: "fipscfg -zeroize" command
19. RADIUS Secret
- Description: Used to authenticate the RADIUS Server (8 to 40 characters)
- Generation: N/A
- Establishment: N/A
- Storage: Plaintext in RAM and Compact Flash
- Entry: Encrypted/Authenticated over SSHv2 session
- Output: Encrypted/Authenticated over SSHv2 session
- Key-To-Entity: Process
- Destruction: "fipscfg -zeroize" command
20 SNMPv3 Auth and Priv password
- Description: Auth and Priv Password (8-32 bytes)
- Generation: N/A
- Establishment: N/A
- Storage: Plaintext in RAM; Plaintext in Compact Flash
- Entry: Encrypted/Authenticated over SSHv2 session
- Output: N/A
- Key-To-Entity: User
- Destruction: "fipscfg -zeroize" command
21. SNMPv3 KDF Internal State
- Description: SHA-1 Key Localization Function
- Generation: N/A
- Establishment: SNMPv3 KDF (SP800-135 Section 5.4); allowed method as per FIPS 140-2 IG D.8 Scenario 4
- Storage: Plaintext in RAM
- Entry: N/A
- Output: N/A
- Key-To-Entity: User
- Destruction: "fipscfg -zeroize" command
22. SNMPv3 Auth and Priv Secrets
- Description: Auth Secret 20-bytes (input to HMAC-SHA-1-96 function); Priv secret AES-128-CFB 128-bit key
- Generation: N/A
- Establishment: SNMPv3 KDF (SP800-135 Section 5.4); allowed method as per FIPS 140-2 IG D.8 Scenario 4
- Storage: Plaintext in RAM and Compact Flash
- Entry: N/A
- Output: N/A
48
- Key-To-Entity: User
- Destruction: "fipscfg -zeroize" command
- - - - - - - - - - - - PUBLIC KEYS - - - - - - - - - - - -
23. DH Public Key (2048 bit modulus)
- Description: Used to establish shared secrets (SSHv2)
- Generation: As per SP800-133 Section 6.2, the random value (K) needed to generate key pairs for the finite
field is the output of the SP800-90A DRBG; this is Approved as per SP800-56A.
- Establishment: N/A
- Storage: Plaintext in RAM
- Entry: N/A
- Output: N/A
- Key-To-Entity: User
24. DH Peer Public Key (2048 bit modulus)
- Description: Used to establish shared secrets (SSHv2)
- Generation: N/A
- Establishment: N/A
- Storage: Plaintext in RAM
- Entry: Plaintext
- Output: N/A
- Key-To-Entity: User
25. TLS Public Key (RSA 2048)
- Description: Used by client to encrypt TLS Pre-Master Secret
- Generation: As per SP800-133 Section 6.1, key generation is performed as per FIPS 186-4 which is an
Approved key generation method
- Establishment: N/A
- Storage: Plaintext in Compact Flash
- Entry: N/A
- Output: Plaintext
- Key-To-Entity: User
26. TLS Peer Public Key (RSA 2048)
- Description: Used to authenticate the client
- Generation: N/A
- Establishment: N/A
- Storage: Plaintext in RAM
- Entry: Plaintext
- Output: N/A
- Key-To-Entity: User
27. FW Download Public Key (RSA 2048)
- Description: Used to update the FW of the module.
- Generation: N/A; Generated outside the module
- Establishment: N/A
- Storage: Plaintext in Compact Flash
- Entry: Plaintext
- Output: Plaintext
- Key-To-Entity: User
28. SSHv2 ECDSA Public Key (P-256)
- Description: Used to authenticate SSHv2 server to client
- Generation: As per SP800-133 Section 6.1, key generation is performed as per FIPS 186-4 which is an
Approved key generation method.
- Establishment: N/A
- Storage: Plaintext in RAM and Plaintext in Compact Flash
- Entry: N/A
- Output: Plaintext
49
- Key-To-Entity: User
29. SSHv2 ECDSA Peer Public Key (P-256)
- Description: Used to authenticate SSHv2 client to server
- Generation: N/A
- Establishment: N/A
- Storage: Plaintext in RAM and Plaintext in Compact Flash
- Entry: Plaintext
- Output: N/A
- Key-To-Entity: User
30. SSHv2 ECDH Public Key (P-256)
- Description: ECDH public key (NIST defined P curves)
- Generation: As per SP800-133 Section 6.2, the random value (K) needed to generate key pairs for the elliptic
curve is the output of the SP800-90A DRBG; this is Approved as per SP800-56A.
- Establishment: N/A
- Entry: N/A
- Output: Plaintext
- Storage: Plaintext in RAM
- Key-To-Entity: Process
31. SSHv2 ECDH Peer Public Key (P-256)
- Description: ECDH public key (NIST defined P curves)
- Generation: As per SP800-133 Section 6.2, the random value (K) needed to generate key pairs for the elliptic
curve is the output of the SP800-90A DRBG; this is Approved as per SP800-56A.
- Establishment: N/A
- Entry: Plaintext
- Output: N/A
- Storage: Plaintext in RAM
- Key-To-Entity: Process
32. LDAP ROOT CA certificate (RSA 2048)
- Description: Used to authenticate LDAP server
- Generation: N/A
- Establishment: N/A
- Storage: Plaintext in RAM and Plaintext in Compact Flash
- Entry: Plaintext
- Output: Plaintext
- Key-To-Entity: Process
33. RADIUS ROOT CA certificate (RSA 2048)
- Description: Used to authenticate RADIUS server
- Generation: N/A
- Establishment: N/A
- Storage: Plaintext in RAM and Plaintext in Compact Flash
- Entry: Plaintext
- Output: Plaintext
- Key-To-Entity: Process
50
16 Appendix D: CKG as per SP800-133
In accordance with FIPS 140-2 IG D.12, the cryptographic module performs Cryptographic Key Generation
(CKG) as per SP800-133 (vendor affirmed). The resulting generated seed, for asymmetric key generation, is the
unmodified output from SP800-90A DRBG. Please see section 15 - Appendix C: Critical Security Parameters
and Public Keys, above, for further details.