DocuSign QSCD Appliance

Certificate

Approved Algorithms (27)

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

flowchart LR
  %% Deterministic review-risk graph for DocuSign QSCD Appliance
  %% 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<br/>Upgrade</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>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/>library named: openssl</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<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 DocuSign QSCD Appliance
  %% 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<br/>Upgrade</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>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/>library named: openssl</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<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

DocuSign QSCD Appliance Hardware version 2.0.0.0 Firmware version 1.2.0.7 FIPS 140-3 Non-Proprietary Security Policy Level 3 Validation August 2024 Document Version 1.7

This is a non-proprietary Cryptographic Module Security Policy for the DocuSign QSCD Appliance. This security policy describes how the DocuSign QSCD Appliance meets the security requirements of FIPS 140-3, and how to operate the appliance in a secure FIPS 140-3 compliant mode. This document was prepared as part of the FIPS 140-3 level 3 validation of the DocuSign QSCD Appliance. It fulfils the security policy requirements as specified in ISO/IEC 19790:2012, B.2.1 to B.2.12 and in NIST Special Publication 800-140B, CMVP Security Policy Requirements: CMVP Validation Authority Updates to ISO/IEC The following table lists the module’s FIPS 140-3 security level for each individual area.

FIPS 140-3 (Federal Information Processing Standards Publication 140-3 -- Security Requirements for Cryptographic Modules) details the requirements for cryptographic modules. More information on the National Institute of Standards and Technology (NIST) and the Canadian Centre for Cyber Security (CCCS) Cryptographic Module Validation Program (CMVP), the FIPS 140-3 validation process, and a list of validated cryptographic modules can be found on the CMVP website: http://csrc.nist.gov/groups/STM/cmvp/index.html. This document deals only with the operations and capabilities of DocuSign QSCD Appliance in the technical terms of a FIPS 140-3 cryptographic module security policy. Additional information about DocuSign QSCD Appliance and other DocuSign products is available at www.docusign.com. The DocuSign QSCD Appliance is also referred to in this document as the appliance, cryptographic module, or the module.

The following table prescribes a common understanding of the terms and abbreviations used throughout this document.

The DocuSign QSCD Appliance is a digital signature product intended to be used as a Qualified Signature Creation Device (QSCD) in a secure operational environment. It is a highly secure, high capacity network attached HSM. The device consists of COTS hardware, tamper resistance hardware, a hardened operating system, an internal database and server software.

Table 3 – Cryptographic Module Tested Configuration

The cryptographic boundary, establishing a contiguous perimeter for the DocuSign QSCD Appliance, is defined as the components that are enclosed within the physical case of the module, save for the hot-swappable dual power supplies.

Power Control I Control

nput Output

CPU

The following figure shows the module’s hardware block diagram. Power                                                                                   Cryptographic Boundary AC Power Supply 1 Control Input AC Power Supply 2                                          FrontSide Bus PCIe Bus        Ethernet 0          Ethernet Port DDR4                                                       Bridge Memory Bus PCIe Bus        Ethernet 1          Ethernet Port    Data Input Data Output Control Input PCI Bus Status Output SSD Drive 0              Sata Interface USB Bus USB Port Bridge SSD Drive 1              Sata Interface Data Input Data Output RS232                         USB Display IDQ6MC1 chip              Processor Entropy source                                                                                                                                Status Output Tamper board Display Keys Control Input Micro-Switch                            Micro-Switch Figure 2 – DocuSign QSCD Appliance Hardware Block Diagram

SAML or JWT

Signature sent back to application

The module meets FCC requirements in 47 CFR Part 15 for personal computers and peripherals designated for home use (Class B). It is labeled in accordance with FCC requirements.

DocuSign QSCD Appliance is installed in a secure operational environment and interacts with other software components and services.

The following figures illustrates the secure environment architecture of a TSP (Trust Service Provider). Signing User SCA IDP SSA CA (Identity Provider) (Server Signing Application) (Certificate Authority) DocuSign QSCD Appliance Admin User Audit Log Server NTP Servers (Network Time Protocol) Technical Log Server Figure 3

• DocuSign QSCD Secure Operational Environment The DocuSign QSCD operational environment includes the following components: The SSA is a Web application that enables the signer to perform digital signatures through a web interface. For detailed explanation about the signing process performed by the SSA, refer to section 2.4.2.
• IDP (Identity Provider) The IDP authenticates the signer and provides a proof of authentication in the format of a signed

SAML or JWT token. The DocuSign QSCD validates the SAML token and enables the signer to access his/her signature key.

• SCA (Signature Creation Application) The SCA is an application that is executed in the user’s PC or in a web application. Prior to the signature process, the SCA presents the data to be signed (DTBS) for review by the signer in order to obtain the signer’s decision. The SCA interacts with the SSA for the purpose of digital signature creation. The SSA replies to the SCA with a digital signature, and the SCA incorporates the digital signature in the document.
• CA (Certificate Authority) The CA generates certificates for signers based on the signature key generated in the Appliance. The SSA interfaces with the CA; it sends the certificate request to the CA and the CA replies with a certificate.
• Audit Logs Server All audit information is sent to an external audit log server.
• Technical Logs Server Some technical logs information is sent to an external server.
• NTP Server The DocuSign QSCD is synchronized with the NTP servers to ensure it has accurate time.
• Administrator Machine Administrators can connect remotely to the Appliance using TLS protocol and perform administrative operations.

