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.

ISO/IEC 24759 Section 6 FIPS 140-3 Section Title Security Level

Table 1: Security Levels Overall security level 2.

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

Figure 9: PA155-RM Figure 10: PA199-RM

The module operates in a limited operational environment. The module has been tested on the following operating environments: Tested Module Identification - Hardware: Model/Part Hardware Version Firmware Processor Features Number Version PA111-SA CDI 01-03-0912l 1.0.0 i.MX6 Ultralite (NXP, N/A IMX6, ARM32) PA111-RM CDI 01-03-0912l 1.0.0 i.MX6 Ultralite (NXP, N/A IMX6, ARM32) PA121-RM CDI 01-03-0912l 1.0.0 i.MX6 Ultralite (NXP, 3 expansion boards IMX6, ARM32) (20 serial host ports) PA155-RM CDI 01-03-0912l 1.0.0 i.MX6 Ultralite (NXP, 1 expansion board (4 IMX6, ARM32) serial host ports and

PA199-RM CDI 01-03-0912l 1.0.0 i.MX6 Ultralite (NXP, 2 expansion boards IMX6, ARM32) (8 serial host ports and 8 PCM ports) Table 2: Tested Module Identification - Hardware

There are no excluded components for this cryptographic module.

Modes List and Description: Name Description Type Status Indicator Approved mode The module only Approved SEC LED on supports the approved mode of operation 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 approved mode of operation. Degraded Mode Description 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. CAVP Algorithm and Mode/Method Description / Key Size(s) Use / Function Cert Standard / Key Strength(s) A3214 SHA-3 [FIPS 202] SHA3-256 Conditioning

CAVP Algorithm and Mode/Method Description / Key Size(s) Use / Function Cert Standard / Key Strength(s) function A4440 AES [SP 800-38A] ECB 128 and 256-bit keys Encrypt/Decrypt with 128 and 256-bit key strengths A4440 AES [SP 800-38D] GCM 128 and 256-bit keys Encrypt/Decrypt with 128 and 256-bit key strengths A4440 DRBG [SP 800-90A] HMAC DRBG SHA2-256 with 128-bit Deterministic key strength Random Bit Generation A4440 ECDSA [FIPS 186-4] KeyGen P-256 with 128-bit key Asymmetric Key strength Generation A4440 ECDSA [FIPS 186-4] KeyVer P-256 with 128-bit key Asymmetric Key strength Verification A4440 ECDSA [FIPS 186-4] SigGen P-256/SHA2-256 with Signature 128-bit key strength Generation A4440 ECDSA [FIPS 186-4] SigVer P-256/SHA2-256 with Signature 128-bit key strength Verification E100 ESV [SP 800-90B] CPU Jitter Source CDI CPU Time Jitter, 8-bit Non-Deterministic samples Random Bit Generation A4440 HMAC [FIPS 198-1] HMAC SHA-1 / 128

• 1024-bit Message keys with 112-bit key Authentication strength, SHA2-256 / 256
• 512-bit keys with 128-bit key strength, SHA2-384 / 256
• 512-bit keys with 192-bit key strength A4440 KAS [SP 800-56Arev3] KAS-ECC-SSC [SP P-256 with 128-bit key TLS key 800-56Arev3]/A4440 strength agreement TLS 1.3 KDF/A4440 A4440 KAS-ECC-SSC [SP 800- Ephemeral Unified P-256 with 128-bit key Shared Secret 56Arev3] strength Computation for Key Agreement A4440 SHS [FIPS 180-4] SHA-13, SHA2-256, Message Digest SHA2-384 A4440 TLS 1.3 KDF [RFC HMAC-SHA2-256, Key Derivation 8446] CVL HMAC-SHA2-384 Function No parts of these 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 Algorithm and Mode/Method Description / Key Size(s) Use / Function Cert Standard / Key Strength(s) protocols, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP. Table 4: Approved Algorithms No parts of the TLS 1.3 protocol, other than the approved cryptographic algorithms and the KDF, 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. Name Properties Implementation Reference CKG Cryptographic key generation per SP 800- IG.D.H 133rev2 and IG D.I - Generation of asymmetric keys for signature generation per [133] section 5.1. - Generation of asymmetric keys for key establishment per [133] section 5.2. - Symmetric key derivation for industry standard protocols from a key agreement shared secret per [133] section 6.2.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 encryption protocol. The module SNMPv3 protocol uses the HMAC-SHA2-256 and AES-CFB8 instead. Data transmits over the SNMP protocol only contains network metrics data that is nonsensitive and is considered plaintext. Name Caveat Use and Function AES-CFB8 Network metrics output over SNMPv3 protocol is obfuscated SNMPv3 privacy protocol and considered plaintext SNMP KDF Key localization function uses a SHA2-256 hash function not SNMPv3 key derivation

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.

Name Type Description Properties Algorithms KAS-ECC KAS Uses the KAS-ECC-SSC shared IG D.F scenario 2, KAS-ECC-SSC SP secret computation which is path (2), no key 800then fed into the module's TLS confirmation, key 56Ar3/A4440

TLS 1.3 protocol 2.4.B, resolution (7). KDF/A4440 P-256 curve providing

strength TLS-KTS KTS PSP transmitted as TLS payload SP 800-38D and SP AES-GCM/A4440 800-38F. KTS (key wrapping and unwrapping), per IG D.G., providing 128 bits of encryption strength 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.

Name Type Operating Sample Size Entropy per Conditioning Environment Sample Component CDI CPU Non-Physical Linux 4.14, 8 bits 1 SHA3-256 (A3214) Time Jitter i.MX6 Ultralite (NXP, IMX6, ARM32) 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: Protocol Key Exchange Server/Host Cipher Integrity Authentication TLSv1.3 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ECDH ECDSA AES-GCM SHS TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH ECDSA AES-GCM SHS 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.

Physical Port Logical Interface Data that passes over the port/interface LEDs

• Status Output Device Status Network
• Control Input CO traffic
• Control Output*
• Status Output
• Data Input User traffic
• Data Output Cellular Antennas
• Control Input CO traffic
• Control Output*
• Status Output
• Data Input User traffic
• Data Output Telco
• Control Input CO traffic
• Control Output*
• Status Output
• Data Input User traffic
• Data Output Host(s)
• Data Input User traffic from managed device
• Data Output User traffic to managed device PCM(s)
• Control Output User traffic to Power Control Module Console
• Control Input CO traffic
• Status Output Reset Switch
• Control Input Hardware reset signal Power(s)
• Power VAC and VDC USBs
• Data Input User traffic from managed device
• Data Output User traffic to managed device Table 10: Ports and Interfaces Note*: A module can be used to remotely administer another module. User Traffic Port Authority User Traffic associated with Control Output, Data Input and Data Output logical 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 𝑚𝑖𝑛𝑢𝑡𝑒

Credential 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 ). Name Description Mechanism Strength of Each Strength per Attempt Minute Certificate X509v3 for CO Signature 2128 8.8x10-17 and User roles Verification Credential ID and Password Identity-based 958 4.5x10-15 for CO and User authentication roles over analog

