SafeCase Security Module

Certificate

Approved Algorithms (15)

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

flowchart LR
  %% Deterministic review-risk graph for SafeCase Security Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>Update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Status Output<br/>Show status<br/>self-test</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."]
    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?"]
    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"]
    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
  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,C6 clue;
  class I2,I3,I6 infer;
  class R2,R3,R6 risk;
  class E2,E3,E6 evidence;

flowchart LR
  %% Deterministic clue tier for SafeCase Security Module
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>Update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Status Output<br/>Show status<br/>self-test</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,C6 clueLow;

Security Policy, page by page

SafeCase Security Module Document Version D18 July 01, 2025 Prepared for: Prepared by: Privoro LLC KeyPair Consulting Inc.

Chandler, AZ 85226 San Luis Obispo, CA 93401 privoro.com keypair.us +1 844.774.8676 +1 805.316.5024 Privoro Public Material – may be reproduced only in its original entirety (without revision)

Privoro LLC SafeCase Security Module FIPS 140-3 Security Policy Table of Contents List of Tables List of Figures Privoro Public Material – may be reproduced only in its original entirety (without revision)

The Module is validated to FIPS 140-3 overall Level 2 requirements with security levels as follows: Table 1: Security Levels The Module is a firmware-hybrid Module as defined by [I19790], operated on a single-chip. The Module provides cryptographic services for use in SafeCase mobile device management systems. The tested Operational Environments are specified in Table 2 below. Table 2: Tested Operational Environments Memory-Mapped Cryptographic Acceleration Unit (MMCAU) within the NXP MK81FN256VDC15 single-chip which is the physical perimeter (TOEPP) of the module. The UID information returned by pcrypt_status contains name (“SCSM”), hardware version (0x81001BD9) for the MMCAU disjoint hardware component and firmware version (“1.0.1”), consistent with the Module’s CMVP listing information and tabularized below: Privoro Public Material – may be reproduced only in its original entirety (without revision)

Privoro LLC SafeCase Security Module FIPS 140-3 Security Policy Table 3: Tested Module Versioning Information/Identification Please Note: The disjoint firmware component of the module is the libpcrypt.a statically linked library (version 1.0.1) and is identified by the identifier returned by the module, i.e. the ‘SCSM’ string as detailed in the table above.

The physical form of the Module is depicted below. The physical perimeter (i.e. the Tested Operational Environment’s Physical Perimeter (TOEPP)) consists of the surfaces, edges and solder connections of the NXP MK81FN256VDC15 integrated circuit shown in Figure 1. Top Bottom Figure 1: Module Physical Perimeter The module is a hybrid module with the disjoint firmware component, libpcrypt.a (executing on the ARM CPU core) and the disjoint hardware component (MMCAU) forming the cryptographic boundary as depicted in the Figure 2 (outlined in red). The libpcrypt.a uses AES hardware cryptographic accleration from the MMCAU. Both the disjoint components Privoro Public Material – may be reproduced only in its original entirety (without revision)

Privoro LLC SafeCase Security Module FIPS 140-3 Security Policy Figure 2: Module Block Diagram

The Module supports only an Approved mode of operation by default, and enforces the following security rules:

1. No additional interface or service is implemented by the Module which would provide access to SSPs.
2. Data output is inhibited during key generation, self-tests, zeroisation, and error states.
3. There are no restrictions on which keys or SSPs are zeroised by the zeroisation service.
4. The Module does not support manual key entry.
5. The Module does not output plaintext CSPs or intermediate key values.
6. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the Module. The Module design corresponds to the Module security rules. No specific installation requirements apply and the initialization process of the Module is as detailed in Section 11 of this document.

The Module does not support a degraded mode of operation.

The Module implements the Approved cryptographic functions listed in Table 4. Equivalent strength in bits is given for each key or algorithm type (as some algorithms do not use or produce keys). The term s is used throughout to indicate security strength, following the notation used in the majority of the sources (refer to the notes below Table 4). This table is referenced by Table 13 (SSPs). All references to the algorithm standards cited throughout this document can be found in the References section. Privoro Public Material – may be reproduced only in its original entirety (without revision)

Privoro LLC SafeCase Security Module FIPS 140-3 Security Policy 6.5. Privoro Public Material – may be reproduced only in its original entirety (without revision)

Algorithm RSADP

Caveat No security claimed

Use/Function Decryption of derived keying material, [FIPS 140-3_IG] 2.4.A Scenario 1

