Document Comparison

Table 2: Summary of Changes Document and Requirements Change Type General Specified that multiple test requirements require the test laboratories to review source code to facilitate validation to the applicable Security Requirements unless otherwise specified. This was an FAQ moved into the DTRs.

Additional Guidance General Throughout the document, changed that the test laboratory shall prepare the Asset Flow Analysis instead of the vendor; and separated the process of Analysis from the output of Diagram.

Requirement General Throughout the document, specified that TDES keys of any size must not be used for device security purposes (such as firmware authenticity, device-level key storage, etc.); that cryptography used for this purpose implements an effective key strength of 128 bits or stronger.

Requirement General Throughout the document, replaced “not feasible” and “infeasible” with “not practical” and “impractical.” Additional Guidance Glossary Added definitions for Biometric Reader, Biometric Sensor, Certificate, Certification Authority, Dual Control, External Memory, Hardware-Management Devices, …

Additional Guidance SR B15 Rewrote the requirements for clarity. Requirements SR B23 Clarified that cleartext account data must never be available to execution environments that are able to execute third- party applications, even through the use of whitelists.

Additional Guidance SR B23.1 Specified that devices supporting third-party applications are unable to release cleartext account data to the execution environment even through the use of whitelists.

Requirement SR B24 Specified that a keyed-hash function must be implemented. Requirement Appendix B Added Biometric Reader and Third-party Application to Applicability Matrix.

Requirement DTRs Introduction Added Requirements Applicability Guidance. Additional Guidance DTR A1 Eliminated epoxy as a consideration. Requirement DTR A1 Added consideration for secret or private keys that are not zeroized in the event of tamper if forward-secrecy is used, and extraction of these keys requires the destruction of the processing element using the key.

Requirement DTR A1 Specified that ephemeral keys erased immediately after use in …

Additional Guidance DTRs A4 Clarified the protection methods for public keys. Requirement DTR A4 Additional clarification on sensitive functions and data. Additional Guidance DTR A5 Specified that where the device supports third-party applications, protections are provided to prevent the disclosure of PINs during entry through the use of device sensors such as accelerometers, gyroscopes, etc.

Requirement DTR A8 Clarified the intent and applicability of display-prompt protection.

Additional Guidance DTR A13 Clarified that SCRs intended for use with COTS devices do not require the same level of attack potential as SCRPs.

Additional Guidance DTR B1 Specified that self-test functions that are implemented by the firmware of the device must use cryptography that implements an effective key strength of 128 bits or stronger.

Requirement DTR B1 Specified that authenticated applications in this requirement do not include third-party applications.

Requirement DTR B1 Clarified guidance for memory re-initialization Additional Guidance DTR B2 Specified that firmware updates must use cryptography …

Requirement DTR B3 Added accessibility option for PIN Entry. Requirement DTR B5 Specified that devices must support at least one of the encrypted key-loading methods for the loading of private or secret keys. This was an FAQ moved into the DTRs.

Additional Guidance DTR B8 Added ISO PIN-block format 1 as an option. Requirement DTR B9 Specified that ECC functionality is addressed if the device can compute an ECDH shared secret and can verify an ECDSA or ECSDSA signature using curve P-256.

Requirement DTR B9 Removed allowance for the support of the ANSI X9.143 Key Variant Binding Method. Requirement DTRs B9 Specified acceptable storage and distribution using key blocks of symmetric keys using both symmetric and asymmetric techniques.

Requirement DTR B9 Specified applicability of minimum key sizes and parameters for algorithm(s) applies to acquirer-based keys that are used for key transport, exchange, or establishment.

Additional Guidance DTR B9 Specified that terminal security keys, such …

Requirement DTR D1 Specified that if a device implements an IP stack, it must support TLS 1.3 or higher and prevent the use of TLS versions less than v1.2, as well as cipher suites that do not provide cryptographic protections equivalent to an effective key strength of 128 bits or greater. Certificate authentication with a key strength of 128 bits or greater must be supported, but certificate authentication with a key strength of 112 bits or greater may also be supported. TLS restrictions are N/A to third-party applications.

Requirement DTR D2 Specified interfaces that may be excluded from consideration.

Requirement DTR D2 Specified that where a physical interface is provided with the expectation that services or protocols are implemented on this by non-firmware applications, it shall be noted in the report.

Requirement DTR D2 Specified that the tester shall identify in the report the publicly-available sources of vulnerability disclosure used.

Requirement DTR D2 Specified …

Requirement DTR E7 Clarified applicability to both key-loading facilities and facilities of initial deployment.

Requirement DTR F3 Clarified applicability where manufacturing and the initial key-loading facility are in the same physical building.

Requirement Appendix E Updated to specify TDES keys of any size must not be used for device security purposes (such as firmware authenticity, device-level key storage, etc.); and that DSA is not allowed for any use.

Requirement Appendix E Specified algorithms and minimum key sizes for device security purposes.

Requirement Appendix F Provided clarification of SCA for SRED-only devices. Additional Guidance Appendix G Clarified public keys relative to Security Domains. Additional Guidance