Credential ID and Password Identity-based 958 6.0x10-14 for CO and User authentication roles over cellular 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 roles: Name Type Operator Type Authentication Methods Crypto Officer Identity CO Credential, Certificate User Identity User Credential, Certificate Table 12: Roles Crypto Officer role 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 authentication. 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 authentication by the Crypto Officer.

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: Name Description Indicator Inputs Outputs Security Function Roles Roles SSP Implementation Access Login Operator login Function returns Login request, Login failure, login AES CO Access Token: without error Password, success and access ECDSA SigVer User E, R Operator token generated KAS-ECC Password: E, Z Certificate SHA2-256 Operator TLS KDF Certificate: E, Z CA Certificate: E AES-GCM Key: G, E TLS Pre-master Secret: G, E TLS Master Secret: G, E EC DiffieHellman Public Key: G, E, R EC DiffieHellman Private Key: G, E ECDSA Public Key: G, E, R

Name Description Indicator Inputs Outputs Security Function Roles Roles SSP Implementation Access ECDSA Private Key: G, E User Access Allow user Function returns Data to and from Plaintext traffic to CO Password: Z access to without error managed external and from managed User AES-GCM Key: E control device external device interfaces and managed elements Audit Log Download Function returns Request for Response CO AES-GCM Key: E event from without error module logs containing module the device logs Certificate Downloading Function returns Request to get a Response HMAC DRBG CO Certificate: W, Z Management CSR and without error device’s CSR, set containing a CSR or ECDSA KeyGen AES-GCM Key: E uploading devices’s the status of the set ECDSA KeyVer certificates certificate, or set action ECDSA SigGen and CA CA certificate ECDSA SigVer certificates Firmware Uploading Function returns Request to upload Response ECDSA SigVer CO Upload device without error and install new containing upload AES-GCM Key: E firmware to firmware or get or install process be installed install process status Module Configuration Function returns Request to get or Response CO Password: W, Z Management of the module without error set module containing AES-GCM Key: E parameters parameters or status of the set action On-demand Perform ALM LED blinks, Request to run ALM LED blinks ECDSA SigVer CO AES-GCM Key: E Integrity Test integrity self- function returns integrity self-test Response test without error containing integrity test status (test is running, test passed, or test

Name Description Indicator Inputs Outputs Security Function Roles Roles SSP Implementation Access failed) On-demand Perform self- ALM LED blinks, Request to run self- ALM LED blinks CO AES-GCM Key: E Self-test test function returns test besides Response without error integrity containing self-test status (test is running, test passed, or test failed) Reset Reset the SEC LED blinks, Request to reset SEC LED blinks CO All SSPs: Z device to function returns (begin boot factory without error sequence) default Device reset to factory default Show Status Return status Function returns Request for the SEC LED on CO AES-GCM Key: E of the module without error status of the Response module containing module status and peripheral hardware status Show Version Return version Function returns Request for the Response CO AES-GCM Key: E and name of without error module version containing the the module module version Zeroisation Zeroize all SEC LED blinks, Request for SEC LED blinks CO All SSPs: Z SSPs function returns zeroization or Device set to without error tamper switch factory default triggered Table 13: Approved Services

