| Standard | FIPS 140-3 |
|---|---|
| Overall level | 3 |
| Module type | Hardware |
| Embodiment | Multi-Chip Stand Alone |
| Status | Active |
| Sunset date | 8/27/2026 |
| Caveat | Interim validation. When operated in FIPS mode; The module generates cryptographic keys whose strengths are modified by available entropy. |
| Vendor | DocuSign, Inc. |
| Algorithm | ACVP Cert |
|---|---|
| AES-CBC | A4400 |
| AES-CBC | A4404 |
| AES-GCM | A4404 |
| ECDSA KeyGen (FIPS186-5) | A4404 |
| ECDSA SigGen (FIPS186-5) | A4404 |
| ECDSA SigVer (FIPS186-5) | A4404 |
| HMAC DRBG | A4400 |
| HMAC-SHA2-256 | A4400 |
| HMAC-SHA2-256 | A4404 |
| HMAC-SHA2-384 | A4400 |
| HMAC-SHA2-384 | A4404 |
| HMAC-SHA2-512 | A4400 |
| HMAC-SHA2-512 | A4404 |
| KAS-ECC-SSC Sp800-56Ar3 | A4404 |
| PBKDF | A4404 |
| RSA KeyGen (FIPS186-5) | A4400 |
| RSA SigGen (FIPS186-5) | A4400 |
| RSA SigGen (FIPS186-5) | A4400 |
| RSA SigGen (FIPS186-5) | A4404 |
| RSA SigVer (FIPS186-5) | A4400 |
| SHA2-256 | A4400 |
| SHA2-256 | A4404 |
| SHA2-384 | A4400 |
| SHA2-384 | A4404 |
| SHA2-512 | A4400 |
| SHA2-512 | A4404 |
| TLS v1.2 KDF RFC7627 | A4404 |
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;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
| # | Section | Page |
|---|
| Item | Page |
|---|---|
| Table 1 – FIPS 140-3 Section Security Level | 7 |
| Table 2 – Terminology | 9 |
| Table 3 – Cryptographic Module Tested Configuration | 10 |
| Table 4 – QSCD Error States | 17 |
| Table 5 – Approved Algorithms | 19 |
| Table 6 – Non-Approved Algorithms Not Allowed in the Approved Mode of Operation | 20 |
| Table 7 – Set System Parameters command | 21 |
| Table 8 – Get Status command | 22 |
| Table 9 – Get System Parameters command | 22 |
| Table 10 – Authenticate command | 24 |
| Table 11 – Software Upload command | 24 |
| Table 12 – Ports and Interfaces | 26 |
| Table 13 – Roles, Service, Input and Output | 29 |
| Table 14 – Roles and Authentication | 31 |
| Table 15 – Approved Services | 34 |
| Table 16 – Physical Security Inspection Guidelines | 38 |
| Table 17 – EFP / EFT | 38 |
| Table 18 – SSPs | 42 |
| Table 19 – Non-Deterministic Random Number Generation Specification | 43 |
| Item | Page |
|---|---|
| Figure 1 – The Module’s Front and Rear View | 10 |
| Figure 2 – DocuSign QSCD Appliance Hardware Block Diagram | 11 |
| Figure 3 – DocuSign QSCD Secure Operational Environment | 12 |
| Figure 4 – DocuSign QSCD Appliance API Model | 15 |
| Figure 5 – QSCD States | 16 |
| Figure 6 – DocuSign QSCD Appliance in FIPS mode (Installed State) | 21 |
| Figure 7 – The Module’s Front View | 25 |
| Figure 8 – The Module’s Rear View | 25 |
| Figure 9 – QSCD Appliance Tamper Seal Location | 38 |
| Figure 10 – Safety Sticker | 49 |
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. ISO/IEC 24759 Section 6 FIPS 140-3 Section Title Security Level [Number Below]
1 General 3
2 Cryptographic module specification 3
3 Cryptographic module interfaces 3
4 Roles, services and authentication 3
5 Software/Firmware security 3
6 Operational Environment N/A
7 Physical security 3
8 Non-invasive security N/A
9 Sensitive security parameters management 3
10 Self-Tests 3
11 Life-cycle assurance 3
12 Mitigation of other attacks N/A
Table 1
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. Term Meaning API Application Programming Interface APT Adaptive Proportion Test CA Certificate Authority CAVP Cryptographic Algorithm Validation Program CC Common Criteria CKG Cryptographic Key Generation CMVP Cryptographic Module Validation Program CO Crypto Officer COC Certificate of Compliance COTS Commercial Off The Shelf CRC16 Cyclic Redundancy Check (16 bit) CSP Critical Security Parameters DTBS Data To Be Signed ECDHE Ephemeral Elliptic Curve Diffie-Hellman EDC Error Detection Code EFP Environmental Failure Protection EFT Environmental Failure Testing ESV Entropy Source Validation GCM Galois Counter Mode HMAC Keyed-Hash Message Authentication Code HSM Hardware Security Module IDP Identity Provider JSON JavaScript Object Notation JWT JSON Web Token KAT Known Answer Test KDF Key Derivation Function KTS Key-Transport Scheme LCD Liquid Crystal Display MAC Message Authentication Code NIC Network Interface Controller NTP Network Time Protocol PBKDF Password-Based Key Derivation Function PCB Printed Circuit Board
Term Meaning PSP Public Security Parameters QSCD Qualified Signature Creation Device RCT Repetition Count Test REST Representational state transfer SAML Security Assertion Markup Language SCA Signature Creation Application SHS Secure Hash Standard SSA Server Signing Application SSD Solid State Drive SSP Sensitive Security Parameter SSS Shamir Secret Sharing TLS Transport Layer Security TSP Trust Service Provider Table 2
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. The key features of the appliance are:
Model Hardware Firmware Distinguishing Features version version DocuSign QSCD Appliance 2.0.0.0 1.2.0.7 Module type: hardware Embodiment: multi-chip standalone appliance The module is operating in FIPS compliant mode:
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.
The following figure shows the module’s hardware block diagram. Power Cryptographic Boundary AC Power Supply 1 Power CPU Control Input Power Control Output 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
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 (Signature Creation Application) SAML or JWT Certificate request Certificate IDP SSA CA (Identity Provider) (Server Signing Application) (Certificate Authority) SAML Signature or JWT sent back to application DocuSign QSCD Appliance Admin User Audit Log Server NTP Servers (Network Time Protocol) Technical Log Server Figure 3
SAML or JWT token. The DocuSign QSCD validates the SAML token and enables the signer to access his/her signature key.
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:
The user then performs the following steps:
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:
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:
DocuSign QSCD Appliance can be in one of the three following 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. Error Meaning CryptoError Failed cryptographic KAT SSLError Failed cryptographic KAT of the TLS library TamperHWFailure Failed to communicate with the tamper board TamperCrcError Failed to validate the tamper firmware CRC16 TamperMismatch The hash of the data in the tamper memory does not match the expected value or is not equal to the value stored in the QSCD appliance database Tamper A tamper event occurred SWVerifyError Failed to verify the firmware signature DBError Failed database connectivity check CriticalError Failed to execute any of the self-tests above Table 4
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: Description/ CAVP Algorithm and Mode/Method Key Size(s)/ Use/Function Cert. Standard Key Strength(s) Core Cryptographic Algorithms A4400 AES CBC AES / Data Encryption FIPS 197 128, 192, 256 bits / 128, 192, 256 bits Vendor CKG1 DRBG Key / Key Generation affirmed SP 800-133 256 bits /
A4400 HMAC HMAC-SHA-256, HMAC / Message Authentication FIPS 198-1 HMAC-SHA-384, 256, 256, 256 bits / HMAC-SHA-512 256, 256, 256 bits A4400 HMAC_DRBG HMAC-SHA-256 HMAC / Deterministic Random SP 800-90A 256 bits / Number Generation
A4400 RSA Appendix A.1.6 RSA Key Generation/ Key Generation FIPS 186-5 Table B.1 (2-100) 2048, 3072, 4096 bits / 112, 128, 128 bits A4400 RSA SHA-256, RSA-PKCS#1 Digital Signature PKCS#1 v1.5 SHA-384, 2048, 3072, 4096 bits / Generation SHA-512 112, 128, 128 bits A4400 RSA PSS-SHA-256, RSA-PSS Digital Signature PKCS#1 v2.1 PSS-SHA-384, 2048, 3072, 4096 bits / Generation PSS-SHA-512 112, 128, 128 bits A4400 RSA SHA-256, RSA-PKCS#1 Digital Signature PKCS#1 v1.5 SHA-384, 2048, 3072, 4096 bits / Verification SHA-512 112, 128, 128 bits A4400 SHS SHA-256, SHA2 / Message Digest FIPS 180-4 SHA-384, None / Hash for digital signature SHA-512 128, 192, 256 Generation E10 ESV N/A Seeding/reseeding SP 800-90B the DRBG The unmodified output of the DRBG is used for symmetric key generation and as the seed for asymmetric key generation
Description/ CAVP Algorithm and Mode/Method Key Size(s)/ Use/Function Cert. Standard Key Strength(s) TLS (OpenSSL) Cryptographic Algorithms A4404 AES CBC AES / TLS Session Schema FIPS 197 128, 256 bits / Session data encryption 128, 256 bits A4404 AES GCM1 AES / TLS Session Schema FIPS 197 128, 192, 256 bits / Session data encryption 128, 192, 256 bits A4404 CVL TLS 1.2 SHA-256, SHA2 / TLS Key Derivation2 SP 800-135rev1 SHA-384 None / 128, 192 bits A4404 HMAC HMAC-SHA-256, HMAC / TLS Session Scheme FIPS 198-1 HMAC-SHA-384, 256, 256, 256 bits / HMAC-SHA-512 256, 256, 256 bits A4404 SHS SHA-256, SHA2 / TLS Session Schema FIPS 180-4 SHA-384, None / SHA-512 128, 192, 256 A4404 Elliptic Curve Appendix A.2.2 P-256, P-384, P-521 / Elliptic Curve Key FIPS 186-5 256, 384, 521 bits / Generation 128, 192, 256 bits A4404 KAS-ECC-SSC ECC Ephemeral P-256, P-384, P-521 / Key Exchange3 Sp800-56Ar3 Unified Scheme 256, 384, 521 bits / 128, 192, 256 bits A4404 PBKDF4 Option 1a 256 bits Password based key SP 800-132 derivation A4404 RSA SHA-256, RSA-PKCS#1 / Digital Signature PKCS#1 v1.5 SHA-384, 2048, 3072, 4096 bits / Generation SHA-512 112, 128, 128 bits A4404 Elliptic Curve ECDSA P-256, P-384, P-521 / Digital Signature FIPS 186-5 256, 384, 521 bits / Generation5 128, 192, 256 bits A4404 Elliptic Curve ECDSA P-256, P-384, P-521 / Digital Signature FIPS 186-5 256, 384, 521 bits / Verification1 128, 192, 256 bits Table 5
The module supports the following non-approved algorithms which are not allowed in the approved mode of operation: Algorithm/Function Use/Function RSA Key Transport (KTS) Key establishment methodology using PKCS#1-v1.5 provides between 112 and 256 bits of encryption strength Table 6
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:
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:
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. Command PUT https://{QSCD}:9091/api/v1/sysparams/tls_mechanisms_mode Header Content-Type: application/json Header Authorization: Bearer JWT ticket that was returned by the Authenticate command Body { "value":"2" } Response 204 No Content Table 7
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
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). Command GET https://{QSCD}:9091/api/v1/appliance Response { "name": "QSCD", "device_id": "eef8ebc4-f64d-a76c-5c65-6c18eef7ee4b", "sw_version": "1.2.0.7", "hw_version": "2.0.0.0", "md_version": "1.2.0.0", "time": { "use_ntp": false, "ntp_server": "0.0.0.0", "time": "2023-07-12T10:06:28.5442185Z" }, "network": { "use_dhcp": false }, "status": "installed", "kind": "key_gen_sign_hsm", "install_mode": "hsm", "cluster_id": "awhyIQJ2MXk=", "cluster_description": "Description", "state": "ok", "state_text": "On", "database_id": "dfac0fec-6876-4d68-8468-e2e4167e03e6", "debug_log_level": 0 } Table 8
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. Command GET https://{QSCD}:9091/api/v1/sysparams/tls_mechanisms_mode Response { "kind": "tls_mechanisms_mode", "name": "TLS Mechanisms Mode", "description": "0 - All mechanisms are available
"category": "general", "value_type": "int_type", "value": 2, "modifiable": true, "min_value": 0, "max_value": 2, "display": true, "display_order": 8 } Table 9
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:
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. Command POST https://{QSCD}: 9091/api/v1/auth Header Content-Type: application/json Body { "login_name" : "{ApplianceAdministrator}", "password" : "{ApplianceAdministratorPassword}" } Response { "id": "a053d06c-4b67-cc6a-c745-8677bf3ab6e6", "login_name": "appliance_administrator", "type": "appliance_admin", "valid_thru": "2022-11-30T16:09:04.6736587Z", "appl_name": "QSCD0004", "jwt": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpX tsdUnoX2AoC55XGHGhei-CPbaNL2I2aC" } Table 10
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. Command POST https://{QSCD}:9091/api/v1/software Header Content-Type: multipart/form-data Header Authorization: Bearer JWT ticket that was returned by the Authenticate command Body Contents of software upgrade file Response { "id":"bd6a5aac-b704-6f93-f6d8-2e5e30908170", "upgrade_progress_info": "upgrading", "code": 0, "file_name": "UpgradeVer_1_0_0_9.dsp", "install_time": "2022-05-25T04:36:16.3383505Z" } Table 11
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 following table shows the mapping of the FIPS 140-3 logical interfaces to the module’s physical interfaces. Logical Interface Physical Port Data that passes over port/interface Ethernet Network ports Ciphertext data, ciphered cryptographic keys, device management data, device configuration data, ciphered Data Input Interface authentication data, status information, and other key management data USB port for smartcard-based token1 Cryptographic keys Ethernet Network ports Ciphertext data, ciphered cryptographic keys, device management data, device configuration data, ciphered Data Output Interface authentication data, status information, and other key management data USB port for smartcard-based token2 Cryptographic keys Used only during module initialization, and reset tamper operation Used only during pre-installation when generating or copying Master Keys on the USB token
Logical Interface Physical Port Data that passes over port/interface Ethernet Network ports Input commands, input data Display keys Input commands Control Input Interface On/Off Power switch Input commands Power connectors Input signals Control Output Interface Power connectors Output signals Ethernet Network ports Status output data Status Output Interface LCD display Status output data LED indicators Output indicators Power Interface Power connectors Power Table 12
The front of the module has several indicators and control buttons:
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:
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. Category Role Service Input Output CO, User, TLS Session QSCD and client TLS session and Anonymous establishment random data, QSCD ephemeral keys TLS Session1 certificate CO, User, Close TLS session None None Anonymous CO Install appliance Master keys Success code CO Write USB token Master keys Split Master Keys on USB token Appliance CO Read USB token Split Master Keys from Master Keys in tamper Setup USB token memory Anonymous Reset tamper Split Master Keys from Master Keys in tamper USB token memory CO Restore factory None None CO Set time from NTP NTP input None CO Monitoring None Status and audit log CO Update network setting Input data Success code CO Update time setting Input data Success code CO Set system parameters Input data Success code CO Manage Trusted Anchors Input data Success code CO Perform software Signed software file Success code Appliance upgrade Administration CO Perform backup None Encrypted backup file CO Restore from backup Encrypted backup file Success code CO Get technical log None Log file CO, Get appliance None Appliance information Anonymous information CO Restart None None CO Shutdown None None CO Create Administrator New Administrator Success code User user User info Administration CO Delete Administrator User ID Success code user 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.
Category Role Service Input Output CO Get users list None Users list CO Get user details User ID User information CO Change password New password Success code CO Unlock Administrator User ID Success code user CO, User Authenticate User ID, Success code Authentication Authentication data User Digital signature Encrypted key blob, Output buffer input buffer Cryptographic User Encryption/Decryption Encrypted key blob, Output buffer Operations input buffer User, Get random Required length of Random data Anonymous random data CO Create User User information Encrypted user blob CO Delete User User ID Success code CO Generate User User ID Encrypted key blob SSA key pair/key Administrator CO Delete User User ID Success code key pair/key CO Supply DTBS User ID, input buffer Success code CO Collect result User ID Output buffer Table 13
Administrators use identity-based authentication with a user ID/password over the TLS session. After successful authentication, the module issues a JSON Web Token (JWT) ticket which is then used to verify the 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) which generates a SAML or JWT ticket. The SAML/JWT ticket is then used to verify the user in all subsequent 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. Role Authentication Method Authentication Strength The module enforces a minimum password length of six Unicode characters. Each character may be numeric (0-9) or alphanumeric (a-z, A-Z) or Unicode. Based on an alphanumeric set of characters there are 62 possible characters and the password is at minimum 8 characters long. Therefore, the probability of a random attempt to succeed is:
CO User ID/Password less than 1 in 1,000,000. It takes the module approximately 1msec to process a login attempt, for a maximum of 1,000 login attempts in 1 second and 60,000 login attempts in 1 minute. Therefore, the probability of a random attempt to succeed during a minute is:
in 3,639,001,759. This too is significantly less than 1 in 100,000. The SAML token is based on a 2048-bit digital signature which has security strength of 112 bit. The probability that random access will succeed is 1 / (2112) which is far less than one in 1,000,000. SAML/JWT ticket protected by CO The appliance cannot process more than 3000 SAML RSA 2048 bit key1 validations per second, thus the authentication provides a 1 in (2112 / (3000 x 60)) probability of a successful random attempt during a one-minute period. This is exponentially less than 1 in 100,000. 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.
Role Authentication Method Authentication Strength The JWT token is based on a HMAC-SHA-256 with AES 256 bit key which has security strength of 256 bit. The probability that random access will succeed is 1 / (2256) which is far less than one in 1,000,000. JWT ticket protected by AES-256 CO The appliance cannot process more than 10000 JWT bit key validations per second, thus the authentication provides a 1 in (2256 / (10000 x 60)) probability of a successful random attempt during a one-minute period. This is exponentially less than 1 in 100,000. Table 14
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:
FIPS 186-5 HMAC-DRBG 18,19 G HMAC-SHA-256 21,22,23 R,W Close TLS session Close TLS connection between CO, User, HMAC-DRBG 17,18,19 Z QSCD and client machine Anonymous Install appliance Enter Operational state by CO SSS, 1,2,3,4,5, R,W Message installing the appliance; This HMAC-SHA-256 6,7 on front service is available only when the RSA Generate 13 G panel appliance is in factory state FIPS 186-5 display Write USB token Write key part into the USB token CO SSS, 1,2,3,4,5, R,W Message HMAC-SHA-256 6,7 on front panel display
Service Description Roles Approved Keys Access Indicator Security and/or rights Functions SSPs to Keys and/or SSPs Read USB token Read key part from the USB CO SSS, 1,2,3,4,5, R,W Message token HMAC-SHA-256 6,7 on front panel display Reset tamper Return to Operational state after CO SSS, 1,2,3,4,5, R,W Message Tamper event HMAC-SHA-256 6,7,16 on front panel display Restore factory Restore the appliance back to CO AES-CBC 7 E Message Factory State and erase all All Z on front settings panel display Set time from NTP Set module time using NTP Anonymous protocol Monitoring Send system status and audit log CO AES-CBC 2 E to external monitoring servers Sign 13 E PKCS#1 v1.5 Update network Set network parameters for the CO AES-CBC 3,7 E Message setting Ethernet interfaces such as DHCP on front on/off, IP address, default panel gateway, DNS, routing table etc. display Update time setting Set time or configure NTP server CO AES-CBC 3,7 E Set system Set system parameters like CO AES-CBC 3,7 E parameters password policy, RSA key generation parameters, logging etc. Manage Trusted Manage the Trusted Anchors CO AES-CBC 3,7 E Anchors which are used to validate SAML 14 R,W tickets Perform software Update the firmware CO AES-CBC 7,9 E upgrade Verify 12 E PKCS#1 v1.5, HMAC-SHA-256 Perform backup Backup system parameters and CO AES-CBC 5,6,7 E other settings into encrypted file Restore from Restore system parameters and CO AES-CBC 5,6,7 E backup other settings from backup file Get technical log Get the module’s technical log CO AES-CBC 7 E files Get appliance Get general information such as CO, information network information, time, Anonymous status, etc.
Service Description Roles Approved Keys Access Indicator Security and/or rights Functions SSPs to Keys and/or SSPs Restart Perform hardware restart CO 7,17,18, Z Message 19,20 on front panel display Shutdown Shutdown the module CO 7,17,18, Z 19,20 Create Create administrator user CO AES-CBC 3,7 E Administrator user 10 W Delete Delete administrator user CO AES-CBC 7 E Administrator user 10 Z Get users list Get list of users CO AES-CBC 3,7 E Get user details Get user details CO AES-CBC 3,7 E Change password Change password of CO AES-CBC 3,7 E administrator user 10 W Unlock CO AES-CBC 7 E Administrator user Authenticate Authenticate user using user CO, User AES-CBC 3,7 E ID/password or SAML ticket 10,14 R Digital signature Enable client applications to use User AES-CBC 1,3,4,7 E RSA keys for digital signatures Sign 8 E signing operations in PKCS#1 v1.5 PKCS#1 v1.5, or PSS schemas RSA-PSS Encryption/ Enable client applications to use User AES-CBC 1,3,4,7,9 E Decryption AES keys for data encryption/decryption in CBC mode Get random Get random data Anonymous HMAC-SHA-256 21,22,23 R,W Create User Create a user CO AES-CBC 1,3,4,7 E 8,9 W Delete User Delete a user CO AES-CBC 7 E Generate User Generate RSA key pair/AES key CO AES-CBC 1,3,4,7 E key pair/key on behalf of the user FIPS 186-5 8,9 W RSA key gen 11 R,W,Z HMAC-SHA-256 21,22,23 R,W Delete User Delete the user’s RSA key pair CO AES-CBC 7 E key pair/key 8,9 Z
Service Description Roles Approved Keys Access Indicator Security and/or rights Functions SSPs to Keys and/or SSPs Supply DTBS Supply data to be CO AES-CBC 4,7 E signed/encrypted Collect result Collect the result of CO AES-CBC 3,7, 9 E cryptographic operation Sign 8 E PKCS#1 v1.5, RSA-PSS Table 15
The module performs two software and firmware integrity tests:
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 external tamper-evident seal provides physical evidence of any attempt to tamper with the module cover. 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. This includes inspecting the enclosure of the appliance as well as the tamper seal and the physical interfaces as listed in the following table. Physical Security Recommended Inspection/Test Guidance Details Mechanism Frequency of Inspection/Test Appliance enclosure 1 year
Physical Security Recommended Inspection/Test Guidance Details Mechanism Frequency of Inspection/Test Environment 1 year
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. Temperature or voltage EFP or EFT Shutdown or Zeroisation measurement Low Temperature +5°C EFP Shutdown High Temperature +45°C EFP Shutdown Low Voltage 10.75V EFT Shutdown High Voltage 12.9V EFT Shutdown Table 17
No additional non-invasive mitigation techniques are employed by the module.
The module protects SSPs against unauthorized disclosure, modification, and submission as follows:
The following table provides details on the SSPs used by the module. SSP# SSP Name / Strength Security Gener- Import / Establish- Storage Zero- Use / related keys Type (bits) Function ation Export ment isation and Cert. Number Master Keys
SSP# SSP Name / Strength Security Gener- Import / Establish- Storage Zero- Use / related keys Type (bits) Function ation Export ment isation and Cert. Number
128 186-5 generation key generation
RSA key ended values gen A4400 Module SSPs
SSP# SSP Name / Strength Security Gener- Import / Establish- Storage Zero- Use / related keys Type (bits) Function ation Export ment isation and Cert. Number TLS Session Keys
32 bytes secret SHA-256 HMAC data
key HMAC- integrity SHA-384 A4404 20. INTER-EC-GEN 128, 192, FIPS Internal NA/NA Memory Key Intermediate EC
256 186-5 EC generation key generation
key gen ended values A4404 DRBG Keys
Entropy sources Minimum number Details of bits of entropy ESV (Cert. #10) Produce 2-bit A hardware-based entropy source ESV (Cert. #10) that meets the samples with requirements of NIST SP 800-90B (Recommendation for the Entropy estimated entropy Sources Used for Random Bit Generation). The entropy source is based of 1.760755 on Quantis IDQ6MC1 chip that generates entropy directly from a quantum process. The entropy source is used as a seed input to the HMAC_DRBG RNG. It generates a new seed every hour or when the reseed counter has reached the value of 100,000 requests. The module is compliant with the ESV (Cert. #E10) and is configured according to section “Configuration Settings” in the public use document1. The overall amount of generated entropy is 1.760755 bits per 2-bit sample and estimated amount of entropy per the sources output bit is.1.96 per 2-bit sample. HMAC_DRBG A Deterministic Random Bit Generator (DRBG) based on HMAC_DRBG algorithm as defined in NIST SP 800-90A rev 1 (Recommendation for Random Number Generation Using Deterministic Random Bit Generators). The algorithm uses HMAC-SHA-256 as its hash algorithm. The output of this DRBG is used to generate random data for key generation (RSA, EC, AES keys), TLS session establishment, digital signature and more. Table 19
The module uses TLS protocol version 1.2 for session key establishment. The cipher suites in use are 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:
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
There are two types of user keys that are managed by the SSA:
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 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:
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:
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:
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:
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
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:
Installation of QSCD appliance should follow these general guidelines: The key features of the appliance are:
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.