The SSA is a Web Application that is deployed in the operational environment and enables the signer to perform digital signatures through a web interface. It is the application that interacts with the user while performing cryptographic operations, acting as a proxy between the user and the module, so some of the operations it performs are on behalf of the user. The SSA has the following characteristics:

• It interacts directly with end users and thus does not expose the QSCD to attacks from external networks
• It conducts the whole lifecycle of creation of a user, key generation, certificate enrollment and the digital signature ceremony
• It enables the QSCD to be of a minimal functionality To perform a signing operation, the SSA will:
• Create a New User Any cryptographic operation in the QSCD appliance starts with SSA user that creates a new user. The input for this command is the user ID and the user login name which uniquely identifies the entity that will use the key.
• Generate a key pair for the user A key is generated for the user. The output of this command is an encrypted key blob that will later be used by the user to perform the cryptographic operation. The module does not keep key storage for cryptographic keys used by the users.
• Get Certificate Interact with the CA (Certificate Authority) to get a certificate for the user.
• Supply DTBS/R For Qualified digital signatures, upload the hash of the data will be signed by the user in advance and get as response a transaction ID.
• Ask the user to identify and authenticate according to the identity and authentication scheme.

The user then performs the following steps:

• Authenticate The user must authenticate to an external identity provider (IDP) and get a valid SAML ticket.
• Perform the Cryptographic Operation As the input of this command the user must supply the SAML ticket along with the encrypted key blob and the input data. Following the user authentication, a SAML token is passed through the SSA to the QSCD and triggers a signature operation. The SSA then:
• Verify the SAML ticket Verify the validity of the SAML ticket and that it belongs to the key blob user and in that way ensure that each key is associated with the correct entity.
• Perform the cryptographic operation in the QSCD appliance.
• Collect the signature and return it to the signing application.
• Depending on the type of signature key (ephemeral or persistent) the SSA decides whether to delete the user and his/her key from the module and from the SSA.

REST API Request

All commands to the DocuSign QSCD Appliance use the REST API, which is based on HTTPS (HTTP over TLS). The module’s REST API provides access to several categories of commands:

• Appliance setup
• Appliance admin
• User management
• Cryptographic operations Most API calls require additional Administrator authentication or User authentication.

After a command is sent to the module, its input parameters are checked with improper or wrong parameters rejected with an error code returned. Correct commands are executed, with the reply sent back to the client over the secure channel. The request is based on the following parameters: •    The operation’s name •    Input parameters in JSON format The response is based on the following parameters: •    Response return code (an integer) •    Output parameters in JSON format Application                           Application                       Application DocuSign QSCD Appliance Appliance Setup        Appliance Admin   Users Admin        Users Authentication Cryptography      SSA Install Appliance      Hardware Setting  Create/Delete User Authenticate         Digital Signature Create/Delete User Read/Write USB Token   System Parameters                                         AES Encryption Generate Key Pair Reset Tamper           Trusted Anchors                                                             Sign/Encrypt Software Upgrade Backup/Restore Figure 4 – DocuSign QSCD Appliance API Model

DocuSign QSCD Appliance can be in one of the three following states:

• Factory Settings State In this state the Appliance is not installed and does not contain any operational data such as Master Keys, Administrative Accounts or any other operational information in its database. All functionality of creating administrative roles or performing cryptographic services is closed and cannot be performed. The appliance installation process changes the appliance’s state from Factory state to FIPS approved Operational state. During installation, Master keys that were generated in pre-install procedure are read from two or more USB tokens. This sensitive operation should be done in a secure environment.
• Operational State In this state, it is possible to fully operate the appliance for its designated purpose as a QSCD. It is possible to turn the appliance back into factory state by performing the Reset Factory operation. Opening the appliance enclosure either when the power is on or off, will set the appliance to tamper state.
• Tamper State The appliance contains a tamper resistant mechanism which when activated erases the Master Keys data that are used to protect sensitive information. In the Tamper state the appliance does not serve any request beside an approval of an Appliance Administrator of the tamper condition called Reset Tamper. The transition to Tamper state will happen in any case the appliance has been tampered with, regardless of the appliance being in Factory or Operational state. Figure 5 below shows the transitions between the three states. Factory State Reset Tamper Operational Tamper State Tamper State Figure 5
• QSCD States

While the QSCD is in Operational state, it can be in either FIPS or non-FIPS mode. The distinction between these two modes depends on the selected TLS cipher suite. When operating in FIPS mode the QSCD must use only the ECDHE_RSA_AES_GCM based cipher suites. Refer to section 2.12 for instructions how to check if the module is operating in FIPS compliant mode.

