Port Authority Series

Certificate

Approved Algorithms (16)

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

flowchart LR
  %% Deterministic review-risk graph for Port Authority Series
  %% 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>update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>self-test<br/>Status Output</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>HTTPS<br/>no library/version identified</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>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 Port Authority Series
  %% 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>update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>self-test<br/>Status Output</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>HTTPS<br/>no library/version identified</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>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

Communication Devices, Inc. Port Authority Series Hardware Version: PA111-SA CDI 01-03-0912I PA111-RM CDI 01-03-0912I PA121-RM CDI 01-03-0912I PA155-RM CDI 01-03-0912I PA199-RM CDI 01-03-0912I Firmware Version: 1.0.0 Document Version: 1.2 Date: 9/6/2024

This document sets forth to describe the security rules under which the Port Authority Series cryptographic module (the “module”) will operate, using the terminology contained in the Federal Information Processing Standards Publication 140-3, which is available at https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf on the NIST website. The format of this document follows the requirements specified in NIST SP 800-140Br1.

Purpose and Use: Out of Band Management, or OBM, refers to products that permit secured technician access to "management elements" (e.g. Firewalls, Routers, Bridges, SONET, Switches, Servers, etc.) via dial up telephone lines, isolated cellular networks and other communication channels not in bandwidth of the primary network. As in-band, or part of the primary network, control

channels both rely on connectivity in the primary network, they can become useless if there is a failure in primary network. In-band control channels are also subject to interception and other compromised conditions that the primary network could be experiencing. When the primary network goes down or is severely disrupted, control traffic has no way to get between the managed elements and the management workstations. Quite often when a managed element goes down, it loses its network connection, which renders in-band management useless. This is where the Port Authority cryptographic module always works flawlessly for OBM. To augment the Port Authority usefulness, access via local networks is available. The module is designed primarily to enable remote access to a device’s console port and provide the capability to remotely power the device on or off. The module can address the limitations of network-dependent remote authentication, which can fail if the network is not operational. The module stores its own database of user rights on board or establish a cryptographic Chain-of-Trust, allowing it to operate even in situations where the primary network is inaccessible. The module supports:

• Dialup speed up to 115.2 Kbps via an internal V.92 modem
• Cellular speed up to 1Mbps via an internal cellular modem
• Network link speed at 1G or 100M
• Power cycling of managed devices via Power Control Module ports (PCM ports)
• Access to managed device’s physical console ports via Host ports The module utilizes TLSv1.3 with AES128-GCM-SHA256 or AES256-GCM-SHA384 cipher suites to safeguard both User-Module and Crypto-Officer-Module connections. For instance, an operator can establish a secure TLS connection to another module located at a remote site, enabling the operator to securely manage devices at that remote site through TLS connection. Module Type: Hardware Module Embodiment: Multi-chip standalone Module Characteristics: None Cryptographic Boundary: The enclosure defines the cryptographic boundary of the module. The cryptographic boundary for the Port Authority consists of several components. The Port Authority consists of a modem, cellular modem, a Power Control port, a Network port, RJ45 or USB Host ports, and I/O Modules. The firmware consists of component parts such as the Encryption Module, the User Authentication Module, the Databases, and the interface buffers. The block diagram is depicted in figures below:

Figure 1: Block Diagram Depicting the Cryptographic Boundary Figure 2: PA111-SA and PA111-RM Hardware Diagram

Figure 3: PA121 Hardware Diagram

Figure 4: PA155 Hardware Diagram

Figure 5: PA199 Hardware Diagram

Figure 6: PA111-SA Figure 7: PA111-RM Figure 8: PA121-RM

The module operates in a limited operational environment. The module has been tested on the following operating environments: Tested Module Identification - Hardware: Table 2: Tested Module Identification - Hardware

There are no excluded components for this cryptographic module. Modes List and Description: Table 3: Modes of Operation When the module starts up successfully, after passing all the pre-operational self-tests, the module uses the approved mode and all communication is based on authenticated and encrypted access. The device authenticates itself via a certificate issued by a Certificate Authority (CA), allowing clients, possibly other Port Authorities, to verify the authentication of the device. Operators can be authenticated by credential or via being issued a certificate with permissions embedded within. Certificates are verified by checking the presented certificate against securely stored Certification Authority (CA) Certificates. Each of the authentication methods results in the issuance of a session token that gives access to a REST API that controls all public functions of the device. Login, token issuance and finally API usage are all secured by TLSv1.3. More detail can be found in section 11.1 and 11.2 Startup Procedures and Administrator Guidance. Mode changes instructions and status indicators This is not applicable to this module which implements only one mode of operation, the The module does not implement degraded operation.