Privoro LLC SafeCase Security Module FIPS 140-3 Security Policy Note 1: Preimage resistance strength applies to hash algorithms used in DRBG, KDFs. Described also in [SP800-57P1r5] Table

3. Note 2: Elliptic curve strengths are annotated as approximate (i.e., s ~=) since [SP800-186] Table 1 provides approximate security strengths. Note 3: Approved elliptic curves for ECC key agreement are given in [SP800-56Ar3] Table
4. Note 4: In Digital Signature applications, security strength is primarily associated with the asymmetric key pair specification. The hash function used must have equivalent strength equal to or greater than the security strength of the associated key pair. Note 5: Estimated security strengths of common RSA moduli are given in [SP800-56Br2] Table
5. IFC key types approved for Digital Signature Generation and Verification are given also in [SP800-57P1r5] Table
6. Equivalent strengths are annotated as approximate (i.e., s ~=) since [SP800-56Br2] Table 4 provides approximate security strengths. Note 6: Security strengths for KDA One Step are given in [SP800-56Cr1] Table 1 (hash). Reference sources for the strengths provided in Table 4 are as follows: • AES (AES-256): [SP800-57P1r5] Table 2. • ECC (P-384): [SP800-186] Table 1. • IFC (k=2048): [SP800-56Br2] Table 4. • SHA2 (SHA2-256, SHA2-384): [SP800-107r1] Table
7. Table 5: Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed Please see the note below Table 9 pertaining to usage of RSADP. The module does not implement the following: • Non-Approved Algorithms Allowed in the Approved Mode of Operation • Non-Approved Algorithms Not Allowed in the Approved Mode of Operation

The Module’s logical interfaces are described in Table 6; the Module’s physical ports are outside the cryptographic boundary. Table 6: Ports and Interfaces The Control Output interface is not applicable, as the module does not control other components. Privoro Public Material – may be reproduced only in its original entirety (without revision)

Privoro LLC SafeCase Security Module FIPS 140-3 Security Policy

The Module supports only the Cryptographic Officer (CO) role. It does not support multiple concurrent operators, a maintenance role or bypass capability. Operator authentication is described in Table 8. Table 7: Roles, Service Commands, Input and Output Privoro Public Material – may be reproduced only in its original entirety (without revision)

Privoro LLC SafeCase Security Module FIPS 140-3 Security Policy The pcrypt_status service does not require authentication and provides information to address both AS04.13 (Show module’s versioning information) and AS04.14 (output current status). The Module is similar to [FIPS140-3_IG] 2.4.C Scenario 2, where pcrypt_status provides a global dynamic indication of Module status and operation in the approved mode, augmented by a status value returned on each API call. The module supports role-based authentication. Table 9 describes all Approved services and service access to SSPs. The following annotations indicate the type of access G = Generate: The Module generates or derives the SSP. E = Execute: The Module uses the SSP in performing a R = Read: The SSP is read from the Module (e.g., the SSP is output). cryptographic operation. W = Write: The SSP is updated, imported, or written to the Module. Z = Zeroise: The Module zeroises the SSP. Table 9: Approved Services Privoro Public Material – may be reproduced only in its original entirety (without revision)

Privoro LLC SafeCase Security Module FIPS 140-3 Security Policy SW refers to the enumerated status return value, encoded in two bytes. The least significant byte gives status as one of the following: PCRYPT_STATUS_READY: Module operation successful/normal PCRYPT_STATUS_NOINIT: Module not initialized (Default startup state) PCRYPT_STATUS_STFAIL: Module self-test failure PCRYPT_STATUS_BADARG: Module passed invalid argument Privoro Public Material – may be reproduced only in its original entirety (without revision)

Privoro LLC SafeCase Security Module FIPS 140-3 Security Policy PCRYPT_STATUS_DISABLED: Module is disabled (tamper detected) PCRYPT_STATUS_ERROR: Module internal error The most significant byte indicates the use of a non-Approved algorithm; at the time of validation, this only applies to RSA Decrypt (RSADP). PCRYPT_STATUS_FIPS_NOALLOW: set to 1 if the service does not use an approved algorithm. Usage of RSADP is deemed non-Approved but allowed and conforms to [FIPS 140_3_IG] 2.4.A example scenario 1. All functions zeroise SSPs within the function scope after use. Call stack cleanup is the responsibility of the application. The Module-provided methods to deallocate memory perform active zeroisation (overwriting with zeros) prior to deallocation. Zeroisation of PW_Ref requires destruction of the firmware image via the SafeCase product Crypto Reset function (Table 13 “Z2”). As allowed by [SP800-140DTR] VE09.38.03, this mechanism is provided as a service of the SafeCase product. The indicator of zeroisation is a status word (SW) returned by the module as specified above.