Failure in any of the power-up or the critical function tests results in entering error state. The QSCD appliance software terminates and the module does not provide any cryptographic services to the users. A corresponding message is written into the QSCD appliance log file. A short error message appears in the display in the front panel of the appliance that indicates the type of error. Table 4 – QSCD Error States For more information about each error, refer to section 10.

The DocuSign QSCD Appliance supports a variety of cryptographic algorithms, and implements these algorithms based on the different cryptographic standards. The module supports the following approved algorithms: The unmodified output of the DRBG is used for symmetric key generation and as the seed for asymmetric key

Table 5 – Approved Algorithms Implementation of AES-GCM complies to NIST SP 800-56Ar3 guidelines. IV is generated internally using the approved DRBG. A 64-bit counter is used, to assure that no two encryptions will use the same counter value. No parts of the TLS protocol, other than the KDF, have been tested by the CAVP and CMVP As per IG D.F Scenario 2 path (2), the CAVP testing is performed in which case it is split into (i) testing the computation of the shared secret, (ii) testing the key derivation function used in deriving the keying material as per SP800-135 Rev 1 The PBKDF algorithm parameters are: password length 32 bytes long, salt length 16 bytes long and the number of iterations is 2048. The resulting key material is only used for storage applications. This algorithm, mode, and key/moduli sizes have been CAVP-tested but are not used by any approved service of the module

The module supports the following non-approved algorithms which are not allowed in the approved mode of operation: Table 6 – Non-Approved Algorithms Not Allowed in the Approved Mode of Operation

The appliance is delivered in the Factory Settings state. In this state it is not installed and does not contain any operational data. Once the CO starts performing the following operations to install and configure the Appliance to run, it is then operating in FIPS mode:

• Generating Master Keys
• The Master Keys are generated prior to the appliance installation and contain secret information that is critical for the operation of the appliance. The Master Keys are generated inside the appliance, split into two or more parts and written on password protected USB tokens; each belonging to a different CO.
• Copying the USB Tokens
• It is possible to duplicate a USB token that contains appliance Master Key part.
• Installing the appliance
• This critical procedure must be performed in a secure environment. After the appliance installation, the administrator can modify the system parameters and start the cryptographic services of the appliance.
• Setting the appliance to FIPS mode
• This final step sets the appliance to work in approved FIPS mode. The Initialization operations can be performed by the Appliance Administrator, either by:
• GUI Based Client Application
• This is a simple setup utility running on the Administrator Windows PC, which is connected to the appliance through Ethernet port NIC2 as it has a fixed IP address. Any operation from the GUI application requires physical access to the appliance by unplugging/plugging the USB token with Master Keys.
• REST API Calls
• Administrators can connect to the appliance via the internal network and directly call the REST API functions.

The generation of the Master Keys and optionally copying them onto the USB tokens are preliminary steps that must be performed prior to the installation of the module. These operations must be performed in a secure environment. In this step, a GUI based client application running on a PC connected to the module is used to send commands to the appliance to generate the Master Keys, split them into parts and store each part on a separate password protected USB token connected to the appliance. The QSCD Appliance Master keys are protected using M of N protection measure, which requires that a minimum number of agents (M) out of the total number of agents (N) work together to perform high-security tasks such as QSCD installation. The Master Keys are split into N parts, but during installation, only M out of N parts will be required to successfully build the Master Keys and install the appliance. The minimum number of N parts is 2 and the maximum is 9. The value of M has to be smaller or equal to N. After the Master Keys are generated they are split into N parts using SSS algorithm. The USB tokens are formatted, their password set and the key parts are written into them. Each USB token is given to a different CO (Appliance Administrator). Later, during installation, the Master Keys are built using M parts out of N using the SSS algorithm. For a complete list of the master keys refer to section 9.1.

The appliance installation is performed by the Appliance Administrators using the GUI based client application. Installation commands are sent to the appliance over secure TLS 1.2 channel. As explained in 2.10.1, M out of N USB tokens with the split Master Keys are required for this operation. Each is password protected and belongs to a different CO. Thus, to complete the appliance installation, each CO must separately authenticate after inserting the token in their possession. During installation, the CO performs the following security related actions:

• Select Appliance Type
• The appliance type is selected: HSM mode, Advanced signatures or Qualified signatures.
• Define Appliance Administrator
• The name and password of the Appliance Administrator is defined.
• Define Users Administrator
• The name and password of the Users Administrator is defined.
• Load Master Keys
• The Master Key components are read from N out of M USB tokens, rebuilt using SSS, and placed in the module’s internal tamper device memory. After installation, the CO (Appliance Admin) can set additional parameters like the appliance IP address, supported TLS cipher suites, default RSA key size, NTP servers and many more.

To set the module in FIPS mode, the CO has to set the appliance to use only the ECDH based TLS cipher suites (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384). Use the Set System Parameters command to set the value of the system parameter tls_mechanisms_mode to 2, meaning only the ECDH cipher suites are enabled. } Table 7 – Set System Parameters command

To verify if the module is operating in FIPS compliant mode, check the appliance display and call two REST API functions: Get Status and Get System Parameters.

