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

The 3DS SDK provides functionality to conduct device security checks (at a minimum, during initialization) and makes the results of those checks available to the 3DS Requestor App upon request as warning messages. Device security checks include, at minimum, determining whether:

Assessment Procedures:
T.1.1.1 The tester shall examine vendor materials and other evidence to determine what features are provided by the 3DS SDK to provide security checks of the operating environment, and how any issues are escalated to the 3DS Requestor App. From this review, the tester shall determine what APIs are provided by the 3DS SDK for these purposes, the functions that are performed (and how often), and what error/warning messages are returned by the 3DS SDK. At a minimum, the SDK shall perform the checks upon initialization.
T.1.1.2 Based on the information provided in T.1.1.1, the tester shall examine vendor evidence, including source code, to determine what methods are used to perform the environment validation, and what they are designed to detect. These checks must include the below, at a minimum:

T.1.1.3 The tester shall also determine the platforms, operating systems, and specific versions of these supported by the 3DS SDK.
T.1.1.4 The tester shall test the 3DS SDK by attempting to execute the 3DS SDK on phones that have been rooted or

jailbroken, and observe the response of the SDK to confirm that the 3DS SDK detects that the phone has been rooted or jailbroken. This test must include use of devices from at least two different manufacturers where the 3DS SDK or operating system supports it.
T.1.1.5 The tester shall test the 3DS SDK by attempting to execute the 3DS SDK within an environment where raised privileges have been attained (i.e., the system has been rooted or jailbroken) with at least two readily available rooting or jailbreaking tools to confirm that the 3DS SDK detects such elevated privileges.
T.1.1.6 The tester shall test the 3DS SDK by attempting to execute the SDK within at least two different emulators and observe the response of the 3DS SDK to confirm that the 3DS SDK detects when an emulator is being used to run the 3DS SDK.
T.1.1.7 The tester shall test the 3DS SDK by attempting to modify the 3DS SDK (for example: by modifying initialization files, runtime files, or cryptographic keys) and then execute this modified version to confirm the 3DS SDK detects when its code or execution has been tampered with. The modification must be specifically designed to attempt to bypass the integrity checking of the 3DS SDK.
T.1.1.8 The tester shall test the 3DS SDK by attempting to execute the 3DS SDK in a system that allows for advanced control or insight into the execution of applications⎯e.g., such as running it in debug or developer mode to confirm the 3DS SDK detects this behavior.
Guidance:
The purpose of device security checks is to collect potential indicators of device compromise and make that information available to the ACS to allow the issuer to make risk-based decisions on how to proceed with the 3DS transaction. The security checks are performed during the initialization of the 3DS SDK and the results are passed to the ACS via the 3DS Requestor App along with other device - specific information. For more information on the interactions between the 3DS SDK, the Requestor App, and the ACS, refer to the EMV® 3-D Secure SDK Specification. Possible indicators of compromise include the existence of specific executables or other residual files and artifacts created during the

rooting or jailbreaking process. Reflection can be used on Android and iOS to calculate a checksum on the 3DS SDK.