The executable form of the disjoint firmware component of the Module is a firmware library statically linked in the SafeCase firmware. During initialization (without operator intervention and prior to operation), it performs an ECDSA P-

384 with SHA2-384 signature verification over all files in the Module boundary. The operator can initiate the integrity test

on demand by either power cycling the Module or by invoking the pcrypt_init service. The module does not support loading of firmware from an external source.

The Module executes in a limited operational environment as defined by [I19790]. The module does not support loading firmware from an external source. The Module is a single-chip embodiment as shown in Figure 1 with a tamper evident hard coating applied to it. The singleNo actions are required by the operator(s) to ensure that the physical security is maintained. Table 10: Physical Security Inspection Guidelines Table 11: EFP/EFT Table 12: Hardness testing temperature ranges Privoro Public Material – may be reproduced only in its original entirety (without revision)

High Temperature

+105 C

Privoro LLC SafeCase Security Module FIPS 140-3 Security Policy

[SP800-140F] currently does not define applicable metrics. The Module does not implement non-invasive security measures. Privoro Public Material – may be reproduced only in its original entirety (without revision)

Privoro LLC SafeCase Security Module FIPS 140-3 Security Policy

Table 13 summarizes the SSPs implemented by the Module. Table 13: SSPs Generation Import/Export Establishment Zeroisation Storage Strength is provided in bits. Please refer to Table 4 and the notes below it for the strength provenance (traceability to applicable standards and special publications). The separation into specific keys is done outside the scope of the module but must be conformant to [SP800-56Cr1]. Privoro Public Material – may be reproduced only in its original entirety (without revision)

Privoro LLC                                                                                                                  SafeCase Security Module FIPS 140-3 Security Policy Generation   Import/Export   Establishment             Zeroisation Storage Legend Generation                                       Establishment                                                                         Storage G1: [FIPS186-4] RSA keypair generation           E1: [SP800-56Ar3] §5.7.1.2 ECC CDH                                                    S1: RAM G2: [FIPS186-4] ECDSA keypair generation         E2: [SP800-56Cr1] KDA OneStep Generate; Reseed                                                                      Z1: Cleared after use, module initiated Import/Export                                                                                                                          Z2: Cleared by Crypto Reset, operator IE1: Call stack (API) parameters                                                                                                       initiated IE2: Entered in manufacturing Table 14: Non-Deterministic Random Number Generation Specification K81= NXP MK81FN256VDC15 Privoro Public Material – may be reproduced only in its original entirety (without revision)

Entropy sources

Minimum number of bits of entropy

Details 0.99 bits of entropy per bit of ENT output; as such the DRBG seeding material contains at least 1013 bits of entropy, well in excess of the requirement

Privoro LLC SafeCase Security Module FIPS 140-3 Security Policy

Each time the Module is powered on, it tests that the cryptographic algorithms still operate correctly, and that sensitive data has not been damaged. CASTs are available on demand and can be tested periodically using the pcrypt_selftest command. The integrity test can be run on demand by either power cycling the Module or by invoking the pcrypt_init service. The disjoint firmware component of the module, i.e., the libpcrypt.a, performs an ECDSA P-384 with SHA2-384 signature verification over all files in the Module boundary during module initialization i.e. on every boot. On power-on or reset, the Module performs the self-tests described below. All cryptographic algorithm self-tests (CASTs) must complete successfully prior to any other use of cryptography by the Module. The ECDSA CASTs are performed prior to the firmware integrity test. All CASTs are implemented as known answer tests. If one of the CASTs or the firmware integrity test fails, the Module enters the STFAIL error state. The error state is persistent, and no services are available. All attempts to use the Module’s services result in the return of a non-zero error code, PCRYPT_STATUS_STFAIL. A power-cycle or reset of the Module is required to recover from an error state, causing it to retry all self-tests. Pre-Operational Self-Tests