The table below lists the approved security functions (or cryptographic algorithms) of the module, including specific key lengths employed for approved services, and implemented modes or methods of operation of the algorithms.

AES-ECB is CAVP tested but not used by the module. This algorithm can only be executed when running a self-test HMAC-SHA-1 is CAVP tested but not used by the module. SHA-1 is CAVP tested but not used by the module.

CAVP Cert

Algorithm and Standard

Mode/Method

Description / Key Size(s) / Key Strength(s)

Use / Function protocols, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP.

Vendor-Affirmed Algorithms The table below lists the vendor affirmed algorithms that are allowed in the approved mode of operation. 5.1. Table 5: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms The module does not implement any non-approved security functions that are allowed in approved services. Non-Approved, Allowed with No Security Claimed The module implements the SNMPv3 protocol which is not conformed to RFC 2574 which mandates the use of the HMAC-SHA-96 authentication protocol and CBC-DES symmetric instead. Data transmits over the SNMP protocol only contains network metrics data that is non-

the SHA-1 specified in SP 800-135r1

Table 6: Non-Approved Allowed in the Approved Mode of Operation with No Security Claimed Non-Approved, Not Allowed Algorithms The module does not implement any non-approved security functions that are not allowed in approved services.

Table 7: Security Function Implementation (SFI)

AES-GCM IV Generation The module implements the TLS protocol version 1.3 defined in RFC 8446. The module’s TLS implementation only uses AES-GCM cipher suites, and the IV is generated and only used within the TLS implementation within the cryptographic boundary of the module. The GCM IV generation complies with IG C.H under scenario 5. When the IV exhausts the maximum value of 264 – 1, the module will establish a new encryption key. The output (key, IV) pair collision probability is less than 2-32. In the event the module’s power is lost and restored, the module will establish a new key for use with the AES-GCM encryption/decryption.

