Payment Card Industry 3-D Secure (PCI 3DS)

T.1.3.1 The tester shall examine vendor materials and other evidence to confirm features are provided by the SDK to perform run-time integrity checks during execution, to verify that the security of the SDK cannot be compromised after the initialization phase by tampering with the execution code or parameters.

T.1.3.2 Where these checks implement the use of a hash function to validate the integrity of the 3DS SDK executable, the tester shall examine vendor materials and other evidence to confirm that the hash function meets PCI requirements of strong cryptography, including applicable cryptography requirements in this standard.

T.1.3.3 The tester shall confirm that these checks include tests to identify attacks that aim to perform interruption of code execution or flow, interception and modification of data elements as they are processed, or modification of responses from the SDK to the calling application.

T.1.3.4 The tester shall determine where data values are stored (even temporarily) outside of the 3DS SDK code itself, or the memory space of the 3DS SDK provided by the device operating system during execution⎯e.g., written to the device file system, stored in system functions such as a “key store,” etc.—and confirm that features or methods are applied to protect these values.

T.1.3.5 The tester shall determine where other code, data, script, or features of the application are not included in the integrity check, and confirm that having these features out of scope does not affect the security of the SDK or 3DS transaction process.

T.1.3.6 Based on the information provided in T.1.3.1 through T.1.3.5, the tester shall examine vendor materials and other evidence, including source code, to confirm that the claimed features are correctly implemented.

T.1.3.7 The tester shall test the 3DS SDK by attempting to modify the 3DS SDK prior to and during execution. Testing shall include attempts to modify the 3DS SDK code itself or values used by the code (for example, modifying configuration files, the runtime code, encryption keys, or keys or parameters stored temporarily in files or live memory during execution that could compromise the secure execution of the SDK.) The tester shall then observe the response of the 3DS SDK to confirm these modifications are detected. The changes must be made in such a way to attempt to avoid detection. Where the 3DS SDK code may be present in different locations (such as in the form of a pre-compiled file, as well as an ahead-of- time compilation that is ready to execute) the tester shall attempt to modify the 3DS SDK code in each location.

T.1.3.8 The tester shall test the 3DS SDK by attempting to execute the 3DS SDK within an execution environment that allows for dynamic modification⎯such as a system that implements a hooking framework, a virtual machine (VM), or a device running a customized operating system to allow for such attacks to confirm that such modification attempts are detected by the 3DS SDK.
Guidance:
Run-time integrity checks are intended to ensure that only authorized libraries are used, and rogue functions are not inserted, attached or executed at run-time. One method for performing run-time integrity checks may include using hooking detection techniques specific to the underlying operating system, software development framework or language. However, other methods could be used to achieve the same objective.