• FW integrity test: ECDSA #A2494 (P-384/SHA2-384) signature verification over all firmware in the Module boundary. Conditional Cryptographic Algorithm Self-Tests (CASTs)
• AES-CCM #A2494: Encrypt CAST performed using reference inputs (256-bit AES key size). Covers self-test requirement for AES-ECB encrypt.
• AES-CCM #A2494: Decrypt CAST performed using reference inputs (256-bit AES key size).
• ECDSA SigGen #A2494: Signature generation CAST using reference inputs (P-384, SHA2-384).
• ECDSA SigVer #A2494: Signature verification CAST using reference inputs (P-384, SHA2-384).
• ENT: [SP800-90B] Startup and conditional tests; executes a suite of self-tests prior to raising a “valid” flag.
• ENT(P) developer defined health tests.
• Hash DRBG #A2494: Instantiate, Generate and Reseed CASTs using reference inputs on the SHA2-256 Hash DRBG.
• HMAC-SHA2-384 #A2494: HMAC CAST using SHA2-384 and reference inputs (192-bit HMAC key).
• KAS-ECC-SSC #A2494: KAS-ECC-SSC CASTs using reference inputs (P-384 curve).
• KDA OneStep #A2494: One-Step KDF CAST using a known shared secret reference input (256-bit z).
• RSA SigGen #A2494: Signature generation CAST using reference inputs (k = 2048).
• RSA SigVer #A2494: Signature verification CAST using reference inputs (k = 2048).
• SHA2-256 #A2494: Message digest generation CAST using SHA2-256.
• SHA2-384 #A2494: Message digest generation CAST using SHA2-384. Conditional Pairwise Consistency Tests (PCTs)
• ECDSA KeyGen #A2494: Pairwise consistency test of generated key pair.
• RSA KeyGen #A2494: Pairwise consistency test of generated key pair. Privoro Public Material
• may be reproduced only in its original entirety (without revision)

Privoro LLC SafeCase Security Module FIPS 140-3 Security Policy

The Privoro SafeCase Security Module FIPS 140-3 Guidance [GD] describes all procedures for secure installation, initialization, configuration, provisioning, decommissioning and sanitization of the Module. The Module is a component of the SafeCase product, integrated in the Privoro manufacturing setting and thus no further installation procedures are required of the Crypto Officer. The initialization process for the module involves loading the module and successfully authenticating to it as the Crypto Officer using the pcrypt_init service. There are no maintenance requirements for the Module.

The Module does not implement mitigations of other attacks outside the scope of [FIPS140-3]. References

• [FIPS140-3]: FIPS 140-3, Security Requirements for Cryptographic Modules, 3/22/2019
• [SP800-140DTR]: NIST SP 800-140, FIPS 140-3 Derived Test Requirements (DTR): CMVP Validation Authority Updates to ISO/IEC 24759, 3/20/2020
• [SP800-140A]: NIST SP 800-140A, CMVP Documentation Requirements: CMVP Validation Authority Updates to ISO/IEC 24759, 3/20/2020
• [SP800-140B]: NIST SP 800-140B, CMVP Security Policy Requirements: CMVP Validation Authority Updates to ISO/IEC 24759 and ISO/IEC 19790 Annex B, 3/20/2020
• [SP800-140Cr2]: CNIST SP 800-140C Rev. 2, Cryptographic Module Validation Program (CMVP)-Approved Security Functions: CMVP Validation Authority Updates to ISO/IEC 24759, 7/25/2023 Supplemental Information: SP 800-140C: Approved Security Functions, 7/25/2023
• [SP800-140Dr2]: NIST SP 800-140D Rev. 2, Cryptographic Module Validation Program (CMVP)-Approved Sensitive Security Parameter Generation and Establishment Methods: CMVP Validation Authority Updates to ISO/IEC 24759, 7/25/2023 Supplemental Information: SP 800-140D: Approved SSP Generation and Establishment Methods, 7/25/2023
• [SP800-140E]: NIST SP 800-140E, CMVP Approved Authentication Mechanisms: CMVP Validation Authority Requirements for ISO/IEC 19790 Annex E and ISO/IEC 24579 Section 6.17, 3/20/2020
• [SP800-140F]: NIST SP 800-140F, CMVP Approved Non-Invasive Attack Mitigation Test Metrics: CMVP Validation Authority Updates to ISO/IEC 24759, 3/20/2020
• [FIPS140-3_IG]: Implementation Guidance for FIPS 140-3 and the Cryptographic Module Validation Program, 1/29/2024
• [I19790]: ISO/IEC 19790:2012 Information technology -- Security techniques -- Security requirements for cryptographic modules, 11/1/2015
• [I24759]: ISO/IEC 24759:2017 Information technology -- Security techniques -- Test requirements for cryptographic modules, 3/1/2017
• [FIPS180-4]: FIPS 180-4, Secure Hash Standard (SHS), 8/4/2015
• [FIPS186-4]: FIPS 186-4, Digital Signature Standard (DSS), 7/19/2013
• [FIPS197]: FIPS 197, Advanced Encryption Standard (AES), 5/09/2023
• [FIPS198-1]: FIPS 198-1, The Keyed-Hash Message Authentication Code (HMAC), 7/16/2008
• [SP800-38A]: NIST SP 800-38A, Recommendation for Block Cipher Modes of Operation: Methods and Techniques, 12/1/2001 Privoro Public Material
• may be reproduced only in its original entirety (without revision)