Verify that the appliance display shows a message that it has been installed. Figure 6 – DocuSign QSCD Appliance in FIPS mode (Installed State)

The Get Status command queries the appliance’s state. Verify the correct status (installed), hardware version (2.0.0.0) and software version (1.2.0.7). }, }, }

The Get System Parameters command queries the supported TLS cipher suites. In FIPS mode, only ECDH based cipher suites should be enabled (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384). Verify the that the value of the system parameter tls_mechanisms_mode is 2, meaning only the ECDH cipher suites are enabled. } Table 9 – Get System Parameters command

The appliance offers a backup operation so that in the case of a technical failure, it will be possible to restore all the information of the database to a new appliance. The backup operation does not contain any key material such as pre-generated RSA keys, but it does contain the following information from inside the appliance:

• System Parameters
• Trusted Anchors (for example, public keys used to verify SAML/JWT tickets)
• Administrators account information The restoration of an appliance is based on the following components:
• Backup USB Tokens A set of M out of N backup USB tokens. From these tokens the whole set of Master Keys are rebuilt using SSS.
• Backup File An encrypted and MACed backup file that includes all the required information for a complete restore of the appliance. The information includes all entities in the database as well as some additional configuration information. When the CO performs the backup operation using the dedicated REST API operation, a protected backup file is prepared by the appliance and downloaded to the Administrative workstation. The file must be accessible only to the COs that hold the USB tokens. To restore an appliance, it first must be installed using the M out of N backup USB tokens. Then, a restore database operation is performed with the provided backup file.

When an Appliance enters Tamper state, a blinking Tamper message appears on the appliance display. In this state, the appliance does not provide any service except the ability for the COs to perform the reset tamper operation. M out of N appliance administrators with the matching USB tokens are required to perform this process. Each administrator has to insert his/her USB token and supply its password. Warning: If you suspect the appliance has been tampered with, contact DocuSign Support via the following web page: https://support.docusign.com/en/contactSupport. The reset tamper operation should be performed only if you are sure that the tamper event occurred as part of a maintenance operation or a controlled operation.

Firmware upgrades are sent to customers through DocuSign support channels. Each software upgrade package is digitally signed using 3072-bit RSA private key controlled by DocuSign engineering corresponding to the public key FIRM-SIG. If the signature verification fails, the module returns an error code and the loaded software is discarded. Only CMVP validated versions are allowed to be uploaded. Firmware upgrade can be performed only by the appliance administrator. Two REST API function calls are needed to perform this operation: Authenticate and Software Upload. The Authenticate command is used to authenticate as the appliance administrator. It returns a JWT token that is later used to perform the Software Upload command. } } Table 10 – Authenticate command

The Software Upload command loads the signed upgrade package. After the software is loaded into the module by the CO, the signature is verified using FIRM-SIG, which is embedded in the module’s firmware. If the verification fails, the module returns an error code and the loaded software is discarded. }

The module is steel, rack mountable box. The physical ports in the front of the module include on/off power button with power indicator, a display, display keys and a USB connector. On the back of the module, there are two power connectors and two network connections (Ethernet Interfaces using TCP/IP). The module is encased in a steel cover, with only the specified ports providing access to the module. All ports use standard connector interfaces. USB port Power switch and Display Display keys: power indicator Up, Down, Left, Right, Home, Back and OK Figure 7

• The Module’s Front View Dual power supply Ethernet network interfaces Tamper seal Figure 8
• The Module’s Rear View The following table shows the mapping of the FIPS 140-3 logical interfaces to the module’s physical interfaces. Used only during module initialization, and reset tamper operation Used only during pre-installation when generating or copying Master Keys on the USB token

Table 12 – Ports and Interfaces Commands sent through the network port are packaged using a REST format and sent to the appliance over the TLS-secured sockets on ports 443, 9091 and 9092 (only in the tamper state). The TLS protocol is based on server authentication (One-way TLS). The power connector has control input and control output signals between the external power supplies and the cryptographic boundary of the module. The signals only control the power mechanism of the module and are not inhibited whenever the module is in error state. Status and telemetry information is sent through the network ports to a cloud-based event monitoring system. This information can be used to collect performance figures, error reporting and to detect hardware, networking and performance issues as they occur. Additional status information is sent to an external audit log server. No CSPs or other sensitive information is sent to the external monitoring and audit systems.

The front of the module has several indicators and control buttons:

• The LCD display shows instructions such as insert/remove the USB token, critical errors such as tamper and general status information such as: host name, appliance status, software version, IP address, default gateway, etc. The display also shows different error messages (see sections 2.8 and 10).
• On/off power button with power indicator. The power switch has a dual-colored LED:
• A steady blue indicates that the device is running normally
• A flashing red indicates a malfunction, such as bad memory, stopped fan, loss of one of the two power sources, etc.
• Display keys (Up, Down, Left, Right, Home Back and OK) which are used to operate the appliance for example when performing comprehensive restore factory The rear of the module has two field replaceable power supplies. Each power supply unit is connected to a power network and includes a status LED whose color indicates the unit’s power status:
• A steady green indicates that power is applied (110-220V)
• A blinking red and a continuous audible alert indicate that power is not applied to this unit but applied to the other unit