The cryptographic module supports the following non-approved services. Name Description Security Functions Role Network Metrics Transmit network Crypto Officer polling metrics data via non-approved SNMPv3 protocol 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.

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.

Physical security Recommended Inspection/Test Guidance Details Mechanism Frequency of Inspection/Test

Physical security Recommended Inspection/Test Guidance Details Mechanism Frequency of Inspection/Test Tamper Seal 12 months A pristine tamper evident seal appears smooth and uniform, firmly adhering to the surface of the device. By closely examining the seal, one can determine whether any tampering has occurred. Attempted removal of the seal may exhibit one or more of the following signs:

1. The silver adhesive layer displays separation or irregularities, forming a noticeable pattern. The printed text may become separated or misaligned from the silver adhesive layer.
2. Blistering, bubbling, or the presence of bumps on the seal's surface, causing it to lose its smooth and flat appearance. These surface irregularities may become apparent when tilting the seal in the light.
3. The edges of the seal show signs of lifting or failing to stay adhered. It can be easily lifted by gently sliding a pick or fingernail under its edge.
4. Residue of adhesive is detectable around the edges of the seal, indicating it has been removed and replaced. Tamper Switch The tamper switch will trip if an attempt is made to remove the top cover. The top cover for all units must be removed in order to access the chassis base and Printed Circuit Board(s).If the tamper switch is tripped, the SRAM containing the unit parameters, audit trail, keys and operator information will be zeroed. The zeroization circuit will activate regardless of if the SRAM is powered by the battery backup or powered by AC. 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 enclosure. The enclosure contains tamper seals that will be destroyed if an attempted is made to remove them. 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:
• middle of left side and right side (all models)
• middle of front seam (PA111-RM, PA121-RM, PA155-RM, and PA199-RM)
• middle of back seam (PA111-RM, PA121-RM, PA155-RM, and PA199-RM) 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

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.