Privoro LLC SafeCase Security Module FIPS 140-3 Security Policy

• [SP800-38C]: NIST SP 800-38C, Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality, 7/20/2007
• [SP800-56Ar3]: NIST SP 800-56A Rev. 3, Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography, 4/16/2018
• [SP800-56Br2]: NIST SP 800-56B Rev. 2, Recommendation for Pair-Wise Key-Establishment Using Integer Factorization Cryptography, 3/21/2019
• [SP800-56Cr1]: NIST SP 800-56C Rev. 1, Recommendation for Key-Derivation Methods in Key-Establishment Schemes, 4/16/2018
• [SP800-56Cr2]: NIST SP 800-56C Rev. 2, Recommendation for Key-Derivation Methods in Key-Establishment Schemes, 8/18/2020
• [SP800-57P1r5]: NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: Part 1
• General, 5/04/2020
• [SP800-63B]: NIST SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management, 3/02/2020
• [SP800-90Ar1]: NIST SP 800-90A Rev. 1, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, 6/24/2015
• [SP800-90B]: NIST SP 800-90B, Recommendation for the Entropy Sources Used for Random Bit Generation, 1/10/2018
• [SP800-107r1]: NIST SP 800-107 Rev. 1, Recommendation for Applications Using Approved Hash Algorithms, 8/24/2012
• [SP800-133r2]: NIST SP 800-133 Rev. 2, Recommendation for Cryptographic Key Generation, 6/04/2020
• [SP800-186]: NIST SP 800-186, Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters, 2/03/2023
• [GD]: SafeCase Security Module FIPS 140-3 Guidance, 12/17/2021 Acronyms and Definitions
• CAVP: Cryptographic Algorithm Validation Program
• ACVTS: Automated Cryptographic Validation Testing System
• AES: Advanced Encryption Standard, see [FIPS197]
• API: Application Programming Interface
• CAST: Cryptographic Algorithm Self-Test
• CCM: Counter with CBC-MAC
• CKG: Cryptographic Key Generation
• CMVP: Cryptographic Module Validation Program
• CO: Cryptographic Officer
• CSP: Critical Security Parameter, see [FIPS140-3]
• CPU: Central Processing Unit
• CCCS: Canadian Centre for Cybersecurity
• DRAM: Dynamic Random-Access Memory
• DRBG: Deterministic Random Number Generator, see [SP800-90Ar1]
• DTR: Derived Test Requirements
• ECB: Electronic Code Book Privoro Public Material
• may be reproduced only in its original entirety (without revision)

Privoro LLC                                                                        SafeCase Security Module FIPS 140-3 Security Policy •    ECC: Elliptic Curve Cryptography •    ECDSA: Elliptic Curve Digital Signature Algorithm, see [FIPS186-4] •    FIPS: Federal Information Processing Standard •    HMAC: Keyed-Hash Message Authentication Code, see [FIPS198-1] •    IG: Implementation Guidance, see [FIPS140-3_IG] •    KAS: Key Agreement Scheme •    KDF: Key Derivation Function •    MAC: Message Authentication Code •    NIST: National Institute of Standards and Technology •    OE: Operating Environment •    PCT: Pairwise Consistency Test •    PSP: Public Security Parameter •    RSADP: RSA Decryption Primitive •    SHA/SHS: Secure Hash Algorithm/Standard, see [FIPS180-4] •    SP: NIST Special Publication •    SSC: Shared Secret Calculation •    SSP: Sensitive Security Parameter Privoro Public Material – may be reproduced only in its original entirety (without revision)