Copyright © 2021 Sophos Limited
This non-proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.
Sophos Cryptographic Module
FIPS 140-2 Non-Proprietary Security Policy
Document Version 1.0
June 22, 2021
Prepared for: Prepared by:
Sophos Limited
The Pentagon
Abingdon Science Park
Abingdon OX14 3YP
United Kingdom
sophos.com
Corsec Security, Inc.
13921 Park Center Road
Suite 460
Herndon, VA 20171
USA
corsec.com
+1 703.276.6050
FIPS 140-2 Security Policy Sophos Cryptographic Module
Page 2 of 15
References
Reference Full Specification Name
[ANS X9.31] Digital Signatures Using Reversible Public Key Cryptography for the Financial Services
Industry (rDSA)
[FIPS 140-2] Security Requirements for Cryptographic Modules, May 25, 2001
[FIPS 180-4] Secure Hash Standard (SHS)
[FIPS 186-2] Digital Signature Standard (DSS) [withdrawn]
[FIPS 186-4] Digital Signature Standard (DSS)
[FIPS 197] Advanced Encryption Standard (AES)
[FIPS 198-1] The Keyed-Hash Message Authentication Code (HMAC)
[IG] Implementation Guidance for FIPS 140-2 and the Cryptographic Module Validation Program
[SP 800-38A] Recommendation for Block Cipher Modes of Operation: Methods and Techniques
[SP 800-38B] Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication
[SP 800-38C] Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication
and Confidentiality
[SP 800-38D] Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and
GMAC
[SP 800-38E] Recommendation for Block Cipher Modes of Operation: the XTS-AES Mode for Confidentiality
on Storage Devices
[SP 800-56Ar1] Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm
Cryptography
[SP 800-56Ar3] Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm
Cryptography
[SP 800-57r5] Recommendation for Key Management: Part 1 - General
[SP 800-67r2] Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher
[SP 800-89] Recommendation for Obtaining Assurances for Digital Signature Applications
[SP 800-90Ar1] Recommendation for Random Number Generation Using Deterministic Random Bit
Generators
[SP 800-131Ar2] Transitioning the Use of Cryptographic Algorithms and Key Lengths
[SP 800-133r2] Recommendation for Cryptographic Key Generation
FIPS 140-2 Security Policy Sophos Cryptographic Module
Page 3 of 15
Table of Contents
References.........................................................................................................................................2
1 Introduction ...............................................................................................................................4
2 Ports and Interfaces....................................................................................................................5
3 Modes of Operation and Cryptographic Functionality ..................................................................6
3.1 Approved Mode............................................................................................................................ 6
3.2 Non-Approved but Allowed Services ............................................................................................ 7
3.3 Non-Approved Services ................................................................................................................ 7
3.4 Critical Security Parameters and Public Keys................................................................................ 8
4 Roles, Authentication and Services............................................................................................10
5 Self-Tests..................................................................................................................................12
6 Operational Environment..........................................................................................................13
7 Mitigation of other Attacks .......................................................................................................14
Appendix A - Installation and Usage Guidance ..................................................................................15
FIPS 140-2 Security Policy Sophos Cryptographic Module
Page 4 of 15
1 Introduction
This document is the non-proprietary Security Policy for the Sophos Cryptographic Module, hereafter
referred to as the Module.
The Module is a software library providing a C language application program interface (API) for use by
other processes that require cryptographic functionality. The Module is classified by FIPS 140-2 as a
software module, multi-chip standalone module embodiment. The physical cryptographic boundary is the
general-purpose computer on which the module is installed. The logical cryptographic boundary of the
Module is the fipscanister object module, a single object module file named fipscanister.o. The Module
performs no communications other than with the calling application (the process that invokes the Module
services).
The current version of the Sophos Cryptographic Module is 1.0.
The FIPS 140-2 security levels for the Module are as follows:
Table 1: Security Level of Security Requirements
Security Requirement Security Level
Cryptographic Module Specification 1
Cryptographic Module Ports and Interfaces 1
Roles, Services, and Authentication 2
Finite State Model 1
Physical Security NA
Operational Environment 1
Cryptographic Key Management 1
EMI/EMC 1
Self-Tests 1
Design Assurance 3
Mitigation of Other Attacks NA
FIPS 140-2 Security Policy Sophos Cryptographic Module
Page 5 of 15
Figure 1: Module Block Diagram
2 Ports and Interfaces
The physical ports of the Module are the same as the computer system on which it is executing. The logical
interface is a C language application program interface (API).
Table 2: Logical Interfaces
Logical interface type Description
Control input API entry point and corresponding stack parameters
Data input API entry point data input stack parameters
Status output API entry point return values and status stack parameters
Data output API entry point data output stack parameters
As a software module, control of the physical ports is outside module scope; however, when the module
is performing self-tests, or is in an error state, all output on the logical data output interface is inhibited.
The module is single-threaded and in error scenarios returns only an error value (no data output is
returned).
FIPS 140-2 Security Policy Sophos Cryptographic Module
Page 6 of 15
3 Modes of Operation and Cryptographic Functionality
The Module supports FIPS 140-2 Approved, Allowed and Non-Approved algorithms in a single mixed mode
of operation.
3.1 Approved Mode
The Module supports the following services and algorithms in FIPS Approved mode:
Table 3: FIPS Approved Cryptographic Functions
Function Algorithm Options Cert. #
Random Number
Generation;
Symmetric Key
Generation
[SP 800-90Ar1] DRBG1
Prediction resistance
supported for all
variations
Hash_Based DRBG: All SHA sizes
HMAC_Based DRBG: All SHA sizes
CTR_DRBG: AES-128, AES-192, AES-256 (with and without
derivation function)
A1398
Cryptographic Key
Generation (CKG)
[SP 800-133r2] CKG Vendor
affirmed
Encryption,
Decryption and
CMAC
[SP 800-67r2] Triple-DES
[SP 800-38B] CMAC
TECB, TCBC, TCFB, TOFB: 3-Key
CMAC generate and verify: 3-Key
A1398
[FIPS 197] AES
[SP 800-38B] CMAC
[SP 800-38C] CCM
[SP 800-38D] GCM
[SP 800-38E] XTS
ECB, CBC, OFB, CFB, CTR: 128/192/256
CMAC generate and verify: 128/192/256
CCM: 128/192/256
GCM: 128/192/256
XTS: 128/256
A1398
Message Digests [FIPS 180-4] SHA SHA-1, SHA-2 (224, 256, 384, 512) A1398
Keyed Hash [FIPS 198] HMAC SHA-1, SHA-2 (224, 256, 384, 512) A1398
Digital Signature
and Asymmetric
Key Generation
[FIPS 186-2] RSA SigVer9.31, SigVerPKCS1.5, SigVerPSS: 1024/1536/2048/
3072/4096 with all SHA sizes
A1398
[FIPS 186-4] RSA KeyGen: 2048/3072
SigGen9.31, SigGenPKCS1.5, SigGenPSS: 2048/3072/4096
with all SHA-2 sizes
A1398
[FIPS 186-4] DSA KeyPairGen: 2048/3072
PQGGen, SigGen: 2048/3072 with all SHA-2 sizes
PQGVer, SigVer: 1024/2048/3072 with all SHA sizes
A1398
[FIPS 186-4] ECDSA PKG: P-224, P-256, P-384, P-521, K-233, K-283, K-409,
K-571, B-233, B-283, B-409, B-571; ExtraRandomBits,
TestingCandidates
PKV: All NIST defined B, K and P curves
SigGen: P-224, P-256, P-384, P-521, K-233, K-283, K-409,
K-571, B-233, B-283, B-409, B-571; all SHA-2 sizes
SigVer: All NIST defined B, K and P curves; all SHA sizes
A1398
KAS-SSC [X1]2
[SP 800-56Ar3] Diffie-Hellman ≥ 2048 bits
ECDH B, K, and P curves ≥ 256-bit curves
Vendor
affirmed
1 For all DRBGs the "supported security strengths" is just the highest supported security strength per [SP 800-90Ar1] and [SP 800-
57r5].
2 In the approved mode, KAS-SSC can only be used in conjunction with an Approved KDF from SP 800-56C or SP 800-135.
FIPS 140-2 Security Policy Sophos Cryptographic Module
Page 7 of 15
3.2 Non-Approved but Allowed Services
The Module supports the following non-Approved but allowed services:
Table 4: Non-FIPS Approved but Allowed Cryptographic Functions
Category Algorithm Description
Key Encryption/
Decryption
RSA RSA may be used to perform key establishment with another module by securely
exchanging symmetric encryption keys with another module.
The module supports the following non-FIPS 140-2 approved but allowed algorithms:
● RSA (key wrapping; key establishment methodology provides between 112 and 256 bits of
encryption strength; non-compliant less than 112 bits of encryption strength)
3.3 Non-Approved Services
The Module implements the following services which are non-approved per the [SP 800-131Ar2]
transition:
Table 5: Non-FIPS Approved Cryptographic Functions
Function Algorithm Options
Digital Signature
and Asymmetric
Key Generation
[FIPS 186-2] RSA GenKey9.31, SigGen9.31, SigGenPKCS1.5, SigGenPSS (1024/1536 with all
SHA sizes, 2048/3072/4096 with SHA-1)
[FIPS 186-2] DSA PQGGen, KeyPairGen, SigGen (1024 with all SHA sizes, 2048/3072 with
SHA-1)
[FIPS 186-4] DSA PQGGen, KeyPairGen, SigGen (1024 with all SHA sizes, 2048/3072 with
SHA-1)
[FIPS 186-2] ECDSA PKG: P-192, K-163, B-163
SigGen: P-192, P-224, P-256, P-384, P-521, K-163, K-233, K-283, K-409, K-
571, B-163, B-233, B-283, B-409, B-571
[FIPS 186-4] ECDSA PKG: P-192, K-163, B-163
SigGen: P-192, K-163, B-163 with all SHA sizes; P-224, P-256, P-384, P-521,
K-233, K-283, K-409, K-571, B-233, B-283, B-409, B-571 with SHA-1
ECC CDH (KAS) [SP 800-56Ar1]
(§5.7.1.2)
P-192, K-163, B-163
These algorithms shall not be used when operating in the FIPS Approved mode of operation. Use of the
non-conformant algorithms listed in Table 5 will place the module in a non-approved mode of operation.
FIPS 140-2 Security Policy Sophos Cryptographic Module
Page 8 of 15
3.4 Critical Security Parameters and Public Keys
All CSPs used by the Module are described in this section. All access to these CSPs by Module services is
described in Section 4. The CSP names are generic, corresponding to API parameter data structures.
Table 6: Critical Security Parameters
CSP Name Description
RSA SGK RSA (2048 to 15360 bits) signature generation key
RSA KDK RSA (2048 to 16384 bits) key decryption (private key transport) key
DSA SGK [FIPS 186-4] DSA (2048/3072) signature generation key
DH Private Diffie-Hellman > 2048 private key agreement key
ECDSA SGK ECDSA (All NIST defined B, K, and P curves except sizes 163 and 192) signature generation
key
EC DH Private EC DH (All NIST defined B, K, and P curves except sizes 163 and 192) private key agreement
key
AES EDK AES (128/192/256) encrypt / decrypt key
AES CMAC AES (128/192/256) CMAC generate / verify key
AES GCM3
AES (128/192/256) encrypt / decrypt / generate / verify key
AES XTS AES (256/512) XTS encrypt / decrypt key
Triple-DES EDK Triple-DES (3-Key) encrypt / decrypt key
Triple-DES CMAC Triple-DES (3-Key) CMAC generate / verify key
HMAC Key Keyed hash key (160/224/256/384/512)
Hash_DRBG CSPs V (440/888 bits) and C (440/888 bits), entropy input (length dependent on security strength)
HMAC_DRBG CSPs V (160/224/256/384/512 bits) and Key (160/224/256/384/512 bits), entropy input (length
dependent on security strength)
CTR_DRBG CSPs V (128 bits) and Key (AES 128/192/256), entropy input (length dependent on security
strength)
CO-AD-Digest Pre-calculated HMAC-SHA-1 digest used for Crypto Officer role authentication
User-AD-Digest Pre-calculated HMAC-SHA-1 digest used for User role authentication
Authentication data is loaded into the module during the module build process, performed by an
authorized operator (Crypto Officer), and otherwise cannot be accessed.
The module does not output intermediate key generation values.
Table 7: Public Keys
Public Key Name Description
RSA SVK RSA (1024 to 16384 bits) signature verification public key
RSA KEK RSA (2048 to 16384 bits) key encryption (public key transport) key
DSA SVK [FIPS 186-4] DSA (2048/3072) signature verification key
ECDSA SVK ECDSA (All NIST defined B, K and P curves) signature verification key
DH Public Diffie-Hellman public key agreement key
EC DH Public EC DH (All NIST defined B, K and P curves) public key agreement key
3 The Module’s IV is generated internally by the Module’s Approved DRBG. The DRBG seed is generated inside the Module’s
physical boundary. The IV is 96 bits in length per [SP 800-38D] §8.2.2 and [IG] A.5 scenario 2. The selection of the IV construction
method is the responsibility of the user of this Module. In Approved mode, users of the Module must not utilize GCM with an
externally generated IV. The only Approved use of GCM is with TLS and with a randomly generated IV.
FIPS 140-2 Security Policy Sophos Cryptographic Module
Page 9 of 15
For all CSPs and Public Keys:
Storage: RAM, associated to entities by memory location. The Module stores DRBG state values for the
lifetime of the DRBG instance. The module uses CSPs passed in by the calling application on the stack. The
Module does not store any CSP persistently (beyond the lifetime of an API call), with the exception of
DRBG state values used for the Module’s default key generation service.
Generation: The Module implements SP 800-90A compliant DRBG services for creation of symmetric keys,
and for generation of DSA, elliptic curve, and RSA keys as shown in Table 3. The calling application is
responsible for storage of generated keys returned by the Module. For operation in the Approved mode,
Module users (the calling applications) shall use entropy sources that contain at least 112 bits of entropy.
To ensure full DRBG strength, the entropy sources must meet or exceed the security strengths shown in
the table below:
Table 8: DRBG Entropy Requirements
DRBG Type Underlying Algorithm Minimum Seed Entropy
Hash_DRBG or HMAC_DRBG
SHA-1 128
SHA-224 192
SHA-256 256
SHA-384 256
SHA-512 256
CTR DRBG
AES-128 128
AES-192 192
AES-256 256
Entry: All CSPs enter the Module’s logical boundary in plaintext as API parameters, associated by memory
location; however, none cross the physical boundary.
Output: The Module does not output CSPs, other than as explicit results of key generation services;
however, none cross the physical boundary.
Destruction: Zeroization of sensitive data is performed automatically by API function calls for temporarily
stored CSPs. In addition, the module provides functions to explicitly destroy CSPs related to random
number generation services. The calling application is responsible for parameters passed into and out of
the module.
Private and secret keys as well as seeds and entropy input are provided to the Module by the calling
application, and are destroyed when released by the appropriate API function calls. Keys residing in
internally allocated data structures (during the lifetime of an API call) can only be accessed using the
Module defined API. The operating system protects memory and process space from unauthorized access.
Only the calling application that creates or imports keys can use or export such keys. All API functions are
executed by the invoking calling application in a non-overlapping sequence such that no two API functions
will execute concurrently. An authorized application as user (Crypto-Officer and User) has access to all key
data generated during the operation of the Module.
Use: In the case of AES-GCM, the IV generation method is user selectable and the value can be computed
in more than one manner.
FIPS 140-2 Security Policy Sophos Cryptographic Module
Page 10 of 15
Following RFC 5288 for TLS, the module ensures that it's strictly increasing and thus cannot repeat. When
the IV exhausts the maximum number of possible values for a given session key, the first party, client or
server, to encounter this condition may either trigger a handshake to establish a new encryption key in
accordance with RFC 5246, or fail. In either case, the module prevents and IV duplication and thus enforces
the security property.
In the event that Module power is lost and restored, the calling application must ensure that any AES-
GCM keys used for encryption or decryption are re-distributed.
The calling application shall ensure that the same Triple-DES key is not used to encrypt more than 216
64-
bit blocks of data.
4 Roles, Authentication and Services
The Module implements the required User and Crypto Officer roles and requires authentication for those
roles. Only one role may be active at a time, and the Module does not allow concurrent operators. The
User or Crypto Officer role is assumed by passing the appropriate password to the
FIPS_module_mode_set() function. The password values may be specified at build time and must have
a minimum length of 16 characters. Any attempt to authenticate with an invalid password will result in an
immediate and permanent failure condition rendering the Module unable to enter the FIPS mode of
operation, even with subsequent use of a correct password.
Authentication data is loaded into the Module during the Module build process, performed by the Crypto
Officer, and otherwise cannot be accessed.
Since the minimum password length is 16 characters, the probability of a random successful
authentication attempt in one try is a maximum of 1/25616
, or less than 1/1038
. The Module permanently
disables further authentication attempts after a single failure, so this probability is independent of time.
Both roles have access to all of the services provided by the Module.
● User Role (User): Loading the Module and calling any of the API functions.
● Crypto Officer Role (CO): Installation of the Module on the host computer system and calling of
any API functions.
All services implemented by the Module are listed below, along with a description of service CSP access.
The access types are determined as follows:
- Generate (G): Generate the Critical Security Parameter (CSP) using an approved Random Bit Generator
- Read (R): Export the CSP
- Write (W): Enter/establish and store a CSP
- Destroy (D): Overwrite the CSP
- Execute (E): Employ the CSP
- None: No access to CSPs
FIPS 140-2 Security Policy Sophos Cryptographic Module
Page 11 of 15
Table 9: Services and CSP Access
Service Role Description Access
Type
Initialize User, CO Module initialization. Does not access CSPs.
CO-AD-Digest, User-AD-Digest
E
Self-test User, CO Perform self-tests (FIPS_selftest). None
Show Status User, CO Functions that provide module status information:
● Version (as unsigned long or const char *)
● FIPS Mode (Boolean)
None
Zeroize User, CO Functions that destroy CSPs:
● fips_drbg_uninstantiate
DRBG CSPs (Hash_DRBG CSPs, HMAC_DRBG CSPs, CTR_DRBG CSPs)
All other services automatically overwrite CSPs stored in allocated
memory. Stack cleanup is the responsibility of the calling application.
D
Random
Number
Generation
User, CO Used for random number and symmetric key generation
● Seed or reseed a DRBG instance
● Determine security strength of a DRBG instance
● Obtain random data
DRBG CSPs (Hash_DRBG CSPs, HMAC_DRBG CSPs, CTR_DRBG CSPs)
E
Asymmetric Key
Generation
User, CO Used to generate DSA, ECDSA and RSA keys:
RSA SGK, RSA SVK; DSA SGK, DSA SVK; ECDSA SGK, ECDSA SVK
G
Symmetric
Encrypt/
Decrypt
User, CO Used to encrypt or decrypt data.
AES EDK, Triple-DES EDK, AES GCM, AES XTS (passed in by the calling
process)
E
Symmetric
Digest
User, CO Used to generate or verify data integrity with CMAC.
AES CMAC, Triple-DES CMAC (passed in by the calling process)
E
Message Digest User, CO Used to generate a SHA-1 or SHA-2 message digest. None
Keyed Hash User, CO Used to generate or verify data integrity with HMAC.
HMAC Key (passed in by the calling process)
E
Key Transport4
User, CO Used to encrypt or decrypt a key value on behalf of the calling process
(does not establish keys into the module).
RSA KDK, RSA KEK (passed in by the calling process)
E
Key Agreement User, CO Used to perform key agreement primitives on behalf of the calling process
(does not establish keys into the module).
Diffie-Hellman/EC Diffie-Hellman Private, Diffie-Hellman/EC Diffie-Hellman
Public (passed in by the calling process)
E
Digital Signature User, CO Used to generate or verify RSA, DSA or ECDSA digital signatures.
RSA SGK, RSA SVK; DSA SGK, DSA SVK; ECDSA SGK, ECDSA SVK (passed in
by the calling process)
E
Utility User, CO Miscellaneous helper functions. None
4 "Key transport" can refer to a) moving keys in and out of the module or b) the use of keys by an external application. The latter
definition is the one that applies to the Module.
FIPS 140-2 Security Policy Sophos Cryptographic Module
Page 12 of 15
5 Self-Tests
The Module performs the self-tests listed below on invocation of “initialize” or “self-test”.
Table 10: Power-On Self-Tests (KAT = Known answer test; PCT = Pairwise consistency test)
Algorithm Type Test Attributes
Software integrity KAT HMAC-SHA1
HMAC KAT One KAT per SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512
Per [IG] 9.3, this testing covers SHA POST requirements.
AES KAT Separate encrypt and decrypt, ECB mode, 128-bit key length
AES CCM KAT Separate encrypt and decrypt, 192-bit key length
AES GCM KAT Separate encrypt and decrypt, 256-bit key length
XTS-AES KAT 128, 256-bit key sizes to support either the 256-bit key size (for XTS-AES-128) or the
512-bit key size (for XTS-AES-256)
AES CMAC KAT Generate and verify CBC mode, 128, 192, 256-bit key lengths
Triple-DES KAT Separate encrypt and decrypt, ECB mode, 3-Key
Triple-DES CMAC KAT CMAC generate and verify, CBC mode, 3-Key
RSA KAT Sign and verify using 2048-bit key, SHA-256, PKCS#1
DSA PCT Sign and verify using 2048-bit key, SHA-384
DRBG KAT CTR_DRBG: AES, 256 bits with and without derivation function
HASH_DRBG: SHA-256
HMAC_DRBG: SHA-256
ECDSA PCT Key gen, sign, verify using P-224, K-233 and SHA-512
ECC CDH KAT Shared secret calculation per SP 800-56A §5.7.1.2, [IG] 9.6
The Module is installed using one of the set of instructions in Appendix A, as appropriate for the target
system. The HMAC-SHA-1 of the Module distribution file as tested by the CMT Laboratory and listed in
Appendix A is verified during installation of the Module file as described in Appendix A.
Per [IG] 9.10, the Module implements a default entry point and automatically runs the FIPS self-tests upon
startup.
The module has a function called FIPS_module_mode_set() within the init code that is automatically
set to enable “FIPS Mode” by default. When the Module is initialized, it will always run its power-on self-
tests, meeting the [IG] 9.10 requirement.
The module also has a Boolean check value to verify whether the module has run its power-on self-tests
upon subsequent instantiations. If the module is determined to have already run its power-on self-tests,
future instantiations will only run the power-up integrity test and not the full set of POSTs. If power is lost
to the module, the Boolean check value “1” is zeroized and the module will run its power-up self-tests
again to verify the correctness of the module operation. Upon successful completion of the POSTs, the
Boolean check value is restored. This is consistent with the requirement described in [IG] 9.11.
FIPS 140-2 Security Policy Sophos Cryptographic Module
Page 13 of 15
The Module also implements the following conditional tests:
Table 11: Conditional Tests
Algorithm Test
DRBG Tested as required by [SP 800-90Ar1] Section 11
DRBG FIPS 140-2 continuous test for stuck fault
NDRNG FIPS 140-2 continuous test for NDRNG
DSA Pairwise consistency test on each generation of a key pair
ECDSA Pairwise consistency test on each generation of a key pair
RSA Pairwise consistency test on each generation of a key pair
In the event of a DRBG self-test failure, the calling application must uninstantiate and re-instantiate the
DRBG per the requirements of [SP 800-90Ar1]; this is not something the Module can do itself.
Pairwise consistency tests are performed for both possible modes of use, e.g. Sign/Verify and
Encrypt/Decrypt.
6 Operational Environment
The tested operating systems segregate user processes into separate process spaces. Each process space
is logically separated from all other processes by the operating system software and hardware. The
Module functions entirely within the process space of the calling application, and implicitly satisfies the
FIPS 140-2 requirement for a single user mode of operation.
The module was tested in the following configurations.
Table 12: Tested Configurations
# Operating System Processor
Optimizations
(Target) Platform
1 Sophos Firewall Operating System (SFOS) 18.5 AMD Ryzen Embedded V1780B PAA XGS 3100
2 Sophos Firewall Operating System (SFOS) 18.5 AMD Ryzen Embedded V1780B None XGS 3100
As described in [IG] 1.21, Processor Algorithm Acceleration (PAA) describes mathematical constructs and
not the complete cryptographic algorithm (as defined in the NIST standards). Examples of PAA supported
by the Module include AES-NI and NEON.
See Appendix A for additional information on installation and usage.
As allowed by [IG] G.5, Maintaining validation compliance of software or firmware cryptographic modules,
the validation status of the Module is maintained when operated in the following additional operating
environments:
• SFOS 18 on XGS series models to include
o XGS 87, XGS 87w, XGS 107, XGS 107w
o XGS 116, XGS 116w, XGS 126, XGS 126w, XGS 136, XGS 136w
o XGS 2100, XGS 2300, XGS 3100, XGS 3300
o XGS 4300, XGS 4500
o XGS 5500, XGS 6500
• SFOS 18 running on the following: VMware, Hyper-V, KVM, XenApp, Amazon AWS, and Microsoft
Azure.
The CMVP makes no statement as to the correct operation of the Module or the security strengths of the
generated keys when the module is ported to an operational environment that is not listed on the
validation certificate.
FIPS 140-2 Security Policy Sophos Cryptographic Module
Page 14 of 15
7 Mitigation of other Attacks
The module is not designed to mitigate against attacks which are outside of the scope of FIPS 140-2.
FIPS 140-2 Security Policy Sophos Cryptographic Module
Page 15 of 15
Appendix A - Installation and Usage Guidance
During the manufacturing process, Sophos executes the build and installation instructions for the Module.
The Module is pre-installed and configured in supported hardware (XGS Series), cloud and virtual form
factors. To ensure the SFOS will use the Module, the “system fips enable” command should be run from
the device console. There are no additional installation, configuration, or usage instructions for operators
intending to use the Module. The operator may verify the Module is in FIPS Mode by using the Device
console to run the “system fips show” command.