Allegro Cryptographic Engine

Certificate

Derived Review-Risk Graph (review prompts, not findings)

flowchart LR
  %% Deterministic review-risk graph for Allegro Cryptographic Engine
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>no library/version identified</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C5 --> I5 --> R5 --> E5
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C2,C3,C5,C6 clue;
  class I2,I3,I5,I6 infer;
  class R2,R3,R5,R6 risk;
  class E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Allegro Cryptographic Engine
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>no library/version identified</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C3,C5,C6 clueLow;

Security Policy, page by page

Allegro Software Development Corporation Allegro Cryptographic Engine Document Revision 1.1 September 2024

(Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

This document is a non-proprietary cryptographic module security policy for the Allegro Cryptographic Engine (Software Version 6.50) from Allegro Software Development Corporation. This security policy contains specification of the security rules, under which the cryptographic module operates, including the security rules derived from the requirements of the FIPS 140-3 standard.

Purpose and Use: The Allegro Cryptographic Engine (also informally referred to as “ACE,” and in this security policy as “the module”) is a software cryptographic module that runs on a general-purpose computer (GPC). It provides FIPS 140-3 approved cryptography that can be used by calling applications via a C language Application Programming Interface (API). The module meets the overall requirements applicable to a multi-chip stand-alone embodiment at FIPS 1403, Level 1. The module is a shared cryptographic library providing symmetric and asymmetric encryption and decryption, message digest, message authentication, random number generation, key generation, digital signature generation and verification, and other cryptographic functionality. As a software cryptographic module that executes on a general-purpose computer, the module depends upon the physical characteristics of the host platform. The module’s physical perimeter is defined by the enclosure around the host system on which it executes. The logical interface of the module is its Application Programming Interface, which a calling application must utilize to invoke the cryptographic services of the module, pass input data to the module and receive output data and status from the module. The module is packaged as a shared object for Linux 5.15 (Mint 21) and Windows 11 Pro. The module also includes a data file that is used for verifying the integrity of the module. The module has been validated on Linux

(Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

The module meets the overall requirements applicable at Level 1 security of FIPS 140-3. Module Type: Software Module Embodiment: MultiChipStand Cryptographic Boundary: The module’s cryptographic boundary is comprised of a single binary:

• On Linux 5.15 (Mint 21), the binary is Acelib.so with the associated digest in AceLib.dat.
• On Windows 11 Pro, the binary is AceDll.dll with the associated digest in AceDll.dll.dat. Tested Operational Environment’s Physical Perimeter (TOEPP) Figure 1 shows a block diagram of the module executing in memory, and its interactions with surrounding software components, as well as the module’s cryptographic boundary. The module supports an Application Programming Interface (API) which provides logical interfaces between the calling application and the module’s services. Figure 1: Block Diagram

Tested Module Identification

• Software, Firmware, Hybrid (Executable Code Sets): (Allegro Software Development Corporation. © 2024) Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

Table 2: Tested Module Identification – Software, Firmware, Hybrid (Executable Code Sets) Tested Operational Environments - Software, Firmware, Hybrid: Table 3: Tested Operational Environments - Software, Firmware, Hybrid The CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when ported if the specific operational environment is not listed on the validation certificate.

There are no components excluded from the module. Modes List and Description: Table 4: Modes List and Description The module supports an approved mode of operation only.

Approved Algorithms: Cipher (Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

Table 5: Approved Algorithms - Cipher Message Authentication Table 6: Approved Algorithms - Message Authentication Symmetric Key Wrap Table 7: Approved Algorithms - Symmetric Key Wrap Table 8: Approved Algorithms - Asymmetric Key Generation (Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

Algorithm KAS-ECC-SSC Sp800- 56Ar3 KAS-FFC-SSC Sp800- 56Ar3

C C A3332 A3332

AVP ert

Properties Domain Parameter Generation Methods - P-224, P- 256, P-384, P-521 Scheme - ephemeralUnified - KAS Role - initiator, responder Domain Parameter Generation Methods - MODP- 2048, MODP-3072

Reference SP 800-56A Rev. 3 SP 800-56A Rev. 3

Asymmetric Key Verification Table 9: Approved Algorithms - Asymmetric Key Verification Table 10: Approved Algorithms - Asymmetric Signature Generation Asymmetric Signature Verification Table 11: Approved Algorithms - Asymmetric Signature Verification Random Number Generation Table 12: Approved Algorithms - Random Number Generation Table 13: Approved Algorithms - Shared Secret Computation Key Derivation (Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

Table 14: Approved Algorithms - Key Derivation Hash Function Table 15: Approved Algorithms - Hash Function Table 16: Approved Algorithms - Safe Primes Generation Table 17: Approved Algorithms - Safe Primes Verification The module’s approved algorithms are specified above. There are some algorithm modes that were tested but not implemented by the module. Only the algorithms, modes, and key sizes that are implemented by the module are shown in this table. Vendor-Affirmed Algorithms:

6.1 6.1)

Table 18: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: (Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

Table 19: Non-Approved, Allowed Algorithms Caveats:

• The module includes vendor-affirmed Component Key Generation (CKG) per IG D.H and NIST SP 800133rev2. The CKG uses the method described in Sections 4 and 6.1 of SP 800-133rev2. The module generates symmetric keys and seeds for asymmetric keys, from the direct output of the DRBG. operation.
• The module provides key derivation functions for use in TLS and SSHv2. No parts of the TLS or SSHv2 protocols, other than the KDF, have been tested by the CAVP and CMVP. N/A for this module. (Allegro Software Development Corporation. © 2024) Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

(Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

Table 21: Security Function Implementations

SHA-3 & SHAKE (IG C.C) SHA-3 and SHAKE were tested and validated on all of the module’s operating environments. RSA (IG C.F) (Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

• Modulus lengths supported by the module for RSA signature generation are 2048, 3072, and 4096 bits.
• The module supports the number of Miller-Rabin tests specified in Table C.3 of FIPS 186-4.
• The RSA signature algorithm implementations are tested.
• For signature verification, the modulus size is at least 2048. AES-GCM (IG C.H) An AES-GCM key may either be generated internally or provided by application code to the cryptographic module. The IV for AES-GCM encryption shall not be generated outside the module. The probability that the authenticated encryption function will be invoked with the same initialization vector and the same key on two or more distinct sets of input data shall be no greater than 2-32. If the module’s power is lost and then restored, a new key for use with AES-GCM encryption/decryption must be established. Per IG C.H Option 2, the module generates 96-bit GCM IVs randomly as specified in SP800-38D section 8.2.2 using an approved DRBG (Cert. #A3332), that is internal to the module’s boundary. The Module does not implement the TLS protocol itself, however, it provides the cryptographic functions required for implementing the protocol. AESGCM encryption is used in the context of the TLS protocol versions 1.2 and 1.3 (per Scenario 1 and Scenario 5 in FIPS 140-3 C.H respectively). For TLS v1.2, the mechanism for IV generation is compliant with RFC 5288. The counter portion of the IV is strictly increasing. When the IV exhausts the maximum number of possible values for a given session key, this results in a failure in encryption and a handshake to establish a new encryption key will be required. It is the responsibility of the user of the module i.e., the first party, client or server, to encounter this condition, to trigger this handshake in accordance with RFC 5246. For TLS v1.3, the mechanism for IV generation is compliant with RFC 8446. The TLS 1.2 AES-GCM cipher suites from Section 3.3.1 of SP 800-52 Rev2 supported by the module are:
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xC0, 0x2B);
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA384 (0xC0, 0x2C);
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xC0, 0x2F);
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xC0, 0x30);
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x00, 0x9E);
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x00, 0x9F);
• TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (0x00, 0xA2); and
• TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (0x00, 0xA3). AES-XTS (IG C.I) AES-XTS shall only be used in storage applications. The module implements the Key_1 ≠ Key_2 check prior to the first use of the algorithm. AES-FF1 (IG C.J) The lengths of the following parameters from SP 800-38G:
• radix = 2 … 96;
• minlen = 6;
• maxlen = 2048; and
• maxTlen = 21. SP 800-107 Requirements (IG C.L) The Allegro Cryptographic Engine is a software module toolkit. The operator utilizing the algorithms and schemes specified in IG C.L shall operate in accordance with the guidance. (Allegro Software Development Corporation. © 2024) Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

PBKDF2 (IG D.N) The Allegro Cryptographic Engine requires the password to be at least ten characters in length, the iteration count at least 1000, the salt at least 128 bits in length, and that the master key output from the PBKDF2 is at least 112 bits in length. Master keys may be used as Device Protection Keys (Option 1(a) from Section 5.4 of NIST SP 800132). Alternately, they may be used with a key derivation function to produce a Device Protection Key (Option 1(b) from Section 5.4 of NIST SP 800-132). Passwords passed to the PBKDF2 implemented shall have a length of at least 10 characters and shall consist of upper- and lower-case letters and numbers (52 letters) and digits (0-9) as well as characters from the set ~!@#$%^&*. There are 71 different characters that can be used, in any order. The probability of guessing this password at random is 7110 = 1: 3.3 * 1018. This provides a password search space of more than 60 bits. The length of the random salt used in PBKDF2 must be at least 128 bits. The iteration count used in PBKDF2 must be at least

1000 and should be as large as is tolerable by the calling application. The length of the master key generated by

PBKDF2 must be at least 112 bits. The calling application may use the master key, the Data Protection Key, or it may derive the Data Protection Key from the master key using a key derivation function. The Data Protection Key shall be used for storage purposes only and shall use only approved encryption algorithms.

The entropy for seeding the SP 800-90Ar1 DRBG is determined by the user of the module, which is outside of the module’s cryptographic boundary. To be compliant, the target application shall supply at least 256 bits of entropy in order to meet the security strength required for the random number generation mechanism. Since entropy is loaded passively into the module, there is no assurance of the minimum strength of generated SSPs (e.g., keys).

SSPs that are generated internally by the module, are generated using the module's approved DRBG.

The module is capable of performing key establishment when utilizing the implemented NIST SP 800-56Ar3 shared secret computation methods, with one of the approved key derivation functions. The module also supports key transport methods compliant with NIST SP 800-38F.

While the module does not implement the TLS or SSH protocols, it does implement the key derivation functions for both, per NIST SP 800-135r1.

Please see Section 11 for details regarding the preparation of the operational environments, and installation of the module.

(Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

Table 22: Ports and Interfaces As a software cryptographic module, the module’s physical and electrical characteristics, manual controls and physical indicators are those of the host system. The host system provides physical ports that the operating system physical indicators of the GPC. The module does not support a control output interface. The module does not identify or authenticate the operator. The Crypto Officer role is assumed by the operator. Only one operator can operate the module at any time.

Table 23: Roles The Allegro Cryptographic Engine supports only one role, which is the Crypto Officer role. (Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

(Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

R,E R,E (Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

R,E R,E R,E (Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

G,W G,W G,W : G,W : G,W : G,W : G,W : G,W (Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

: G,W : G,W : G,W : R,E : R,E G,W (Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

G,W G,W Z Z Z Z :Z (Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

Z Z Z :Z R,E (Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

R,E G,W,E G,W,E (Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

The module does not support the external loading of software or firmware.

The module, which is made up of a single component, is provided in the form of binary executable code (Acelib.so for Linux and AceDll.dll for Windows). A software integrity test is performed on the runtime image of the module. The HMAC-SHA2-256 (Cert. #A3332) implemented in the module is used as an approved algorithm for the integrity test. If the test fails, the module enters an error state where no cryptographic services are provided, and data output is prohibited. (the module is not operational)

The software integrity test is performed as part of the Pre-Operational self-tests. It is automatically executed at power-on. It can also be invoked by powering-off and reloading the module, or using the AcRunSelfTest() service.

Type of Operational Environment: Modifiable How Requirements are Satisfied: The module operates in a modifiable operational environment as described by the FIPS 140-3 definition. The operating systems on which the module was tested run user processes in logically separate process spaces. When (Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

the module is present in memory, the operating system protects the module’s memory space from unauthorized access. The module functions entirely within the process space of the calling application.

The physical security requirements of FIPS 140-3 do not apply to software modules.

The module does not implement non-invasive attack mitigations.

Table 25: Storage Areas The module does not persistently store SSPs.

Table 26: SSP Input-Output Methods Note: To prevent the inadvertent output of sensitive information, two independent internal actions shall be required in order to output any plaintext CSP.

Table 27: SSP Zeroization Methods SSPs are implicitly zeroized when unloading the module or removing power, and explicitly zeroized when using AcDeInit() and AcReleaseHandle() where SSPs are overwritten with zeros. (Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

(Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

(Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

Table 28: SSP Table 1 (Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

(Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

(Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

(Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

Table 30: Pre-Operational Self-Tests The module performs the pre-operational software integrity test automatically upon every instantiation. (A CAST for HMAC-SHA2-256 executes prior to the software integrity test.)

(Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

(Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

(Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

Table 31: Conditional Self-Tests Conditional CASTs are performed automatically upon every instantiation. The pairwise consistency tests are performed on the condition that an asymmetric keypair is requested, and the AES-XTS key validation test is performed prior to using the keys, per IG C.I. The DRBG health tests required by NIST SP 800-90A, Section 11.3 (instantiate, generate, reseed) execute upon instantiation of the module and also upon the following conditions:

1. Instantiate: Any time that a new DRBG instance is created.
2. Generate: When new random data is generated.
3. Reseed: When the reseed counter has reached its pre-determined maximum value and the DRBG needs to be reseeded.

Table 32: Pre-Operational Periodic Information (Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

(Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

(Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

Table 33: Conditional Periodic Information The pre-operational software integrity test and all conditional CASTs can be executed on-demand by calling the AcRunSelfTest() service.

Table 34: Error States The module implements two error states. A hard error state, whereby recovery may be attempted by restarting or reinstalling the module, and a software error state whereby conditional self-test failures such as the pairwise tests and the AES-XTS key validation test may be recovered. Self-tests in the module return an indication of whether the invocation passed or failed. If any self-test fails, the module’s data output interfaces will be inhibited, and only control input and status output commands will be allowed to execute. To correct an on-demand or conditional self-test error, the module must be restarted by calling the AllegroTaskInit() service after the module has been de-initialized. To correct a preoperational self-test error, the module must be reloaded into memory by terminating and restarting the host application. If the pre-operational self-test fails after restarting the host application, it will be necessary to re-install the module.

The pre-operational software integrity test and all conditional CASTs can be executed by the operator using the API call AcRunSelfTest().

(Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

When built and executed, the module automatically operates in the approved mode. (Additional guidance is provided in Section 11.2.)

Initial setup for the module consists of:

1. Installing the host operating system: Linux 5.15 (Mint 21) or Windows 11 Pro.
2. Creating a new user account on the Operating System (and providing that user account with a password). The host operating system will provide the operational environment required for the module to meet FIPS 140-3, Level 1 security specifications. The Crypto Officer will create a new admin account per the guidelines of the OS user manual. (The Crypto Officer shall refer to all administrative and guidance documents in order to create a new user account on the Operating System.) The Crypto Officer is in charge of the secure management and handling of the module. The Allegro Cryptographic Engine is shipped on a DVD and delivered via FedEx. A tracking number is provided to the Crypto Officer in order to track the progress of the shipment and ensure secure delivery of the module. The Crypto Officer shall sign for the DVD upon arrival and shall maintain control of the DVD throughout its lifetime. Following the secure delivery of the module, the Crypto Officer shall first follow the steps outlined above. After the operational environment has been prepared, the module can be built in any configuration specified in Table

2 of this security policy, by consulting the build instructions provided in Chapter 5 of the ACE™ Allegro

Cryptography Engine Programming Reference, Version 6.50, included on the DVD. During normal operation, the operator may check the status of the module by attempting to run a service. If the service executes and does not return an error, the module is operating in the approved mode.

The module supports the role of Crypto Officer only, which is an administrative role.

The module may be sanitized by uninstalling the binary and power-cycling the host GPC.

The operator shall adhere to the guidelines of this Security Policy. Operators in the Crypto Officer role are able to use the approved services listed in this security policy. The operator is responsible for monitoring the module for any irregular activity.

The module does not attempt to mitigate specific attacks. (Allegro Software Development Corporation. © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).