Name Description Persistence Type SRAM Port Authority backup memory Volatile Flash Port Authority non-volatile memory Non-volatile RAM Port Authority working memory Volatile Table 16: Storage Areas

Name From To Format Type Distribution Entry SFI or Type Type Algorithm

Name From To Format Type Distribution Entry SFI or Type Type Algorithm TLS Payload-Out6 RAM Outside Encrypted Manual Electronic TLS-KTS the crypto boundary Factory Pre-load7 Manufacturer Flash Plaintext N/A N/A N/A KAS-In Outside the RAM Plaintext Automated Electronic KAS-SSC crypto boundary KAS-Out RAM Outside Plaintext Automated Electronic KAS-SSC the crypto boundary Load Cert Outside the SRAM Encrypted Manual Electronic TLS-KTS crypto boundary Operator Outside the RAM Encrypted Manual Electronic SHA2-256 Password Entry crypto boundary Operator Set Outside the SRAM Encrypted Manual Electronic SHA2-256 Password Entry8 crypto boundary Token-In Outside the RAM Encrypted Automated Electronic ECDSA crypto SigVer boundary Token-Out RAM Outside Encrypted Automated Electronic ECDSA the crypto SigGen boundary TLS Handshake-In Outside the RAM Plaintext Automated Electronic N/A crypto boundary TLS Handshake- RAM Outside Plaintext Automated Electronic N/A Out the crypto boundary TLS Payload-In Outside the RAM Encrypted Automated Electronic AES crypto boundary Table 17: SSP Input-Output Methods

Method Description Rationale Operator Initiation 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.

Capability Reset/Zeroization Zeroization of SSPs are zeroed when Yes service persistent SSPs the operator invokes the service Tamper response Zeroization of SSPs are zeroed when N/A persistent SSPs tamper switch is tripped Per connection Zeroization of Ephemeral SSPs related N/A ephemeral SSPs to TLS and SNMP protocols are zeroed when connection closed Table 18: SSP Zeroization

Name Description Size - Type Generated Established Used By Strength By By AES-GCM Key / Session key for 128 - 128, Symmetric key Derived TLSv1.3 TLS CSP TLS connection 256 - 128 from TLS KDF Master Secret TLS Pre- master Pre- master 384

• 128 Keying material N/A TLS TLS Secret / CSP secret for TLS handshake handshake connections TLS Master Master secret 384
• 128 Keying material Internally N/A TLS Secret / CSP for TLS derived by handshake connection TLSv3 KDF from TLS Pre-master Secret EC Diffie- Asymmetric key P-256 - Public key Internal ly N/A KAS-SSC Hellman Public used during EC 128 generated Key / PSP Diffie-Hellman per SP 80056Arev3 EC Diffie- Asymmetric key P-256
• Public key N/A N/A KAS-SSC Hellman Public used during EC 128 Key (operator) Diffie-Hellman / PSP EC Diffie- Asymmetric key P-256
• Private key Internally N/A KAS-SSC Hellman used during EC 128 generated Private Key / Diffie-Hellman per SP 800CSP 56Arev3 ECDSA Public Asymmetric key P-256
• Public key Internally N/A TLS Key / PSP used during TLS 128 generated handshake authentication per FIPS

Name Description Size - Type Generated Established Used By Strength By By 186-4 ECDSA Private Asymmetric key P-256

