DSA Signature Verification and Validation
Signature verification may be performed by any party (i.e., the signatory, the intended recipient or any other party) using the signatory’s public key. A signatory may wish to verify that the computed signature is correct, perhaps before sending the signed message to the intended recipient.
The intended recipient (or any other party) verifies the signature to determine its authenticity.
Prior to verifying the signature of a signed message, the domain parameters, and [..]
Digital Signatures – Key Pair Management
The secure use of digital signatures depends on the management of an entity’s digital signature key pair as follows:
- The validity of the domain parameters shall be assured prior to the generation of the key pair, or the verification and validation of a digital signature .
- Each key pair shall be associated with the domain parameters under which the key pair was generated.
- Key pairs shall only be used to generate [..]
The Digital Signature Algorithm (DSA)
DSA Parameters
A DSA digital signature is computed using a set of domain parameters, a private key x, a permessage secret number k, data to be signed, and a hash function. A digital signature is verified using the same domain parameters, a public key y that is mathematically associated with the private key used to generate the digital signature, data to be verified, and the same hash function that was used [..]
Cryptographic Module Guidance
The requirements in this section are intended to ensure that all entities using the cryptographic module have adequate guidance and procedures to administer and use the module in a secure manner. Guidance documentation consists of administrator and non-administrator guidance.
Administrator guidance is written material that is used by the Crypto Officer and/or other administrative roles for the correct configuration, maintenance, and administration of the cryptographic module. The administrator guidance contains information [..]
Cryptographic Module Finite State Model
The operation of a cryptographic module shall be specified using a Finite State Model (or equivalent) represented by a state transition diagram and/or a state transition table and state descriptions. The FSM shall be sufficiently detailed to demonstrate that the cryptographic module complies with all of the requirements of this standard.
Documentation shall include the FSM (or equivalent) using a state transition diagram and/or state transition table and state descriptions that [..]
Cryptographic Modules – Design
A design is an engineering solution that addresses the functional specification for a cryptographic module. The design is intended to provide assurance that the functional specification of a cryptographic module corresponds to the intended functionality described in the Security Policy.
Cryptographic modules shall be designed to allow the testing of the implemented functionality to this standard, where possible without compromising the security of the module, so that all the services of [..]
Cryptography – Configuration Management
Configuration management specifies the security requirements for a configuration management system implemented by a cryptographic module vendor, providing assurance that the integrity of the cryptographic module is preserved by requiring discipline and control in the processes of refinement and modification of the cryptographic module and related documentation.
A configuration management system is put in place to prevent accidental or unauthorized modifications to, and provide change traceability for, the cryptographic module and [..]
Cryptography – Conditional Self-Tests
Conditional tests shall be performed by a cryptographic module when the conditions specified for the following tests occur: Pair-Wise Consistency Test, Software Load Test, Manual Key Entry Test, Continuous RBG Test, RBG Entropy Source Test, and Conditional Bypass Test.
Pair-Wise Consistency Test (for public and private keys). If a cryptographic module generates public or private keys, then the following pair-wise consistency tests for every pair of generated public and private keys [..]
Cryptography – Pre-Operational Self-Test
The pre-operational tests shall be performed by a cryptographic module between the time a cryptographic module is powered on, either from a power-off state or a quiescent state (e.g., low power, suspend or hibernate) and the time that the cryptographic module uses a function or provides a service using the function to be tested.
Prior to using a security function, the pre-operational test(s) of that security function shall pass successfully. The [..]
Cryptography – SSP Zeroization
A module shall provide methods to zeroize all CSPs (including temporarily stored values) within the module.
Once a CSP is zeroized, the CSP shall not be retrievable from the module. Zeroization of PSPs, encrypted CSPs, or CSPs otherwise physically or logically protected within an additional embedded validated module (meeting the requirements of this standard) is not required at levels below Security Level 5.
Keys used only to perform pre-operational self-tests shall be [..]