The module has two classes of roles: Crypto Officer (CO) and User. The module does not support role change, thus an operator that has been defined as a CO cannot change to the User role. The module does not include a maintenance interface, nor does it include a maintenance role.

There are three types of CO administrative sub-roles:

• Appliance Administrator This role is responsible for installing, configuring and maintaining the appliance, by performing the following operations:
• Install the appliance
• View and modify system parameters
• Backup/Restore the module’s data
• Shutdown/Hardware Restart the appliance
• Upload software updates provided by DocuSign
• Download technical log files from the appliance
• Add/Update/Delete/View Trusted Anchors which are used to validate SAML tickets generated by an IDP
• Configure networking parameters (IP address, default gateway, DHCP, etc.)
• Configure time parameters (set current time, NTP server of the system)
• Reset Tamper to set the appliance state back to Operational state after tamper event
• Restore to factory settings to set the appliance back to Factory state
• Modify the debug level to control which information will be written to the technical log
• Users Administrator This role is responsible for managing module accounts, and can perform the following operations:
• Add a new Administrator
• Delete an existing Administrator
• Unlock an Administrator account that was locked after too many password failures
• View Administrator user information
• SSA (Server Signing Application) Administrator This role is responsible for performing cryptographic operations on behalf of the user, by performing the following operations:
• Create/delete a User entity
• Generate key pair/key for the User
• Perform cryptographic operation on behalf of the User

The user interacts with the QSCD via the SSA for the purpose of performing cryptographic operations such as digitally signing a document/data or performing AES encryption/decryption.

The following table provides a high-level summary of the approved services provided by the module. The TLS session service is used by all other QSCD services as it establishes the basic communication channel with the module, on which the REST API functions are sent.

Table 13 – Roles, Service, Input and Output

Administrators use identity-based authentication with a user ID/password over the TLS session. After administrative user in all subsequent REST API commands. In this case, the JWT ticket is protected by AES 256 bit key (MK-JWT) and HMAC-SHA-256 algorithm. Users also use identity-based authentication indirectly by authenticating to an external Identity Provider (IDP) REST API commands. In this case the SAML/JWT ticket is protected by RSA private key whose public key is stored in the appliance trusted anchors (TRUSTED-ANCHORS). Each REST API command requires a specific administrator JWT or user SAML/JWT ticket. Thus, multiple concurrent operators are allowed, and each command is specifically tested to verify that the user is allowed to perform. The calculation is performed for the smallest supported RSA key size (2048 bit). When using larger RSA keys (3072 and 4096 bit), the probabilities are even smaller.

The following table shows for specific service, which role has access to it and which SSP and access type is used to provide the service. Refer to section 9.1 for the description of the SSPs used by each operation. The convention below applies to the following table when specifying the access permissions (types) that the service has for each SSP:

• 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 = Zeroise The module zeroises the SSP

The module performs two software and firmware integrity tests:

• Software Integrity Test The QSCD appliance’s firmware is signed with an RSA 3072-bit digital signature. This signature is verified using the corresponding RSA public key (FIRM-SIG) to ensure the integrity of the software.
• Tamper Firmware Test The tamper controller firmware is embedded in an EPROM on the tamper board. The EDC used to ensure the tamper firmware integrity is CRC16. Both tests are performed during the module power-up to ensure the software and firmware haven’t been modified. The tests are run before any other service has started. If the integrity tests succeed, then all other services are started. If any of the test fail, the QSCD services will not start and the module will enter error state. Later, those integrity tests are performed once a day as part of the periodic self-tests of the module. The CO can initiate those integrity tests on demand by requesting to restart the module by calling the restart REST API function.

This section is not applicable for FIPS 140-3 Level 3.

The DocuSign QSCD Appliance is a multi-chip standalone appliance. It has been designed to meet all FIPS 140-3 Level 3 requirements. The module is encased within a steel box rigged with a tamper-evident seal (see photo in section 3) and tamper-responsive micro-switches. Only the specified physical interfaces permit access to the module. Any intrusion attempt cause power to instantly cut off, preventing access to any useful information by zeroizing all plaintext Critical Security Parameters (CSPs) including the appliance Master Keys stored in the tamper board. The seal, installed at the manufacturing stage, is placed over the screw that joins the top cover and the bottom enclosure. Both the seal and screw must be removed in order to open the cover of the module. If the screw is even partially removed the micro-switches are tripped and the tamper response is triggered. There are two micro-switches, which are connected to the tamper board. One micro-switch is used for tamper detection regardless if the power is on or off and triggers zeroization of the appliance Master keys. The other micro-switch is used for tamper detection while power is on and it immediately turns off the appliance and, in that way, stops all services and zeroizes all CSPs. Any attempt to restart the Appliance, automatically displays tamper alerts on the physical display. Only a Reset Tamper operation performed by an CO (Appliance Administrator) can set the QSCD Appliance back to an Operational state. During the Reset Tamper Operation, the COs must physically insert the M out of N USB tokens. All vents on the module are baffled to meet FIPS 140-3 physical security requirements for opacity and probing.