• Private key Internally N/A TLS Key / CSP used during TLS 128 generated handshake authentication per FIPS 186-4 ECDSA Public ECDSA Public P-256 - Public key External N/A TLS Key Certificate Key Certificate 128 handshake / PSP issued by a CA Server Self- ECDSA Public P-256 - Public key Internal N/A TLS signed Key Certificate 128 handshake Certificate / PSP ECDSA Public ECDSA Public P-256 - Public key External N/A TLS Key Certificate Key Certificate 128 handshake (operator) / issued by a CA PSP CA Certificate / CA public key P-256 - Public key External N/A mTLS PSP for certificate 128 validation DRBG V / CSP DRBG internal 256 - 128 DRBG secret Internal N/A DRBG state DRBG Key / DRBG internal 256 - 128 DRBG secret Internal N/A DRBG CSP state Entropy Input / Bit string for 440 - 128 Entropy bit Internal N/A DRBG CSP seed generation string DRBG Seed / Bit string to 440 - 128 DRBG secret Internal N/A DRBG CSP instantiate the DRBG Password / CSP Credential for Minimum Authentication N/A N/A SHA2-256 operator of 8 authentication characters (Salted SHA2-

Hashed Password hash 256 Authentication Internal N/A SHA2-256 Password / CSP Operator Client ECDSA P-256 - Public key External N/A TLS Certificate / public key 128 handshake / PSP certificate for Login mTLS Access Token / Time-limited P-256 - Signature Internal N/A ECDSA CSP access token 128 SigGen / ECDSA SigVer Table 19: SSP Table 1

Name Input - Output Storage Storage Zeroization Related SSPs Duration AES-GCM Key / N/A - N/A RAM Per connection Per connection, Derived from CSP tamper response, TLS Master Reset/Zeroization Secret service TLS Pre- master N/A - N/A RAM Per connection Per connection, EC DiffieSecret / CSP tamper response, Hellman Reset/Zeroization Private Key, service EC Diffie Hellman Public Key TLS Master N/A - N/A RAM Per connection Per connection, Derived from Secret / CSP tamper response, TLS PreReset/Zeroization master Secret service EC Diffie- N/A - KAS-Out RAM Per connection Per connection, EC DiffieHellman Public tamper response, Hellman Key / PSP Reset/Zeroization Private Key, EC service Diffie-Hellman, TLS Pre-master Secret EC Diffie- KAS-In - N/A RAM Per connection Per connection, TLS Pre-master Hellman Public tamper response, Secret Key (operator) Reset/Zeroization / PSP service EC Diffie- N/A - N/A RAM Per connection Per connection, EC DiffieHellman tamper response, Hellman Public Private Key / Reset/Zeroization Key, EC DiffieCSP service Hellman Public Key (operator), TLS Pre-master Secret ECDSA Public N/A - TLS SRAM Per connection Per connection, ECDSA Private Key / PSP Payload-Out tamper response, key Reset/Zeroization service ECDSA Private N/A - N/A SRAM Until replace Tamper response, ECDSA Public Key / CSP by new ECDSA Reset/Zeroization key Key Pair by CO service ECDSA Public Load Cert - SRAM - Until replace Tamper response, ECDSA Public Key Certificate TLS RAM by new ECDSA Reset/Zeroization Key, ECDSA / PSP Handshake- Key Pair by CO service Private Key Out - Per connection Server Self- N/A - TLS SRAM Until replace Tamper response, ECDSA Public signed Handshake- by new ECDSA Reset/Zeroization Key

Name Input - Output Storage Storage Zeroization Related SSPs Duration Certificate / Out Key Pair by CO service PSP ECDSA Public TLS RAM N/A Per connection, CA Certificate Key Certificate Handshake-In - tamper response, (operator) / N/A Reset/Zeroization PSP service CA Certificate / Load Cert - SRAM N/A Tamper response, Used to verify PSP N/A Reset/Zeroization the trusted service chain of certificate DRBG V / CSP N/A / N/A RAM Periodically Reboot DRBG Seed updated DRBG Key / CSP N/A / N/A RAM Periodically Reboot DRBG Seed updated Entropy Input N/A / N/A RAM DRBG reseed Automatic at end DRBG Seed of function call DRBG Seed / N/A / N/A RAM DRBG reseed Automatic at end Entropy Input CSP of function call Password / CSP TLS Payload-In SRAM Per connection Per connection, N/A - N/A tamper response, Reset/Zeroization service Hashed N/A

• N/A RAM Per connection Per connection, Password Password / CSP tamper response, Reset/Zeroization service Operator KAS-In - N/A RAM Per connection Per connection, N/A Certificate / tamper response, PSP Reset/Zeroization service Access Token / Token-In - RAM Per connection Per connection, ECDSA Public CSP Token-Out tamper response, Key - ECDSA Reset/Zeroization Private Key service Table 20: SSP Table 2

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. Algorithm Test Test Method Type Indicator Details or Test Properties ECDSA P-256 Signature Software SEC LED blinking Signature Verification Verification Integrity 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: Algorithm Test Properties Test Type Indicator Details Condition or Test Method AES-ECB 128, 256 KAT CAST LED signal Encrypt / Decrypt Run during power-up AES-GCM 128, 256 KAT CAST LED signal Encrypt / Decrypt Run during power-up HMAC SHA2-256, KAT CAST LED signal Message Run during SHA2-384 Authentication power-up Code SHS SHA2-256, KAT CAST LED signal Message Digest Run during SHA2-384 power-up SHS SHA3-256 KAT CAST LED signal ENT conditioner Run during power-up ECDSA P-256 KAT CAST LED signal Sign / Verify Run during power-up KAS-ECC- P-256 KAT CAST LED signal Shared Secret Run during SSC Computation power-up TLSv1.3 KAT CAST LED signal Key Derivation Run during KDF power-up DRBG HMAC_DRBG, KAT CAST LED signal Random Bit Run during Instantiate, Generation power-up Reseed and Generate ECDSA P-256 PCT CPCT LED signal Sign / Verify Key Pair Generation KAS-ECC- P-256 PCT CPCT LED signal SP 800-56Arev3 Shared Secret SSC assurance checks Computation ECDSA P-256 Signature CFLT LED signal Digital Signature Software Verification update signature verification ENT APT, RCT and CCFT LED signal SP 800-90B Health Run during Lag health tests tests for Entropy power-up (on Sources 1,024 samples) and runtime health tests 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.

State Name Description Conditions Recovery Method Indicator Error Any pre- Initialization Reboot or hard ALM LED on operational self- error, self-test reset test, error or general cryptographic error from any algorithms self- state lead to the tests, or critical Error state function test failure 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 reboot or hard reset, and the module will execute all the pre-operational self-tests again.

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.

AES Advance Encryption System ASCII American Standard Code for Information Interchange CA Certificate Authority CAST Cryptographic Algorithm Self-test CAVP Cryptographic Algorithm Validation Program

CCFT Conditional Critical Function Test CDI Communication Devices, Inc. CFLT Conditional Firmware Load Test CMVP Cryptographic Module Validation Program CPCT Conditional Pair-Wise Consistency Test CO Crypto Officer CSR Certificate Signing Request DH Diffie-Hellman DRAM Dynamic Random Access Memory EC Elliptical Curve EIA/RS232 Modem/Host Serial Interface EIA/RS232 Signals DCD Data Carrier Detect DTR Data Terminal Ready RTS Request to Send CTS Clear to Send GND Signal Return (Ground) Data Set Ready TxD Transmit Data RxD Received Data Flash Flash Solid State Memory HMAC Hash-based Message Authentication Code KAT Known Answer Test Kbps Kilo Bauds per Second Mbps Mega Bits per second MAC Message Authentication Code NIST National Institute of Standards and Technology OBM Out of Band Management PA Port Authority PCM Power Control Module RM Rack Mounted RNG Random Number Generator SRAM Static Random Access Memory SA Stand Alone VAC Voltage Alternating Current VDC Voltage Direct Current