Table 8: Entropy Sources Entropy Information: The module provides the CDI CPU Time Jitter for generation of random numbers with a validated SHA3-256 conditioning component (cert. #A3214). The entropy source has undergone the Entropy Server Validation program, obtaining the following cert. #E100. For more information, the following link can be consulted: https://csrc.nist.gov/projects/cryptographicmodule-validation-program/entropy-validations/certificate/100. DRBG Information Besides the Entropy Source, the module offers a SP 800-90A compliant HMAC DRBG mechanism with an HMAC SHA2-256 for creation of key components of asymmetric keys, and random numbers. The DRBG is instantiated with 128 bits of encryption strength. 440 bits of entropy input is used to seed the DRBG.

For generation of ECDSA key pairs, the module implements approved key generation services compliant with [FIPS 186-4] where the key material is directly obtained from an approved [SP 800-90Arev1] HMAC DRBG. The public and private key pair used in the EC Diffie-Hellman KAS are generated internally. They are compliant with NIST [SP 800-56Arev3]. The symmetric keys used in the TLSv1.3 and SNMPv3 contexts are derived using an approved KDF and this method is compliant with section 6.2 of [SP 800-133rev2].

Key Agreement The module provides EC Diffie-Hellman as shared secret computation method to obtain “shared secrets” values. The security strength of the preceding algorithms is as follows: • EC Diffie-Hellman key agreement provides 128 bits of encryption strength.

In addition, the module does support Key Derivation methods, listed below: • Protocol-Suite Key Derivation: TLS 1.3 KDF and SNMPv3 KDF4. Key Transport The module does not transport secret key or private key. However, the module supports public key input and output in TLS payload.

Note: no parts of the TLS v1.3 and SNMPv35 protocols, other than the approved cryptographic algorithms and KDFs, have been tested by the CAVP and CMVP. The following table shows the cipher suites information available for this cryptographic module: Table 9: Security Relevant Protocols

The base and primary applications installed at factory contains the Build server public key. When the module receives an update, the operator executes the Firmware Upload service and uses the mentioned public key to validate the package. The verification is done before installation and corresponding integrity self-tests are executed as well.

No guidance for initialization is declared. This SNMP KDF is a non-approved algorithm used by the module as a non-security function with no security claimed. This SNMPv3 protocol implements a KDF using SHA2-256, not SHA-1 as specified in SP 800-135r1. The module can only output network metrics containing only non-sensitive status data obfuscated using AES-CFB8. The status data transmitted over this protocol is considered plaintext. No security is claimed for this protocol.

Table 10: Ports and Interfaces Note*: A module can be used to remotely administer another module. interfaces is defined as traffic meant to access the control interfaces of external devices or toggle those device's power via a PCM. The traffic comes into the device via the FIPS secured mechanism and is then acted upon. In the case of accessing another device's control interface, this is typically done via the RJ45 or USB Host Ports; however, it may also include using the Network Port to access TCP/IP based control interfaces.

In the case of toggling another device's power, the Port Authority will send a signal via a RJ-11 PCM port that will tell connected PCM modules to toggle the power on or off. Crypto Officer Traffic Port Authority Crypto Officer (CO) Traffic is associated with Control Input and Control Output logical interfaces and is defined as traffic meant to configuring and securing the Port Authority device.

The module does not implement any trusted channels.

The control output interface is inhibited when the module is running any self-tests specified in Section 10.

The module includes authentication mechanisms compliant with security level 2 as well as User and Crypto Officer roles. The cryptographic module does support concurrent operators using TLS connections, but it does not support concurrent operators using dialup or cellular connection. The Port Authority does not support bypass capability or maintenance role.

The Port Authority supports two types of authentication mechanisms, certificate and credential. The authentication strength objectives for the modules are: • a probability of less than one in 1,000,000 that a single attempt will succeed, and • a probability of less than one in 100,000 that a random attempt will succeed for multiple attempts during a one-minute period. Certificate Either via an existing TLS connection between non-user entities or initiating an TLS connection directly, an operator presents a valid certificate that the operator has been granted as the Crypto Officer or User role. The certificate is checked in the following way:

1. The certificate is checked against loaded certificate authority certificates.
2. The x509v3 extension OID 1.3.6.1.4.1.50769.140.3.1 is checked to determine if the operator is a User: a. If the extension is present, then the user's Common Name become the name used by the module and is added to the access token.

b. If not, check to determine if operator is a Crypto Officer.

3. The x509v3 extension OID 1.3.6.1.4.1.50769.140.3.2.2 is checked to determine if the operator is a Crypto Officer: a. If yes, then the admin flag is set for this operator, else not set.
4. The x509v3 extension OID 1.3.6.1.4.1.50769.140.3.2.3 is checked to determine the operator's port permissions (access tag): a. These tags are added to the access token. b. If omitted, the operator will have no access to ports. This login method relies on ECDSA P-256 and SHA2-256 to secure the certificate. Historically, certificate attacks tend to target the hash function via a collision attack. This type of attack would require 2128 hashes to be computed. Even if the attack can leverage precomputation, hash generation is bottlenecked by computation power. The device can only produce a few hundred hashes per second, and even specially designed farms filled with devices meant to only generate hashes can produce Gigahashes per second. If all the hash farms worked together and produced 500 Exahashes second. Putting this all together a single attempt has a 1/(2 128) chance of succeeding and even using all the hashing power the chance of success in a minute would be: 500𝑥1018 ℎ𝑎𝑠ℎ𝑒𝑠 60 𝑠𝑒𝑐𝑜𝑛𝑑𝑠 𝑥 1 𝑚𝑖𝑛𝑢𝑡𝑒

Either via an existing TLS connection between non-user entities or initiating a TLS connection directly, the user presents credentials that correspond to a record in the device indicating User or Crypto Officer permissions. The Port Authority provides identity-based authentication. Users do not have access until a valid ID and Password are entered. The User ID and Password each has a minimum of 8 printable characters. The chance that a random attempt will be accepted is less than 1 in 1,000,000; every graphic ASCII character can be used (958 = 6.6x1015). For analog calls, after 3 failed attempts the call will be dropped and require re-dialing. At most 30 logins can be attempted in 1 minute; therefore, multiple attempts in 1 minute, yielding a strength per minute of (30/958). For cellular calls, each login attempt takes approximately 150ms. This means 400 login attempts per minute, yielding a strength per minute of (400/958 ).

Credential

ID and Password for CO and User roles over cellular

Identity-based authentication

6.0x10-14

Table 11: Authentication Methods The Port Authority unit supports the Crypto Officer and User roles. The module also allows concurrent operators with an associated TLS connection. The table below lists the available Table 12: Roles The module supports the Crypto Officer role for the purpose of programming the user and parameters. The Crypto Officer will either connect to the device via two possible methods using a TLSv1.3-based API or with a serial connection and terminal emulator. The Crypto Officer can either authenticate to the module via credential or certificate. In both situations, a time-limited access token will be issued and used by the operator when making requests to perform configuration and management actions restricted to the Crypto Officer role. User role The module supports the User role to access a remote device via the module’s Host, PCM, or Network port. To gain access to a module’s Host, PCM or Network port, a User must first create a secure TLS connection and authenticate to the module, either using certificate or credential Once authenticated, the User will be granted access to use the User Access service of the module. The User needs at minimum a User ID and Password to authenticate to the module. Certificate-based authentication is also possible if the User is set up to use certificate-base

The Roles SSP Access column has entries for each SSP accessed by that role using that service with the appropriate access indicators

• G: The module generates or derives the SSP.
• R: The SSP is read from the module (e.g. the SSP is output).
• W: The SSP is updated, imported, or written to the module.
• E: The module uses the SSP in performing a cryptographic operation.
• Z: The module resets the SSP to zero. The module provides services to operators who assume one of the roles. Only approved services are offered and listed below: G, E

The cryptographic module supports the following non-approved services. Table 14: Non-Approved Services

There are two main integrity mechanisms: one for updating packages and one runtime. Both of these mechanisms rely on:

1. The build server having a local only private key, and
2. The build server’s public key being embedded into the primary application at compilation time. The build server builds the primary application then creates a signature file for it. For other files in an update, corresponding signature files are created (which may be combined). These files are then bundled into a single update file that will also be signed by the build server. At this point, the update file is securely transferred to a customer for update. An operator acting as the Crypto Officer then uses the REST API and an admin token to send the package to the device. The device will first verify the package file has been signed by the trusted build server, else it will not proceed. It will then install the primary application and other files to their desired directories. Finally, it will fail over the new code and trigger a runtime integrity check. A runtime integrity check will be performed at boot. It will first find the signature file for the primary application and verify its own integrity before proceeding. It will verify the integrity of all files in other signature files. Assuming all the files pass this verification the integrity check passes. Only firmware validated by the CMVP shall be loaded to maintain module validation. Loading firmware updates that have not been validated means the module is no longer a validated module.

The Port Authority does not support bypass capability.

Physical security Mechanism

Recommended Frequency of Inspection/Test

Inspection/Test Guidance Details

No output of CSPs are declared for this cryptographic module.

The software components of the module are validated by using a Digital Signature (ECDSA P256) approved technique. A runtime integrity check will be performed at boot automatically and can be run on demand. It will first find the signature file for the primary application and verify its own integrity before proceeding. It will verify the integrity of all files in other signature files. If all the files pass this verification the integrity check passes.

The module provides on-demand integrity test. The integrity test is performed by the Ondemand Integrity test service, which is called on request and verifying the signature as explained in the Integrity Techniques section.

The Port Authority uses a limited operational environment. The code is stored in a FLASH chip in binary executable format. A Crypto Officer can only modify the existing code in the Port Authority by issuing an authenticated update command with a signed firmware package. Type of Operational Environment The module works in a limited operational environment.

The module should be installed as stated in section 11.

Table 15: Mechanisms and Actions Required The Port Authority series module is a multi-chip standalone cryptographic module, consisting of a number of IC chips mounted on a printed circuit board contained within a protected Each cryptographic module has a number of tamper evident seals applied as shown in the following section.

The Crypto Officer may replace damaged tamper seals. The Crypto Officer must ensure the module surface is clean and dry before applying the tamper seals. Number:

• PA111-SA: 2 tamper seals
• PA111-RM, PA121-RM, PA155-RM, PA199-RM: 4 tamper seals Placement:

Surface Preparation: cleaned with alcohol before placement Operator Responsible for Securing Unused Seals: Crypto Officer Part Numbers: NOVA Vision XUG6-K222-60S Below are the pictures illustrating the placement of the tamper seals on the modules: PA111-SA Figure 11: PA111-SA Tamper Seal at Side/Bottom Figure 12: PA111-SA Tamper Seal at Side/Bottom PA121-RM Figure 13: PA121-RM Tamper Seals at Side/Bottom and Front/Bottom

Name

From

To

Format Type

Distribution Type

Entry Type

SFI or Algorithm

Figure 14: PA121-RM Tamper Seals at Side/Bottom and Rear/Top PA111-RM, PA155-RM, and PA199-RM Figure 15: PA111-RM, PA155-RM, PA199-RM Tamper Seals at front/Top and Side/Bottom Figure 16: PA111-RM, PA155-RM, PA199-RM Tamper Seals at Rear/Bottom

The module does not implement any non-invasive mitigation techniques.

Method

Description

Rationale

Operator Initiation

Table 17: SSP Input-Output Methods

Server public key outputs as certificate signing request. Key is pre-loaded by manufacturer and new firmware may contain the key for validating the next firmware. Only Crypto Officer can create new operator (Crypto Officer or User) and set the password for the operator. The module does not allow User to change password; only Crypto Office can change password on behalf of User.

The module performs pre-operational self-test automatically when the module powers on. The ECDSA SigVer and SHA2-256 conditional known answer tests are performed before performing the pre-operational module integrity test. The integrity of the software component is then verified according to section 5, using a digital signature. If the known answer test or integrity test fails, the module transits to the Error state. The module also performs the cryptographic algorithms self-tests and critical function test defined in section 10.2. In addition, the CDI CPU Time Jitter entropy source performs start-up health testing as part of the Critical Function Tests. Table 21: Pre-Operational Self-Tests

Cryptographic Algorithm Self-Tests The module performs self-tests on approved cryptographic algorithms supported in the approved mode of operation. Data output is inhibited during the self-tests. The cryptographic algorithm self-tests are performed in the form of Known Answer Tests (KATs), in which the calculated output is compared with the expected known answer. The module performs testing on the continuous outputs of the entropy source. The CDI CPU Time Jitter entropy source executes the APT, RCT and Lag tests as approved health testing. If any of these self-tests fails, the module transitions to the Error state. Conditional Pairwise Consistency Tests The module implements the ECDSA algorithm and key generation and performs the pairwise consistency test using sign and verify functions when the keys are generated. In addition, the assurance for the KAS-ECC-SSC (per section 5.6.2 of SP 800-56Arev3, required by [IG] D.F) is verified by running conditional testing on the ephemeral key pairs created during the key agreement.

Conditional Software/Firmware Load Test When the module receives an update as a result of the execution of the Firmware Upload service, the conditional software load test is executed and the module applies a digital signature integrity technique to verify the validity of the firmware. Conditional Manual Entry Test When setting or changing a password, the module uses duplicate entries to prevent error on the part of the human operator could result in the incorrect entry of the intended value.

The following table summarizes the content of the previous subsections: Table 22: Conditional Self-Tests

On demand self-tests can be invoked by executing the services On-demand Self-tests and Ondemand Integrity test. The services request the self-test after the boot initialization sequence. During the execution of the on-demand self-tests, cryptographic services are not available, and no data output or input is possible.

Table 23: Error States If the module fails any of the self-tests, or receives an error from the system initialization or any other operational state, the module outputs an error and stops functioning, and the output interface is inhibited as well. To recover from the Error state, the operator must perform a

The base image and the primary applications are installed at factory and no other startup steps are needed.

CDI will send a serial number list electronically and securely to the customer. When the module is delivered the Crypto Officer can compare the serial number of the module against the list CDI provided and check against tampering following the Inspection/Test Guidance in Section 7.1. If any tamper evident seal is damaged, the Crypto Officer shall contact manufacturer to replace the module. The module requires the Crypto Officer to reset the default the CO password upon accessing the module for the first time or after a hard reset. The Crypto Officer should choose a password of minimum length of 8 characters with sufficient complexity and secrecy.

The Crypto Officer should check the name and version information matches the following by a request to “/v1/fips/versions”: {"Hardware":"PA111","FirmVer":"1.0.0","BldVer":"F13-1","RepoVer":" c406cc110c5c8422440c8a6ca79838238ae8f5ea "}, {"Hardware":"PA121","FirmVer":"1.0.0","BldVer":"F13-1","RepoVer":" c406cc110c5c8422440c8a6ca79838238ae8f5ea "}, {"Hardware":"PA155","FirmVer":"1.0.0","BldVer":"F13-1","RepoVer":" c406cc110c5c8422440c8a6ca79838238ae8f5ea "}, or {"Hardware":"PA199","FirmVer":"1.0.0","BldVer":"F13-1","RepoVer":" c406cc110c5c8422440c8a6ca79838238ae8f5ea "} The Crypto Officer is in charge of executing the Firmware Upload service when an update is released. The CO shall only upload firmware validated by the CMVP. If a tamper evident seal is damaged by accident, the CO shall replace the damaged seal following the instructions illustrated in Section 7.

There is no specific procedures for non-administrator operators.

There are no maintenance requirements or maintenance role.

To decommission the module, the CO shall execute the Reset/Zeroization service. This process will erase all SSPs contained within the cryptographic module. After that, the module shall be disposed of or distributed to other operators.

The module does not mitigate other attacks outside the scope of FIPS 140-3.