The CO should perform a scheduled inspection of the module to verify no physical tampering has occurred. listed in the following table.

Table 16

• Physical Security Inspection Guidelines Tamper seal Figure 9
• QSCD Appliance Tamper Seal Location If there is any suspicion that the appliance has been tampered with, contact DocuSign Support via https://support.docusign.com/en/contactSupport or email security@docusign.com. The following table shows the QSCD appliance response to minimum and maximum temperature and voltage values. The temperature measurement is on the air inlet into the appliance. An additional protection on the module monitors the CPU temperature and if it exceeds, the appliance will shut down to prevent possible damage to the hardware. Table 17
• EFP / EFT

No additional non-invasive mitigation techniques are employed by the module.

The module protects SSPs against unauthorized disclosure, modification, and submission as follows:

• The SSPs that are stored inside the module are used by their assigned entity only for specific processes or functions.
• Access to functions that use keys is allowed only after the entity requesting access has been authenticated.
• TLS sessions between an operator’s PC and the module are authenticated and encrypted.
• The module does not provide key storage for cryptographic keys used by an entity. After generating a key, it is exported in an encrypted and MACed blob to the entity for their use.
• The variables that indicate the current sessions, the operators of sessions, and session keys are stored in RAM. When the module is powered off this information is erased as the RAM is powered off. Upon module restart, all entities must open new authenticated TLS sessions.
• The module provides no access to intermediate key generation values, and outputs no intermediate key generation information. All intermediate key generation values are zeroized when they are no longer needed.

The following table provides details on the SSPs used by the module. Generated inside the appliance during preliminary pre-installation procedure and split into N parts using SSS M out of N parts are recombined during installation using SSS and stored in tamper memory Stored in cleartext in tamper memory along with SHA256 hash for data integrity Any attempt to tamper the module results in tamper response, clearing the tamper memory

User blobs are encrypted (AES-CBC) using MK-EXT-KEK and HMACed (HMAC-SHA-256) using MK-JWS The module does not provide key storage for cryptographic keys used by an entity, therefore it cannot zeroize those keys Stored in the QSCD database with integrity (HMAC-SHA-256) using MK-MAC The RSA public key used for firmware signature validation and firmware update validation is hardcoded in plaintext in the signed module firmware Stored encrypted (AES-CBC) using MK-INT-KEK in a file on the module SSD drive Stored in QSCD database in plaintext with integrity (HMAC-SHA-256) using MK-MAC

Table 18 – SSPs Used for establishment of TLS sessions with users and stored encrypted (AES-CBC) in password protected PFX file on the module SSD drive Negotiated during the establishment of the TLS connection, stored in volatile RAM and destroyed when the session is terminated Upon shutdown, the HMAC_DRBG uninstantiate function zeroises the DRBG state DRBG Key of size 256 bits is based on a 512-bit random seed retrieved from an internal hardware entropy source (Quantis IDQ6MC1 chip)

Table 19

• Non-Deterministic Random Number Generation Specification Note: The module generates cryptographic keys whose strengths are modified by available entropy. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. Keys are input or output from the DocuSign QSCD Appliance in several processes:
• User keys are output from the appliance in encrypted and MACed key blobs.
• The CO can output/input CSPs from/to the appliance by performing backup and restore operations of the appliance’s database (See 2.12).
• CSPs are output from the module to the USB port during Master Key generation. The server Master Keys are generated, split into N parts using the Shamir Secret Sharing (SSS) algorithm and then written on external password protected USB tokens connected to the USB port.
• Only during installation, restoration or reset tamper operations, CSPs are input to the module from the USB port. The key parts are read from M out of N password protected USB tokens connected to the USB port. Then, the Master Keys are rebuilt using SSS.
• In regular operational mode there is no manual input or manual output of keys. https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validationprogram/documents/entropy/E10_PublicUse.pdf

Split knowledge procedures for key import and export are used during pre-installation, installation and reset tamper. Those procedures use USB tokens on which the master keys are split using the Shamir Secret Sharing algorithm. Those procedures use M of N scheme. The Master Keys are split into N USB tokens where (2 ≤ N ≤ 9). Then, it is possible to reconstruct the Master Keys from any subset of M USB tokens where (2 ≤ M ≤ N). This means that the minimum is (N = M = 2) meaning the Master keys are split into two parts and must be constructed from the same two parts. The higher supported limit is (N = M = 9), meaning the Master keys are split into nine parts and must be constructed from the same nine parts. The SSS algorithm well-known and proven to provide the requirement that the knowledge of any (M – 1) components provides no information about the original CSP other than the length.

There are two types of user keys that are managed by the SSA:

• Ephemeral keys Ephemeral keys can be used for signing for a very short time (several minutes). In many cases they are used for a single digital signature operation.
• Persistent keys Persistent keys can be used for a long period of time.

