By Gunawan Ang, PCI SSF Assessor
Introduction
In 2019, the Payment Card Industry Security Standards Council (PCI SSC) issued the PCI Software Security Framework which contains two standards: the PCI Secure Software Standard (SSS), and the PCI Secure Software Lifecycle (SSLC). These standards effectively replaced the PCI Payment Application Data Security Standard (PA-DSS) which retired at the end of Oct 2022.
The PCI SSS contains significant uplifts in software security requirements. The scope of the PCI SSS is not limited to cardholder data and sensitive authentication data, but also areas such as authentication credentials, cryptographic keys, and configuration files. While this shift promised more robust security, many payment software vendors continue to grapple in developing software that comply with the PCI SSS due to a lack of detailed understanding of this complex standard.
ISSUE
Payment software cryptographic implementation is one of the heavy uplifts in PCI SSS. The following are examples of newly-introduced requirements which tend to be a challenge for organisations:
1. Requirement 7.3:
All random numbers used by the software are generated using only industry-standard random number generation (RNG) algorithms or libraries. Industry-standard RNG algorithms or libraries are those that meet industry standards for sufficient unpredictability (for example, NIST Special Publication 800-22).
2. Requirement 7.4:
Random values have entropy that meets the minimum effective strength requirements of the cryptographic primitives and keys that rely on them.
Payment Software that generates cryptographic keys, random password, salt (for hashing), etc. uses one or more random number generators. The random number maybe produced by invoking a function that is either developed by the vendor themselves or third-party systems (hardware/software/library).
In either case, Payment Software vendors are required to ensure that their selected approach complies with the above requirements. The problem is that this is often overlooked when using third party system which later causes headaches (and unforeseen costs) in the assessment. If you are a Payment Software vendor, here is some guidance on how you can avoid this pitfall when architecting your product:
- Verify that the system (library/software/hardware) you use to generate a random number has passed an industry-accepted validation program such as FIPS 140-3. In such case, it is very important that you further verify the following:
a. The validation covers the random number generator used by the software.
b. The dependencies included in the validation is also used by the software to run the random number generator. - If the system is not validated, you can test the random number generator using the NIST Statistical Test Suite (STS). Appendix F of PCI’s guide: “PCI Mobile Payments on COTS Security and Test Requirement, Version 1.0.1”, contains guidance for using this tool.
Example
A payment software vendor considers Bouncy Castle FIPS Java API as one of the candidates of the libraries to be used to generate random number generators. The vendor verifies that the library is FIPS 140-2 validated and its Deterministic Random Bit Generator (DRBG) is included in the validation. The vendor then verifies that the operational environments (in which the library’s function is invoked) are aligned with one described in the library’s security policy.
The payment software vendor plans to have its payment software validated for multiple execution platforms (via PCI SSS). However, one of them is not aligned with the operation environment in the library’s security policy. Therefore, the vendor employs the NIST STS using the samples of random numbers generated by the library on this execution platform to verify that it generates sufficient unpredictability and entropy.
Conclusion
PCI SSS is more rigorous than PCI PA-DSS. The requirements discussed in this article are one example of the level of rigour required to comply with PCI SSS, a common issue faced by our clients.
Payment software vendors should plan their product carefully and engage with their PCI assessor as soon as they design and architect their product to avoid common (and sometimes costly) pitfalls. Sekuro’s team of PCI Assessors offers expert help in understanding and implementing the security requirements defined in the PCI SSS, PCI SSLC, and PCI PA-DSS.
Contact us to learn how Sekuro can help you with your compliance needs.

Gunawan Ang
PCI SSF Assessor, Sekuro