Marvell LS2 HSM Family

Certificate

Vendor resources (verify with the vendor)

Approved Algorithms (67)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Marvell LS2 HSM Family
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C1["[high] Firmware / bootloader<br/>versions disclosed<br/>(identity, not provenance)<br/><i>MARVELL-LS2-FW-*, MARVELL-LS2-UBOOT-*</i>"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>CN_LOAD_RECOVERY_KEY_INIT CN_LOAD_RECOVERY_KEY_FI…<br/>CN_FW_UPDATE_BEGIN, CN_FW_UPDATE, CN_FW_UPDATE_END<br/>CN_UPDATE_LICENSE</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>CN_ZEROIZE<br/>CN_APP_INITIALIZE<br/>CN_APP_FINALIZE</i>"]
    C4["[high] Physical/logical<br/>interfaces (some 'blocked<br/>in firmware')<br/><i>USB FTDI USB to Multi-Channel Serial SPI/I2C…<br/>PCIe<br/>PCIe SMBus</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>HTTPS<br/>library named: openssl</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>arm trusted firmware</i>"]
  end
  subgraph Inference["Derived inference"]
    I1["Component identity is<br/>disclosed, but provenance<br/>and patch lineage are not."]
    I2["Trusted code is reachable<br/>through update and<br/>recovery paths."]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    I4["Interface reachability may<br/>vary by boot stage and<br/>lifecycle state."]
    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"]
    R1["Do the vendor version<br/>strings obscure the<br/>upstream baseline, fork<br/>lineage, or known-CVE<br/>exposure?"]
    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?"]
    R4["Are interfaces blocked<br/>before the bootloader<br/>runs, or only after<br/>approved mode starts?"]
    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"]
    E1["SBOM / component baselines<br/>· patch and backport<br/>manifest · CVE disposition"]
    E2["update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E4["lifecycle reachability<br/>matrix · boot-stage<br/>interface timing ·<br/>factory/recovery/error-state<br/>access controls"]
    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
  C1 --> I1 --> R1 --> E1
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C4 --> I4 --> R4 --> E4
  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 C1,C2,C3,C4,C5,C6 clue;
  class I1,I2,I3,I4,I5,I6 infer;
  class R1,R2,R3,R4,R5,R6 risk;
  class E1,E2,E3,E4,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Marvell LS2 HSM Family
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C1["[high] Firmware / bootloader versions disclosed (identity, not provenance)<br/><i>MARVELL-LS2-FW-*, MARVELL-LS2-UBOOT-*</i><br/>src: certificate.firmwareVersions"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>CN_LOAD_RECOVERY_KEY_INIT CN_LOAD_RECOVERY_KEY_FI…<br/>CN_FW_UPDATE_BEGIN, CN_FW_UPDATE, CN_FW_UPDATE_END<br/>CN_UPDATE_LICENSE</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>CN_ZEROIZE<br/>CN_APP_INITIALIZE<br/>CN_APP_FINALIZE</i><br/>src: securityPolicy.services"]
    C4["[high] Physical/logical interfaces (some 'blocked in firmware')<br/><i>USB FTDI USB to Multi-Channel Serial SPI/I2C…<br/>PCIe<br/>PCIe SMBus</i><br/>src: securityPolicy.portsAndInterfaces"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>HTTPS<br/>library named: openssl</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>arm trusted firmware</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 C1,C2,C3,C4 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

Marvell LS2 HSM Family January 29, 2026

Revision History 1.0 1.0.1 1.0.2 1.0.3 1.0.4 Notice This document may be reproduced only in its entirety (without revision).

1.1 Module Overview The LS2 HSM Family module (hereafter referred to as the module or HSM) by Marvell is a high-performance purpose-built security solution for key management and crypto acceleration. The module provides a FIPS 140-3 overall Level 3 security solution. The module is deployed in a PCIe slot to provide crypto and protocol acceleration in a secure manner to the system host. It is typically deployed in a server or an appliance to provide crypto offload for the keys stored on the HSM. The module’s functions are accessed over the PCIe interface via opcode defined by the module. The HSM is a hardware multi-chip embedded cryptographic module with firmware programmed on the HSM. The module provides cryptographic primitives to accelerate approved, allowed and non-approved, allowed (only in non-approved mode of operation) algorithms to support use cases including PKI, code signing, document signing, Root Of Trust, and TLS. The cryptographic functionality includes asymmetric (RSA/EC) and symmetric (AES and Triple-DES) ciphers, signatures, and random number generation, along with protocol-specific complex instructions to support TLS 1.2. The module implements password-based singlefactor authentication at FIPS 140-3 Level 3 security and an optional public-key-based authentication. The physical boundary of the module is the outer perimeter of the PCIe card itself as depicted in section 2.5 . 1.2 The cryptographic module meets the overall requirements applicable to Level 3 security of FIPS 140-3. Table 1 Security Levels [Number Below] N/A N/A N/A

Cryptographic Module Specification The configuration of hardware and firmware for this validation is as described in the following table: Table 2 Cryptographic Module Tested Configuration

Bootloader: MARVELL-LS2-UBOOT-10.23-1107 -R02-SB FW: MARVELL-LS2-FW-10.23-1107 Bootloader: MARVELL-LS2-UBOOT-10.01-10 Bootloader: MARVELL-LS2-UBOOT-10.02-1200 Bootloader: MARVELL-LS2-UBOOT-10.23-1107 -R01-SB Bootloader: MARVELL-LS2-UBOOT-10.23-1107 -R01-SB HPS APP: PIN-App:10.23-1107 The part number printed on the product label will have additional information to optionally identify a manufacturing process such as key ceremony, packaging, and shipping per customer requirements. For example, the part number shown on the product label is in the format “LS2-G-A300-XX-Y-B0”. Here XX represents the key ceremony process and “Y” represents the size of the bracket (short or full) fitted to the module (PCIe adapter). LS2-HSM-G Firmware MARVELL-LS2-FW-10.02-1102 MARVELL-LS2-UBOOT-10.01-10 MARVELL-LS2-UBOOT-10.02-1200 MARVELL-LS2-FW-10.23-1107 MARVELL-LS2-UBOOT-10.23-1107 -R01-SB MARVELL-LS2-UBOOT-10.23-1107 -R02-SB PIN-App:10.23-1107 MARVELL-LS2-FW-10.23-1150 MARVELL-LS2-UBOOT-10.01-10 MARVELL-LS2-UBOOT-10.02-1200-SB MARVELL-LS2-UBOOT-10.23-1107 -R01-SB MARVELL-LS2-UBOOT-10.23-1107 -R02-SB PIN-App:10.23-1107 MARVELL-LS2-FW-10.23-1202 MARVELL-LS2-UBOOT-10.23-1107 -R01-SB MARVELL-LS2-UBOOT-10.23-1107 -R02-SB PIN-App:10.23-1107 Note: These binaries do not have extensions. The LS2 HSM module is a multi-chip PCIe adapter with firmware. It consists of multiple components, including an operating system, applications exposing services and interfaces related to secure key management, crypto operations, and policy management of the module. Important hardware components of the module are: general purpose, ARM-based control processor, ARM-based microcontroller, RAM memory, NOR and eMMC flash for persistent storage, USB interfaces, and RJ45 and PCIe gen-4 x8 with SMBus interfaces. The following components are excluded from the cryptographic boundary as they do not belong to either data/control interface.

• Top side: o
• RJ45 connector (J901): This is blocked in firmware. Bottom side:
• None

2.1 Partitions The LS2 HSM adapter is an SR-IOV enabled intelligent PCIe adapter with one physical function and 64 virtual functions. The physical device is referred to as Physical Function (PF) while the virtual devices are referred to as Virtual Functions (VF). Allocation of the VF can be dynamically controlled by the PF via registers encapsulated in the capability. Each VF's PCI configuration space can be accessed by its own Bus, Device and Function Number (Routing ID). And each VF also has PCI Memory Space, which is used to map its register set. VF device driver operates on the register set so it can be functional and appear as a real existing PCI device. In addition to crypto offloads, this adapter can provide secure key storage with up to 64 logical partitions, including a master partition. Each partition will have dedicated resources that are logically and securely isolated from other partitions. A partition will have its own specific policies and controls, and its own user accounts to manage what can be done with a partition and by a user of a partition. Consequently, each partition is treated as a virtual HSM and referred as a pHSM (or HSM Partition). An LS2 HSM always has one default partition called the master partition, which exposes the interfaces to create, delete, and update the remaining partitions. LS2 HSM can either be in host virtualization mode or non-virtualization mode. One or more applications on a host/virtual machine/container can make use of different partitions available on the HSM. Each partition will have dedicated communication channels; these channels are linked to the PCIe devices. In virtualization mode, channels will be linked to PCIe VFs, otherwise linked to PCIe PF. Communication channels have basic checks to identify that an application is communicating with an intended partition on the HSM. HSM FW provides the following mechanisms to ensure only an authorized user or application of a specific partition can communicate with it. It is optional to use either mechanism based on the deployment scenarios and risk assessment.

These channels depend on the Host OS security for device binding and application isolation. In this case, HSM does basic session validation.

• To run any authorized operation on an HSM partition, a user needs to login, get a random session handle, and use the session handle in all future communications to bind the authorization information. Security critical operations (user management, key management, backup/restore, etc.) are all protected by encryption using keys that are (optionally derived from) set up during key ceremony.

The end-to-end encryption feature in the module allows an application to initiate a TLS connection with the firmware to ensure the confidentiality of the data communicated to the HSM. The connection is based on TLS v1.2 with the cipher-suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(known to OpenSSL as ECDHE_RSA_AES128-GCM-SHA256 and ECDHE_RSA_AES256-GCM-SHA384). The module will act as server, and the host application will act as client. The server private key will be the partition private key (PAK), which is generated for each pHSM when it is created. The server certificate used for the SSL connection is the partition certificate (PAC). The complete chain will be validated by host applications before establishing the TLS connection. The end-to-end encryption feature is enabled using the initialization configuration parameters. Once this feature is enabled, all commands except initialize and open session are encrypted.

This is the default partition with only one user, called the Master Crypto Officer (MCO). This partition will expose authorized services to manage (create, delete, update, backup/restore) other partitions and set policies or conditions for them to operate. Additionally, it exposes anonymous services like fetching module information, etc. Refer to section 4.3 Roles, Services, and CSP Access for details about the services supported by the master partition. The master partition must be initialized and the MCO logged in to execute any authorized service.

Each partition will have a different set of users to manage it and a dedicated key storage and crypto resources associated with it. A partition will have default configuration or policies supplied by the master partition. Some policies can be changed by the partition

administrator or PCO. When a partition is created by the MCO, it will be in a zeroized state and must be initialized to do any key management or crypto operations. Partition initialization will create the Partition Crypto Officer (PCO). The PCO can later create up to

1024 users (PCO or PCU) on demand. Each user will have a unique username to identify themselves. The user has to log in to the

partition/vHSM to issue any authorized commands. Users are authenticated using passwords submitted during the user creation. 2.2 Modes of Operation The module supports the following modes of operation:

1. Uninitialized/zeroized mode.
2. Non-approved mode of operation.
3. Approved mode of operation. The module is initialized into one of the modes specified above during the module initialization period as mentioned in Section
4. The value of the parameter fipsState passed into the call specifies the mode. The following values are allowed for the fipsState parameter:

The indicator of Approved mode is obtained by using the Get Status service. The fipsState field of the Get Status service indicates the mode. CSPs are not shared between the approved and non-approved modes of operation.

When received by the end user, the module is not configured or initialized; this state is called uninitialized/zeroized mode. In this mode, the user can query for basic information about the module, such as version details and vendor information, using an unauthenticated role.

The module provides an Approved mode of operation, comprising all services described in Table 10. In this mode, the module allows only Approved or allowed algorithms. Request for any non-approved/allowed algorithm is rejected.

The module supports a non-Approved mode implementing the non-Approved algorithms listed in Table 6. In this mode, the module also allows Approved or allowed algorithms. 2.3 Supported Cryptographic Algorithms This section provides the list of supported cryptographic algorithms segregated based on the operating mode.

The cryptographic module supports the following Approved algorithms. There are algorithms, modes, and key/moduli sizes that have been CAVP-tested but are not used by any approved service of the module. Only the algorithms, modes/methods, and key lengths/curves/moduli used by the module in approved mode are listed in the following table. Note: All symmetric key sizes represent the key strength. Table 3 Approved Algorithms 4)

N/A

• AES-GCM (#A1947) o o
• TLS 1.2 or other applications can offload GCM operations.
• For TLS-1.2 protocol, IV constructed as described in RFC 5288.
• Refer Section 2.4 for the TLS 1.2 AES GCM supported cipher suites
• IV is generated internally to the cryptographic module.
• The module triggers a handshake to establish new encryption keys and IVs when the IV exhausts the maximum possible values for the given session key.
• SP 800-38D §8.2.2 is used for GCM IV construction.
• IVs are generated randomly and IG C.H Option #2 applies.
• IV’s free field is a 4-byte counter
• IV’s random field is a 96-bit random number.

• IV’s random field is incremented by 1. IV’s random field wouldn’t overflow 96-bits in the lifetime of the module.
• For IV restoration conditions guidance, refer to section 11.5 User Guidance.
• Internal Approved RBG (Hash DRBG #A1947): SP 800-90A DRBG, HASH_DRBG SHA2-512. o
• IVs are generated randomly, and IG C.H Option #2 applies.
• IV is generated internally to the cryptographic module.
• SP 800-38D §8.2.2 is used for GCM IV construction.
• IV’s random field is a 128-bit random number.
• For IV restoration conditions guidance, refer to section 11.5 User Guidance.
• Approved RBG (Hash DRBG #A1947): SP 800-90Ar1 DRBG, HASH_DRBG SHA2-512 CKG SP 800-133Rev2 (Vendor affirmed) o
• IG C.H Notes:
• SP 800-133Rev2 Section 5.1 Asymmetric signature key generation using unmodified DRBG output
• SP 800-133Rev2 Section 5.2 Asymmetric key establishment key generation using unmodified DRBG output
• SP 800-133Rev2 Section 6.1 Direct symmetric key generation using unmodified DRBG output
• SP 800-133Rev2 Section 6.2.1 Derivation of symmetric keys from a key-agreement shared secret.
• SP 800-133Rev2 Section 6.2.2 Derivation of symmetric keys from a pre-shared key PBKDF (SP 800-132) (#A1948) o
• PBKDF with HMAC password strength
• The password is a minimum of 8 characters, case-sensitive alpha-numeric. As such there are (26*2+10)^8 = 62^8 possible minimum-length passwords, and the false acceptance rate is 1 in 62^8 which is less than 1 in 1,000,000.
• A maximum of 20 password attempts are possible before permanent lockout. Therefore the probability of false authentication over any timeframe is 20 in 62^8, which is less than 1 in 100,000. (The number of allowed login attempts prior to lockout is configured during module initialization but cannot exceed 20.)
• Lockout of MCO automatically zeroizes the module in the next reboot. In all other cases, lockout can be unset by destroying the partition. PBKDF with HMAC Iteration Count and Justification
• Iteration count should be at least 1000, following the recommendation in SP800-132r2.
• Salt length is 128 to 4096 bits.

The cryptographic module supports the following non-Approved algorithms, which are allowed for use in Approved mode. Table 4 Non-Approved Algorithms Allowed in the Approved Mode of Operation

• This functionality of the module is used by the user of the module as part of TLS protocol negotiation. The TLS protocol has not been reviewed or tested by the CAVP or CMVP. The cryptographic module supports the following non-Approved algorithms; they are allowed in the Approved mode of operation with

The cryptographic module supports the following non-Approved algorithms available only in non-Approved mode of operation. Table 6 Non-Approved Algorithms Not Allowed in the Approved Mode of Operation

2.4 TLS 1.2 Cipher Suites The module supports the algorithms for the following cipher suites using Approved and allowed algorithms and key sizes:

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 For cipher suites using GCM, the IV is generated per RFC 5288. The module supports GCM cipher suites compatible with SP 80052 Rev2. 2.5 Module Photograph The following images depict the module’s physical and logical cryptographic boundary. RJ45 Connector Figure 1 Top View of Cryptographic Module

Figure 2 Bottom View of Cryptographic Module

The module ports and interfaces are described in the below table. Table 7 Ports and Interfaces N/A * The RJ45 Connector depicted in Figure 1 is disabled in firmware. 3.1 self-tests are run and firmware is loaded. After the module is zeroized, the firmware enforces that the PCIe data interface only provides basic versioning and informational When the module enters the error state, the PCIe data interface will report the error state and no other data. 3.2 Other interfaces are all meant for informational services to read temperature, logs, and diagnostic information but no other data.

Roles, Services, and Authentication The module supports different operator roles. One identity is allowed for each role, per partition. Username is used as the identity of a user. This means for a given partition, each username needs to be unique per predefined roles. Master Partition Roles: • Master Crypto Officer (MCO) - The Master Crypto Officer role (MCO) is allowed only on the master partition, which is mandatory to use the HSM. This role has access to administrative services offered by the module or HSM. This role is used to configure non-master partitions (create, provision, resize, and delete) but cannot access their resources (e.g., cannot manage or use non-master partition keys). Master partition supports only MCO role in addition to UN-AUTH operator roles as described in Table

8. Non-Master Partition Roles: • Pre-Crypto Officer (Pre-CO) - This role is an optional role with limited functionality; eventually transitions into PCO. During partition initialization, default credentials are used to create a Pre-CO or a PCO. The Pre-CO is a restricted role primarily for configuring certificates and setting up a PCO. After a PCO is set up for a partition, the Pre-CO role is no longer accessible. • Partition Crypto Officer (PCO) - This role has access to administrative services of the partition and can configure PCU and AU identities. The HSM supports more than one Crypto Officer role with a requirement there shall be at least one. • Partition Crypto User (PCU) - This role has access to all cryptographic services offered by the partition; its purpose is operational use of the module. • Appliance User (AU) - This role has access to partition audit logs and can create end-to-end encrypted channels. It is used to set up and synchronize clusters. Each non-master partition supports these four (4) distinct operator roles (Pre-CO, PCO, PCU, and AU) in addition to UN-AUTH as described in Table
9. The module enforces the separation of roles using identity-based authentication. Re-authentication is required to change roles. Except for Pre-CO, concurrent operators are allowed; however, only one operator is allowed per login session. 4.1 Roles, Services, and CSP Access Service interface documentation details specific service inputs and outputs: Document name: LiquidSecurity2-10.23-1150-Driver-APIs.zip Version: 10.23-1150 Release date: 09/26/2025 To access the document, complete the below steps.
10. Open the following link to open the Marvell Public Driver Downloads page: https://www.marvell.com/support/downloads.html
11. Choose CATEGORY, PLATFORM, and PART NUMBER as shown in the following screenshot; then click the APPLY button.

Select “LiquidSecurity2-10.23-1150-Driver-APIs-html" to download. 3. This pops up a window to accept the “MARVELL LIMITED USE LICENSE AGREEMENT”.

Click I ACCEPT to accept the terms and conditions; the Service Interface document will be downloaded.

4. After the Interface document is downloaded, extract the archive with the password “LS-FIPS-140-3”.
5. To access the Services, open the index.html file; then select LiquidSecurity Opcodes > Recommended API(s) from the left-pane. The following interface displays. The module's primary service inputs are opcodes. An API is provided to the operator on the host system to invoke these opcodes.

The host API is called, which packetizes services and calls the PCIe host driver to send the request from the host to the HSM. The HSM processes the service requests and passes the response from HSM to the host through PCIe host Driver and API. NOTE: The new API documentation 10.23-1150 also covers the API documentation version 10.02-1102, 10.23-1107 and 10.231202. Table 8 Roles, Service Commands, Input and Output

* Please refer to the API documentation for specific Opcode inputs and Opcode outputs. * The below generic services represent a set of related services:

• CN_BACKUP includes the opcodes CN_BACKUP_BEGIN, CN_BACKUP_CONFIG, CN_BACKUP_END,
• CN_RESTORE includes the opcodes CN_RESTORE_BEGIN, CN_ RESTORE_CONFIG, CN_ RESTORE_END, CN_
• CN_INSERT_MASKED_OBJECT includes the opcode the CN_INSERT_MASKED_OBJECT_USER.
• CN_CERT_AUTH_STORE_CERT includes the opcode the CN_CERT_AUTH_STORE_CERT_CHAIN .
• CN_UPDATE_LICENSE, CN_GET_LICENSE_INFO, CN_GET_DIAGLOG, and CN_NOR_HUK_OP services are only applicable for MARVELL-LS2-FW-10.23-1107. Table 9 Roles and Authentication In the table below, “UN-AUTH” refers to all users defined in section 4.2 Assumption of Roles
• Non-Master Partition Roles other than Table 10 Approved Services

(SP 80090Ar1) E R Z Z Z (SP 80090Ar1) Z (SP 80090Ar1) R E G, E G, E

E E (SP 800AOTAC, r E E E E W W E T KAS-ECCSSC SP80056Ar3 E E W E E

G E E (SP 80090Ar1) HKDF (SP80056Br2) W W E E E E E

W E E G E E E G (SP 80090Ar1) Z G, E R HMAC-SHA2256 (FIPS 198PEK R R R E W, E W

E E R (SP 80090Ar1) E E TLS premaster G, E KAS-ECCSSC SP80056Ar3 G, E G E G (SP 80090Ar1) E

E E W G,E G, E G, E HKDF (SP80056Br2) (SP 80090Ar1) T R R R

G 2.4.A 2.4.A E (SP 80090Ar1) R W E KAS-ECCSSC SP80056Ar3

(SP 80056Br2) 2.4.A 2.4.A (SP 80056Ar3) (SP 80056Br2) (KTS) (SP80038D)

(SP 80056Ar3) D.G D.G R E KAS-ECCSSC SP80056Ar3 (SP 80056Br2) (SP 80056Br2) (KTS) (SP80038D)

E G, E (SP 80056Ar3) (SP 80056Ar3) P/ (SP 80056Ar3) (SP 80056Ar3)

E (SP 80090Ar1) E E E E KAS-ECCSSC SP80056Ar3

E E (SP 80090Ar1) E E (SP 80090Ar1) E

(SP 80090Ar1) E (SP 80090Ar1) E E E E E E E R E (SP 80090Ar1) G E E HKDF (SP80056Br2) E G (SP 80090Ar1) G E

E G G G R HKDF (SP800Key E (SP 80090Ar1) G E E E G G G W

W R R (SP 800FMAK E R E E R E R MCO/UNAUTH MCO/UNAUTH Z

Indicator for Approved services: The indicator is success for all Approved services when the partition is operated in the approved mode. The following codes are used G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module (e.g., the SSP is output). W = Write: The SSP is updated, imported, or written to the module. E = Execute: The module uses the SSP in performing a cryptographic operation. Z = Zeroize: The module zeroizes the SSP. Approved services that also support the use of non-approved security functions are enumerated in the Non-Approved Services table below with their supported non-approved security functions. Table 11 Non-Approved Services 2.4.A

The indicator is success for all non-approved services only when the partition is operated in the non-approved mode. The nonapproved services will fail FIPS POLICY MISMATCH when partition is operated in the approved mode.

Firmware Security Firmware integrity is verified by the bootloader during the boot up using EDC (CRC32) for itself and using RSA 2048 signatures and SHA-256 for next level image. The integrity test can be run on-demand by resetting the module by power-cycling it or by PCIe function reset. As part of firmware load operation, the new firmware’s integrity and authenticity is verified by the active firmware using RSA 2048 signatures and SHA-256. Operational Environment The module implements a limited operational environment running SMP Linux operating system on 64-bit Armv8.2-based control processor. FIPS 140-3 Area 6 Operational Environment requirements do not apply to the module in this validation. Any firmware loaded into this module that is not shown on the module certificate is out of the scope of this validation and requires a separate FIPS 140-3 validation. The module is a hardware module with a limited operational environment and Physical Security Level 3. 7.1 The module’s cryptographic boundary is defined to be the outer perimeter of the hard epoxy enclosure containing the hardware and firmware components. The module is opaque and completely conceals the internal components of the cryptographic module. The epoxy enclosure of the module prevents physical access to any of the internal components without having to destroy the module. There are no operator required actions. Note: The module’s hardness testing was only performed at ambient temperature (23°C); no assurance is provided for Level 3 hardness conformance at any other temperature. 7.2 Tamper Evidence The module is coated in hard epoxy, such that any physical breach attempt leaves behind evidence of tamper. This is shown in the figure below. Figure 3 Cryptographic Module Showing Tamper Evidence While the module is designed to prevent successful tampering (any physical breach to module circuitry is likely to destroy the module, as per FIPS 140-3 Level 3 Physical Security requirements), the module should still be checked periodically for attempts. Guidelines are provided in the table below. Table 12 Physical Security Inspection Guidelines

If the module is found to be meaningfully damaged or tampered with (e.g., circuitry is showing or other significant damage has occurred), it should be removed from use and destroyed. Table 14 Hardness Testing Temperature Ranges Non-Invasive Security N/A due to the module not claiming to implement any non-invasive security protection mechanisms. Sensitive Security Parameter Management 9.1 Definition of Critical Security Parameters (CSPs) The Manufacturer FIPS Data Encryption Key (MFDEK) and HSM Master Partition Master Encryption Key are stored in plaintext form in eMMC Flash. The Partition Master Encryption Key (PMEK) is stored encrypted under the HSM Master Partition Master Encryption Key. All other keys and CSPs stored in the persistent memory are encrypted by the MFDEK, HSM Master Partition Master Encryption Key, or PMEK. All general purpose user CSPs are generated/created by the PCU, and these CSPs can be shared between multiple PCUs. In Table 15, the following notations are used to indicate the type of zeroization: D = Manually zeroized (via CN_DESTROY_OBJECT service) E = Zeroized right after use (Memory is wiped with zeros, immediately after use) MFZ = Zeroize all Partitions’ SSPs, including the HSM adapter owner programmed ones (Brings HSM to factory state. Factory reset via CN_ZEROIZE service with factory-reset as argument with MCO credentials) MZ = Zeroize all Partitions’ SSPs, except vendor programmed ones (Master Partition Regular CN_ZEROIZE) PD = Zeroize all SSPs in the Partition and then delete the User Partition (via CN_DELETE_PARTITION service) PFZ = Zeroize all SSPs in the Partition (Factory reset via CN_ZEROIZE service with factory-reset as argument with PCO credentials)

= Zeroize all User SSPs in the Partition Regular p (Equivalent to User Partition Regular zeroize via CN_ZEROIZE service) S = Zeroized on session close (Session Close via CN_CLOSE_SESSION, CN_APP_FINALIZE and CN_CLOSE_PARTITION_SESSIONS) = Vendor zeroize (Zeroizes all SSPs including vendor programmed configuration and CSPs. Makes the module unusable; the module must be sent back to the vendor for re-programming.) via CN_VENDOR_ZEROIZE service. * The SSPs are zeroized securely by writing zeros to memory. * Private/Secret keys are always encrypted when doing export/import, and key encapsulation mechanisms are listed in the respective CSP row. * All CSPs from Table 15 and Table 16 are entered through automated electronic entry mechanisms. Table 15 SSPs EstablishStorage Zeroization N/A N/A N/A N/A N/A N/A

EstablishStorage Zeroization DS E E KAS-ECCSSC SP80056Ar3 (SP 80056Br2) E E

EstablishStorage Zeroization DS Table 16 Non-Deterministic Random Number Generation Specification

9.2 Definition of Session Keys The cryptographic module supports the generation/import/export of user keys that are bound to a session and are termed as session keys. The following points apply to session keys:

• Session keys are stored in RAM and are lost across reboots.
• Session key access is restricted to the application in which it is created.
• PCU can share the session keys with other users so that other sessions can use it.
• Every session in an application will have access to the keys created by every other session in the same application.
• When a session is closed, the session keys created by that session are destroyed.
• If a session key is shared, then it will be deleted only after closing all the sessions sharing the key.

This section documents the security rules enforced by the cryptographic module to implement the self-test requirements of this FIPS 140-3 Level-3 module. The module always executes the self-tests without operator intervention regardless of approved or non-approved mode or any other configuration. Failure of any of the self-tests causes the module to go into an error state. If the failure happens during periodic execution of Cryptographic Algorithm Self-Tests (CASTs), then module will reject all future commands received. The module need to be reset to recover from the situation. Data output except for status log messages is inhibited during self-tests, zeroization, and error states. Status information does not contain CSPs or sensitive data. The conditional cryptographic algorithm self-tests (CASTs) run periodically. The periodicity is configurable by the MCO and by default runs every 24 hours. The execution of CASTs causes a momentary (less than a second) service interruption. The voltage monitoring happens continuously by the module which samples the voltage rails for every 400 micro-seconds. The temperature monitoring happens continuously by the module for every 30 seconds. Module performs the pre-operational Firmware integrity tests (#A1946) RSA 2048-bit SHA-256 signature verification every 24 hours. The cryptographic module performs the pre-operational and conditional self-tests:

• Pre-operational software/firmware integrity test
• CRC-32 integrity test
• Firmware integrity tests (#A1946) RSA 2048-bit SHA-256 signature verification. Pre-operational bypass test (7.10.2.3)
• None Pre-operational critical functions tests: The module runs the following critical functions tests, which are required to ensure the correct functioning of the device.
• Temperature monitor test
• Voltage monitor test Conditional self-tests
• Conditional cryptographic algorithm test: The operator is capable of commanding the module to perform the powerup self-test by cycling power or resetting the module. Power-up self-tests do not require any operator action.
• CPT Library:
• AES-CBC (SP 800-38A) Decrypt KAT (#A1947, 128-bit key)
• AES-CBC (SP 800-38A) Encrypt KAT (#A1947, 128-bit key)
• AES-CCM (SP 800-38C) Decrypt KAT (#A1947, AES 128-bit key)
• AES-CCM (SP 800-38C) Encrypt KAT (#A1947, AES 128-bit key)

• o AES-CMAC (SP 800-38B) Sign KAT (#A1947, 128-bit key)
• AES-CMAC (SP 800-38B) Verify KAT (#A1947, 128-bit key)
• AES-GCM (SP 800-38D) Decrypt KAT (#A1947, 128-bit key)
• AES-GCM (SP 800-38D) Encrypt KAT (#A1947, 128-bit key)
• ECDSA SigGen (FIPS186-4) (CVL) KAT (#A1947, P-256 using SHA-1, SHA-256, SHA-384, SHA-512)
• Hash DRBG (SP 800-90Ar1) (instantiate, generate, reseed) KAT (#A1947, SHA512)
• KAS-ECC-SSC SP800-56Ar3 KAT (#A1947, P-256)
• *KDF SP800-108 CMAC in Counter mode KAT (#A1947, AES 128-bit key)
• *KDF SP800-108 HMAC in Counter mode KAT (#A1947, HMAC-SHA-256)
• KDF TLS (CVL) (SP 800-135r1) TLSv1.2 KDF KAT (#A1947, HMAC-SHA-256)
• RSA (SP 800-56Br2) Encrypt KAT (2048-bit)
• RSA Decryption Primitive (SP 800-56Br2) (CVL) KAT (#A1947, 2048-bit)
• RSA Signature Primitive (CVL) (FIPS 186-4) KAT (#A1947, 2048-bit)
• TDES-CBC (SP 800-38A) Decrypt KAT (#A1947, Triple-DES)
• TDES-CBC (SP 800-38A) Encrypt KAT (#A1947, Triple-DES) LS2_SW_Crypto Library:
• AES-CBC (SP 800-38A) Decrypt KAT (#A1948, 128-bit key)
• AES-CBC (SP 800-38A) Encrypt KAT (#A1948, 128-bit key)
• AES-CMAC (SP 800-38B) Sign KAT (#A1948, AES 128-bit)
• AES-CMAC (SP 800-38B) Verify KAT (#A1948, AES 128-bit)
• *AES-GCM (SP 800-38D) Encrypt KAT (#A1948, AES 128-bit)
• AES-KW (SP 800-38F) Unwrap KAT (#A1948, AES 128-bit)
• AES-KW (SP 800-38F) Wrap KAT (#A1948, AES 128-bit)
• Counter DRBG (SP 800-90Ar1) (instantiate/generate/reseed) KAT (#A1948, AES 256-bit)
• *ECDSA KeyGen (FIPS186-4) KAT (#A1948, P-256)
• ECDSA KeyVer (FIPS186-4) KAT (#A1948, P-256)
• ECDSA SigGen (FIPS186-4) KAT (#A1948, P-256 with SHA-1, SHA-256, SHA-384, SHA-512)
• ECDSA SigVer (FIPS186-4) KAT (#A1948, P-256 with SHA-1, SHA-256, SHA-384, SHA-512)
• HMAC-SHA-1 (FIPS-198-1) KAT (#A1948, HMAC-SHA-1)
• HMAC-SHA2-256 (FIPS 198-1) KAT (#A1948, HMAC-SHA-256)
• HMAC-SHA2-512 (FIPS 198-1) KAT (#A1948, HMAC-SHA-512)
• KAS-ECC SP800-56Ar3 KAT (#A1948, P-521 and HMAC-SHA-512)
• KAS-ECC-SSC SP800-56Ar3 KAT (#A1948, P-256)
• KAS-IFC-SSC (SP 800-56Br2) KAT (#A1948, RSA 2048-bit)
• KDA OneStep SP800-56Cr1 KAT (#A1948, SHA-224)
• KDA TwoStep SP800-56Cr1 KAT (#A1948, SHA-224)
• KDF ANS 9.63 (SP 800-135r1) KAT (#A1948, SHA-256)
• KDF SP800-108 CMAC in Counter mode KAT (#A1948, AES 128-bit)
• KDF SP800-108 HMAC in Counter mode KAT (#A1948, HMAC-SHA-256)
• *KDF TLS (SP 800-135r1) TLSv1.2 KDF KAT (#A1948, HMAC-SHA-256)
• PBKDF (SP 800-132) KAT (#A1948, HMAC-SHA-256)
• RSA (SP 800-56Br2) Encrypt KAT (2048-bit)
• RSA Decryption Primitive (SP 800-56Br2) (CVL) KAT (#A1948, 2048-bit)
• RSA SigGen (FIPS186-4) KAT (#A1948, 2048-bit)
• RSA SigGen (FIPS186-4) KAT (#A1948, 4096-bit)
• RSA SigVer (FIPS186-4) KAT (#A1948, 2048-bit)
• RSA SigVer (FIPS186-4) KAT (#A1948, 4096-bit)

• o *RSA Signature Primitive (CVL) (FIPS 186-4) KAT (#A1948, 2048-bit)
• TDES-CMAC (SP 800-38B) Sign KAT (#A1948)
• TDES-CMAC (SP 800-38B) Verify KAT (#A1948)
• TDES-KW (SP 800-38F) Unwrap KAT (#A1948) LS2_UBOOT Library: o
• RSA SigVer (FIPS186-4) KAT (#A1946, 2048-bit with SHA-256) OCTEON HW RBG:
• SP 800-90B startup health tests (RCT and APT)
• SP 800-90B (HW RBG) continuous health tests (RCT and APT)
• DRBG, SP 800-90A Health Tests (instantiate, generate, reseed) (#A1948, AES CTR 256-bit), (#A1947, Hash SHA512)
• SP 800-56A rev3 required assurances (All SP 800-56Ar3 implementations).
• SP 800-56Brev2 required assurances (All SP 800-56Br2 implementations). Note: CN_INVOKE_FIPS” will execute all the listed CASTs.
• Conditional pair-wise consistency test
• ECDSA/ECDH Pairwise Consistency Test (ECDSA FIPS 186-4 & KAS-ECC-SSC) at the time of key generation and import
• RSA Pairwise Consistency Test (RSA FIPS 186-4 & SP 800-56Br2) at the time of key generation and import Conditional software/firmware load test (7.10.3.4)
• –
• N/A Conditional bypass test (7.10.3.6)
• Firmware load test (RSA Signature Verification)
• RSA 2048-SHA-512 (#A1948) Conditional manual entry test (7.10.3.5) N/A Conditional critical functions test (7.10.3.7)
• Temperature monitor test
• Voltage monitor test
• PKCS Sign and Verify Mod exp CRT with private key and verify with public key at every Sign Operation Periodic Conditional self-tests
• Module performs periodic self-tests CASTs every 24 hours or as configured by MCO.
• Temperature monitor test: every 30 Seconds
• Voltage monitor test: every 400 micro seconds Note: Algorithms preceded with * marks that the algorithm is only utilized for self-tests.

Refer to the sections related to HSM installation and configuration in the user guide (LS2-HSM-NFBE-Driver-SDK- UserGuide; version 1.0 or later). Before installing the HSM, the customer verifies the following:

• The ElectroStatic Discharge (ESD) bag in which the HSM is placed in the shipping container is sealed and has not been tampered with.
• The part number and other information included in the label on the HSM matches the label on the shipping bag.

• There is no evidence of physical tampering on the HSM itself. After this is verified, the customer can physically insert the HSM into the PCIe on the host server. The host must meet the following requirements: • Support low-profile PCIe Gen 3/Gen 4 (x4 or x8 slot) • SR-IOV support enabled. After the HSM is physically installed, the LS2 driver and utilities that communicate with the HSM are installed on the host using standard Linux/Operating system tools. The user must be logged in the host as root/Administrator to perform the installation. The HSM owner then completes the following steps to claim ownership of the HSM and enable the approved mode:

1. Loads the driver (command: insmod <driver.ko>).
2. Invokes Cfm2Master Utility and logs in as default crypto officer (CO) and initializes the HSM. For example: Command: initHSM -p <CO password> -sO <CO user name> -fips_state [2|3] As part of initializing the HSM: • The Master Crypto Officer is created with username/password (see Table 8 and Table 9 for a description of this role, authentication requirements, and service access). • The fips_state flag is set on the HSM (non-Approved, Approved with single- or dual-factor authentication, or Approved with dual-factor authentication required). As a final step, the HSM owner claims the HSM by loading the adapter owner certificates (AOTAC and AOAC) on the HSM and import the HSM owner fixed backup key (OKBK). These steps are taken by the MCO using Cfm2MasterUtil. Example command syntax: Command: storeCert -s <cert-type> -f <Adapter Owner Trust Anchor Cert (AOTAC)>.crt Command: storeCert -s <cert-type> -f <Adapter Owner Auth Cert (AOAC)>.crt Command: storeMCOFixedKey -f <path>/<OKBK file>

The specific tasks that can be performed by users on the HSM are strictly limited by their user role (see Table 8 for details). A user of the module can query the module’s device information, operational parameters, operating mode by invoking the command getHSMInfo from the Cfm2MasterUtil. “FIPS state” member of the output will indicate the module to be in one of the following modes:

• Approved mode with 1FA (“2”)
• Approved mode with 2FA (“3”)
• Non-Approved mode (“0”)
• Zeroized (“1”) Example command syntax: Command: getHSMInfo The following compliance-specific conditions are applicable to the HSM module:
• Crypto Officer must maintain control of the module while the zeroization process is executing.
• There are no restrictions on which keys or CSPs are zeroized by the zeroization service.
• The module does not support a maintenance interface or role.
• The module does not support bypass capabilities.

• The module does not support manual key entry.
• The module has no CSP feedback to operators.
• The module does not enter or output plaintext CSPs.
• The module does not output intermediate key values part of any operation.
• The module is delivered to the users using the following secure distribution mechanism.
• The module is attached with a specific part number and serial number labels. And, kept in a tamper evident ESD bag with the same labels.
• Then the ESD bags are put inside a shipping box and delivered to customers using any preferred shipping carriers.
• Optionally the modules are locked to a given customer using the AOTAC cert during the manufacturing process and is locked to not run any other commands unless AOAC loaded as per the steps mentioned above. HSM Zeroization The instances of zeroization mentioned below are executed through the utilities. There are different types of zeroization which can be executed through utilities: o zeroizeHSM --> example command: Cfm2MasterUtil singlecmd zeroizeHSM. This zeroizeHSM will delete all the Partition which in turn will zeroize all the partition CSPs, including cleanup all the temporary SSPs.
• This maps to CN_ZEROIZE service. o zeroizeHSM along with option (-factory_reset) can be used by operator to zeroize all non-vendor specific CSSPs.
• VENDOR zeroizeHSM can be used to zeroize all SSPs. To operate a VENDOR zeroizeHSM the operator must log-in as Crypto Officer with its credentials. Without the credentials of the crypto officer, the vendor zeroize can’t be executed.
• This maps to CN_ZEROIZE service with –factory_reset option This maps to CN_VENDOR_ZEROIZE service. Notes:
• Temporary SSPs (like in this case: session keys and Integrity test values) are forcefully memset to 0 during session close, application close, partition deletion and zeroization of the partition or the HSM.
• Reboot is a power cycle operation which will lead to the zeroization of temporary SSPs like session Keys.
• Zeroization of a partition or HSM execution can take a few minutes to complete. The zeroization request command is blocked until the execution is completed only after zeroization of required CSPs is completed. User is notified about delay with a notification log as depicted below. The Operator must remain in control of the module while the zeroization process is executing. For example: (the below output is executed through Marvell provided driver utilities): Cfm2MasterUtil singlecmd zeroizeHSM Version info, Driver Version: 10.02.11.01, SDK API Version: 10.02.11.01 Cfm2AppInitWithExtNonce () returned app id : 000e0000 Cfm2OpenSession2() returned 0x00 : HSM Return: SUCCESS Command: zeroizeHSM Successful zeroization of HSM will reboot the HSM and Host-HSM handshake will be re-done. Please wait, this may take few minutes. Cfm2ZeroizeHSM returned: 0x00 : HSM Return: SUCCESS Current FIPS mode is: ffffffff

Note: Unsigned ffffffff indicates zeroized, which is –1.

• DRBG context : On zeroizeHSM command DRBG related contexts are reset. This means that the internal state of the context with respect to DRBG become unusable.
• In case the power is lost unexpectedly and if the TDES keys are permanent keys, then the module can continue to use the TDES keys for encryption after the module restart as well, until the encryption limit is reached.
• On a routine basis, the MCO can verify that the HSM is correctly operating in approved mode by providing MCO credentials and invoking the command “fipsTest” from the Cfm2MasterUtil utility. The fipsTest utility invokes CN_INVOKE_FIPS service to perform the CAST. Example command syntax: Command: fipsTest
• The following compliance-specific conditions are applicable to the HSM module:
• There are no restrictions on which keys or CSPs are zeroized by the vendor zeroization service (CN_VENDOR_ZEROIZE).
• The module does not support a maintenance interface or role.
• The module does not support bypass capabilities.
• The module does not support manual key entry.
• The module does not enter or output plaintext CSPs.
• The module has no CSP feedback to operators. The module does not output intermediate key values part of any operation.
• The cryptographic module clears previous authentications on power cycle. The module does not let access SSPs between approved/non-approved and requires zeroization of the HSM/partition.
• When the module has not been placed in a valid role, the operator shall not have access to any cryptographic services.

On successful completion of the FIPS tests, the DA Green LED remains in the “ON” state. If any other LED remains in the permanent glow, the card’s is in ERROR state. Any of these fatal errors will cause the module to reject all future commands received. Resetting the module is required to recover from the situation. Bootloader-level self-test failures will reset the board automatically. There is no separate LED indication for this error. All these fatal errors are shown on UART when the issue is observed. In addition, the latest errors are reported on UART on bootup. Because the logs are maintained within the module’s flash memory, which has no direct access to external users/ applications, they are not vulnerable to any tampering. Table 17 LED Flash Pattern for Errors Y Y Y Y

AES GCM IV restoration upon Power Cycle of Module: If the module’s power is lost and then restored, the module will establish new sessions, which will generate new IVs. For an E2E (TLS) session, this will result in fresh handshake; new AES-GCM keys and IVs will be established for the new session.

No mitigation of other attacks is implemented by the module.

1. NIST Key Wrap Specification SP 800-38F, December 2012.
2. NIST Special Publication 800-38D November 2007.
3. NIST Special Publication 800-56A rev3 , April 2018.
4. NIST Special Publication 800-56B rev2, March 2019.
5. NIST Special Publication 800-56C rev2, August 2020.
6. NIST Special Publication 800-52 rev2, August 2019.
7. NIST Special Publication 800-57 Part-1 rev5, May 2020.
8. FIPS PUB 186-4, Digital Signature Standard (DSS), July 2013.
9. FIPS PUB 140-3, FIPS Publication 140-3 Security Requirements for Cryptographic Modules.
10. NIST Special Publication 800-90A rev1, June 2015.
11. NIST Special Publication 800-90B, January 2018.
12. Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program.
13. NIST Special Publication 800-131Ar2, March 2019.
14. NIST Special Publication 800-133r2 rev2, June 2020.
15. NIST Special Publication 800-108, October 2009.
16. NIST Special Publication 800-135 Revision 1, December 2011.
17. LS2-HSM-NFBE-Driver-SDK-UserGuide-1.0.

ATF Arm Trusted Firmware CAST Cryptographic Algorithm Self-Tests HSM Hardware Security Module KAS Key Agreement Scheme KAT Known Answer Test KBK Key Backup Key KLK Key Loading Key MCO Master Crypto Officer PCO Partition Crypto Officer PCU Partition Crypto User SR-IOV 2FA Single Root I/O Virtualization 2-Factor Authentication

Marvell first revolutionized the digital storage industry by moving information at speeds never thought possible. Today, that same breakthrough innovation remains at the heart of the company's storage, networking and connectivity solutions. With leading intellectual property and deep system-level knowledge, Marvell semiconductor solutions continue to transform the enterprise, cloud, automotive, industrial, and consumer markets. For more information, visit www.marvell.com. and/or its Affiliates in the US and/or other countries. This document may also contain other registered or common law trademarks of Marvell and/ or its Affiliates. Doc. No. LS2-HSM-SP Revised: January 14, 2025

Referenced URLs

• https://www.marvell.com/support/downloads.html
• www.marvell.com