The DocuSign QSCD Appliance monitors firmware operations through a set of self-tests to ensure proper operation in accordance with FIPS 140-3. All tests run automatically without operator intervention. The CO can initiate the power-up self-tests and the critical function tests by cycling the module’s power and starting the QSCD firmware. The module includes three types of self-tests: power-up self-tests, critical function tests and conditional tests. When the module is powering up and performing these tests, the display port shows the message “Starting…”. Upon successful power-up self-tests and critical function tests, all QSCD services are started and the display shows the message "Installed”. If an error occurred an appropriate error message is displayed, and the module enters the error state. The order in which the self-tests are performed makes sure that any test that relies on another function will be performed only after that function was tested successfully. For example, the firmware integrity test is being performed only after the relevant cryptographic functions were tested.

The power-up self-tests are performed immediately after the module power is turned on. They include low-level hardware tests and cryptographic algorithm tests.

When power is first applied to the module, the hardware performs a series of checks to ensure it is functioning properly. The motherboard of the appliance performs an initial hardware check which is aimed to test the hardware components of the system such as the CPU, memory, network interfaces, SSD Drive and dual power supply. If there is any problem the appliance would not start, and the display will show the message (loading…). This low-level test is being performed prior to loading of the appliance operating system and running the QSCD services.

The critical function tests are performed after the power-up self-tests.

Upon startup, the QSCD communicates with the tamper device to check if tamper event has occurred. Failure to communicate with the tamper board results in tamper hardware error (TamperHWFailure).

This test calculates the CRC16 of the tamper firmware. Failure to calculate the expected CRC value results in tamper CRC error (TamperCrcError).

This test is designed to identify several problems that are related to the value of the Master keys stored in the tamper memory, for example:

• The appliance was installed from USB tokens that are not from the same set
• Due to hardware problem, the data in the tamper memory was changed and is now inconsistent
• A reset tamper operation was performed with wrong USB tokens, that do not match the database stored on the appliance The test verifies the integrity of the critical Master Keys stored in the tamper device, by calculating the SHA256 hash of the data in the tamper memory and comparing it to the expected value. The hash is also compared to the hash value stored in the database of the appliance. If the test fails, the appliance would not start and a corresponding message (TamperMismatch) is displayed.

The DRBG tests are performed upon power-up and immediately following the cryptographic algorithm tests. Both the entropy source ESV (Cert. #10) and the HMAC_DRBG are tested. The entropy source ESV (Cert. #10) power-up test follows the NIST SP 800-90B guidelines and include:

• Continuous health test on approximately 4000 random samples as described in 10.3.3. The HMAC_DRBG power-up test follows the NIST SP 800-90A guidelines and include:
• Instantiate function KAT
• Reseed function KAT
• Generate function KAT
• Reseed counter test

As part of the DocuSign development procedures, all executable and shared object files of the firmware are digitally signed using 3072-bit RSA private key controlled by DocuSign engineering. The signature of each file is produced using PKCS#1 v1.5-SHA-256 algorithm. When the module starts, after the hardware tests, it performs the firmware integrity test. The module verifies the signatures using the corresponding RSA public key (FIRM-SIG) which is embedded in the module’s code. If the signature verification fails, the appliance does not start and a corresponding message (SWVerifyError) is displayed.

A database connectivity check validates that the database is alive and can respond to requests. In the case of failure, the appliance’s service will not start and thus will not provide service to clients. A corresponding message (DBError) is displayed.

As the various software subsystems are initialized, the return codes are checked for success to verify the subsystems were initialized successfully. In any case the above tests failed to execute a critical error message (CriticalError) is displayed.

Known Answer Tests (KATs) are run at power-up for all implementations of cryptographic algorithms used by the module. In a Known Answer Test, input values, values of keys and output values are all hardcoded, thus checking only the execution of the algorithm itself. If the execution of the algorithm yields a different output than the hardcoded expected ones, then the test fails and a corresponding error is displayed. Failure in the Core algorithm tests results in (CryptoError) and failure in the TLS library tests results in (SSLError). The following Core cryptographic algorithms are tested:

• AES128, AES192, AES256 CBC Encrypt, Decrypt KATs
• SHA-256, SHA-384, SHA-512 KATs
• HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512 Calculation, Verification KATs
• RSA 2048 Sign, Verify KATs
• HMAC_DRBG KAT For the appliance’s TLS, additional library (OpenSSL) with the following implemented algorithms is tested:
• AES128, AES192, AES256 ECB, CBC, GCM Encrypt, Decrypt KATs
• SHA-256, SHA-384, SHA-512 KATs
• HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512 Calculation, Verification KAT

• RSA 2048, 3072, 4096 Encrypt, Decrypt KATs
• ECDSA P-256, P-384, P-521 Sign, Verify Test
• ECDH P-256, P-384, P-521 Key exchange KATs
• PBKDF5 using HMAC-SHA-256 KAT

To ensure the correct operation of the RSA/EC key generation, each newly generated RSA/EC key pair is tested for pairwise consistency. The newly generated private key is used to sign test data, and the resulting signature is then verified by the corresponding public key.

The entropy source is a non-deterministic RNG seed that is generated by high quality internal hardware chip (Quantis IDQ6MC1 chip). The chip meets the requirements of NIST SP 800-90B standard. It produces 2-bit samples with estimated entropy of 1.760755. The seed is updated every hour or when reseed counter is reached. The 2-bit outputs of the entropy source are checked by continuous random tests (RCT and APT) as defined in NIST SP 800-90B:

• Repetition Count Test (RCT) as defined in section 4.4.1, with the following values: -30 H = 1.5, α = 2 , C = 21
• Adaptive Proportion Test (APT) as defined in section 4.4.2, with the following values: -30 W = 512, H = 1.5, α = 2 , C = 248 The cutoff value C meets the requirement C <= W. If the continuous random tests fail, the appliance enters an error state with a corresponding error displayed.

A Deterministic Random Bit Generator (DRBG) based on HMAC_DRBG algorithm as defined in NIST SP 800-90A. The output of the HMAC_DRBG algorithm is also continuously checked for statistical errors by running the continuous random tests (RCT and APT) as defined in NIST SP 800-90B:

• Repetition Count Test (RCT) as defined in section 4.4.1, with the following values: -30 H = 6, α = 2 ,C=6
• Adaptive Proportion Test (APT) as defined in section 4.4.2, with the following values: -30 W = 512, H = 6, α = 2 , C = 31 The cutoff value C meets the requirement C <= W. In addition, the HMAC_DRBG are continuously tested for correctness as required by NIST SP 800-90A:
• Instantiate function KAT
• Reseed function KAT
• Generate function KAT
• Reseed counter test
• Uninstantiate KAT

Module firmware can only be remotely upgraded from the management system with proper authentication to the module. However, in order to strictly control the loading of new firmware to the appliance, the new firmware must be digitally signed by DocuSign. The load of a firmware update takes place using RSA signatures. The successful load of this update would render the module non FIPS validated unless the update has also been validated.

Once a day, the module performs periodic self-tests, which include the power-up self-tests (except low-level hardware tests) and the critical function tests listed above.

The CO can initiate the self-tests on demand by requesting to restart the module by calling the restart REST API function.

At manufacturing both tamper device and tamper seal are assembled. The assembly of these components activates the tamper mechanism and tamper evidence of the module. The whole product is fully tested before delivery. The product is packaged and directly delivered to the customer. The product is in a Factory state when delivered to the customer. During delivery, the product is protected by a unique tamper seal on the case and the casing of the appliance. It is also enclosed in a special plastic package protected with four distinct tamper evident security stickers similar to the following: Figure 10

• Safety Sticker Upon delivery, the CO must follow the instructions below:
• Verify that all the four stickers exist, have not been tampered with, and are attached to the plastic package.
• Verify that each tamper evident security sticker includes the word DocuSign and that its serial number matches the number listed in the QSCD delivery message sent from DocuSign.
• Open the plastic package and check the appliance’s case for any evidence of physical tampering.
• Check the tamper evident seal on the back of the appliance and make sure it is not damaged.
• Verify that the serial numbers of the tamper evident stickers and the tamper seal, match the documentation COC (Certificate of Compliance) received with the appliance (for security reasons, the serial numbers of the package are sent in two separate ways: email and paper).
• Turn on the module, verify that tamper error message does not appear on the display in the front panel and that it starts correctly without any error massage. If any problems or suspicions arise, the CO must contact DocuSign Support via https://support.docusign.com/en/contactSupport or email security@docusign.com.

In addition to the module, the CO will also get an electronic DocuSign envelope from DocuSign Manufacturing. This envelope includes the following information about the DocuSign QSCD Appliance:

• DocuSign QSCD Appliance serial number (for example: QSCD0004)
• Serial numbers of all the tamper evident stickers
• Additional information related to the appliance

Installation of QSCD appliance should follow these general guidelines: The key features of the appliance are: • The Appliance should be installed as part of the organizational IT infrastructure.

• The Appliance should be placed in a physically secure location in the IT infrastructure, which allows very limited physical access and a minimal number of IT personnel.
• The secure environment should be frequently inspected for any suspicious activity.
• A firewall should be employed to control and monitor all incoming and outgoing communication with the Appliance.
• No external access to the Appliance is allowed. All communication with the Appliance can be done only within the TSP (Trust Service Provider) operational environment. This means that:
• Any administrative access for the purpose of managing the Appliance (performed by an Appliance Administrator) or for managing Administrative accounts (performed be a User’s Administrator), must be performed from within the internal network of the Appliance infrastructure.
• All Administrative software shall be deployed only in the internal operational environment of the TSP.
• The SSA (Secure Signing Application) must also be deployed in the internal infrastructure of the TSP and can access the Appliance using the SSA Administrator credentials. Only the SSA can be accessible by signers from the external network of the TSP.

Refer to section 2.10 for general instructions on installing the QSCD appliance. For detailed instructions refer to the QSCD admin guide.

A scheduled inspection of the module should be performed to verify no physical tampering has occurred (see 7.2).

The procedures required for the secure destruction of the module are described in a proprietary document, which will be provided upon request.

The DocuSign QSCD Appliance does not include any mechanisms to mitigate other attacks.