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

The 3DS SDK collects and retains only the sensitive 3DS SDK data elements absolutely necessary for the software to perform its intended purpose and functionality, and only for the duration necessary.
Assessment Procedures:
T.2.1.1 The tester shall examine vendor materials and other evidence to determine all sensitive 3DS SDK data elements used or required by the 3DS SDK Vendor evidence should account for the name of the data element collected, the duration for which the data element is retained, how the data element is stored (e.g., in memory only, in the OS file system, in an OS storage mechanism such as a key store, in a device mechanism such as a Trusted Execution Environment, etc.), and how the data element is securely deleted after storage.
T.2.1.2 The tester shall examine vendor evidence and other materials, including source code, to determine the functionality provided by the 3DS SDK and confirm that the functionality contained within the 3DS SDK correctly aligns with the vendor materials and evidence supplied and assessed in T.2.1.1.
T.2.1.3 Given the output of T.2.1.1 and T.2.1.2, the tester shall reference Table 2, “Sensitive 3DS SDK Data Elements,” to confirm that the list of sensitive 3DS SDK data elements identified in T.2.1.1 is exhaustive and correct given the functionality of the 3DS SDK under evaluation. Where sensitive 3DS SDK data elements are collected that are not required for the attested functionality, the tester shall note this as a non-compliance.
T.2.1.4 For each sensitive 3DS SDK data element identified in T.2.1.1, the tester shall determine whether the element is retained, and confirm that all sensitive 3DS SDK data elements that are retained are allowed to be retained, as noted in Table 2, “Sensitive 3DS SDK Data Elements.”

T.2.1.5 The tester shall test the 3DS SDK by performing a series of 3DS operations, ensuring that these cover all functionality provided by the 3DS SDK, to confirm that all sensitive 3DS SDK data elements used by the 3DS SDK correctly and completely align with the sensitive 3DS SDK data elements identified in T.2.1.1.

T.2.1.6 The tester shall test the 3DS SDK by performing a series of 3DS operations to determine how the sensitive 3DS SDK data elements are stored and retained, and confirm that the use and retention of sensitive 3DS SDK data elements correctly and completely aligns with the details provided in T.2.1.1.

Note: This testing may be achieved through operation of the 3DS SDK in a virtualized environment that allows for monitoring the memory and storage of the system during processing, through the use of tools to monitor the data elements during operation on a physical device, or other means that will allow for confirmation of the use the memory and storage space of the 3DS SDK operating environment. It is also noted that this testing may require assistance from the 3DS SDK Vendor to disable protections in the software that would otherwise prevent the use of these types of tools.
Guidance:
To ensure that the 3DS SDK does not disclose sensitive 3DS SDK data elements to unauthorized parties, the 3DS SDK should only collect the sensitive 3DS SDK data elements absolutely necessary to perform its expected functionality. Collecting sensitive 3DS SDK data elements that do not directly support the functionality of the 3DS SDK presents the opportunity for the information to be overlooked, mishandled, or otherwise insufficiently protected.

Sensitive 3DS SDK data elements collected by the 3DS SDK in association with 3DS transactions are securely deleted after 3DS transaction processing is complete and never retained, unless retention is explicitly permitted.
Assessment Procedures:
T.2.2.1 Referencing the information produced in T.2.1.1, the tester shall examine vendor materials and other evidence, including source code, to confirm that each of the sensitive 3DS SDK data elements is securely deleted after use and that the methods used ensures that each sensitive 3DS SDK data element is rendered irretrievable to any subsequent process, component, functions, or applications after secure deletion.

T.2.2.2 Where secure deletion is prevented by the nature of the 3DS SDK operating environment (e.g., through virtualized memory and garbage-collection processes), the tester shall examine vendor materials and other evidence to confirm that additional protections have been implemented beyond secure deletion of the data element, and that such protections are sufficient to be considered equal to industry best practice.

T.2.2.3 Where additional protections or secure deletion methods are required to be implemented to compensate for lack of direct memory access in the 3DS SDK operating platform, the tester shall confirm that these methods are covered by the reverse- engineering protections tested under Requirement 1.4, “Protection against Reverse Engineering,” and that any cryptography used is covered under the testing of Requirement 3.1, “Approved Algorithms and Modes of Operation.”
T.2.2.4 The tester shall test the 3DS SDK by performing a series of 3DS operations, ensuring that these cover all functionality provided by the 3DS SDK to confirm that each of the sensitive 3DS SDK data elements covered in T.2.1.1 is rendered irretrievable in accordance with the methods identified in T.2.2.1 through T.2.2.3.

Note: This testing must be performed against a 3DS test host/harness that provides all required 3DS functionality and data elements, and allows for the monitoring of traffic to the 3DS SDK. This testing may also require assistance from the 3DS SDK Vendor to disable protections in the software that would otherwise prevent the use of these types of tools.
Guidance:
Sensitive 3DS SDK data elements collected in conjunction with 3DS transactions should only be retained for as long as required to complete that transaction. After 3DS transaction processing is complete, any and all locations where the sensitive 3DS SDK data elements have been retained should be securely wiped or overwritten, or the sensitive 3DS SDK data elements rendered irretrievable such that any subsequent process, component, function, application, entity, etc., within the environment may not capture the information. Only in circumstances where the retention of specific sensitive 3DS SDK data elements is explicitly permitted should they be retained after 3DS transaction processing is complete. Refer to Table 2, “Sensitive 3DS SDK Data Elements,”in the “Scope of Security Requirements” section for more information.

T.2.3.2 Referring to the information produced in T.2.1.1, the tester shall examine vendor materials and other evidence, including source code, to determine all sensitive 3DS SDK data elements that are passed to third-party components or services.

Note: Validation of this requirement must also consider whether the 3DS SDK has any advertising, machine learning, data collection, logging, tracking, or security features which rely on third-party components, features, or external services. This list of items is to be considered a minimum set and is not considered exhaustive of all potential third-party features which must be considered under this requirement.
T.2.3.3 Where third-party services are used, interfaced with, or operated by the 3DS SDK, the tester shall examine vendor materials and other evidence to confirm the vendor provides reasonable and documented justifications for the use of each third- party system or components and that the vendor maintains processes for addressing vulnerabilities in those systems or components in accordance with Requirement 4.4, “Vulnerability Identification and Monitoring.”

T.2.3.4 The tester shall test the 3DS SDK by performing a series of 3DS operations, ensuring that these cover all functionality provided by the 3DS SDK, to determine how any third-party components or services are utilized during this operation and which data elements are sent to third parties. The tester shall confirm this correctly and completely aligns with the vendor materials and evidence provided in T.2.3.1 and T.2.3.2.

Note: This testing must be performed against a 3DS test host/harness that provides all required 3DS functionality and data elements, and allows for the monitoring of traffic to the 3DS SDK. This testing may also be achieved through operation of the 3DS SDK in a virtualized environment that allows for monitoring the memory and storage of the system during processing, through the use of tools to monitor the data elements during operation on a physical device, or other means that will allow for confirmation of the use of third-party components and services. It is noted that this testing may require assistance from the 3DS SDK Vendor to disable protections in the software that would otherwise prevent the use of these types of tools.
T.2.3.5 The tester shall test the 3DS SDK by performing a series of 3DS operations, ensuring that these cover all functionality provided by the 3DS SDK, and observe the traffic output from and received by the 3DS SDK to determine whether any of this traffic is external or extraneous to the 3DS test host to which the SDK is communicating, whether any sensitive 3DS SDK data elements are communicated through these channels, and if so, confirm that they correctly and completely align with the information provided in T.2.3.2.

T.2.3.6 The tester shall determine the functionality provided by the 3DS SDK during testing and confirm that this correctly and completely aligns with the information provided in T.2.3.1 to T.2.3.4.

T.2.3.7 The tester shall examine vendor materials and other evidence to confirm that use of third-party services is only implemented where this is a reasonably justified and documented part of the 3DS SDK architecture.
Guidance:
The use of third-party services or components should be carefully controlled and justified. Control over sensitive information may no longer reside with the 3DS SDK Vendor once sensitive information is shared or made accessible to third-party services or components, and 3DS SDK Vendors should consider the ramifications of third-party misuse or disclosure of such information.

The 3DS SDK does not disclose sensitive 3DS SDK data elements through unintended channels.
Assessment Procedures:
T.2.4.1 Referring to the information produced in T.2.1.1, the tester shall examine vendor materials and other evidence, including source code, to determine how each of the data elements is generated/input and displayed (if displayed).

T.2.4.2 Referring to the information produced in T.2.1.1 and the details generated above, the tester shall confirm that for each sensitive 3DS SDK data element identified in T.2.1.1, the vendor has implemented protections to safeguard that data element against disclosure through unintended channels.

T.2.4.3 Where the sensitive 3DS SDK data element is input by the cardholder, the tester shall confirm that methods are implemented by the 3DS SDK to mitigate clickjacking, screen overlay, or other such input-stealing attacks.

T.2.4.4 For all sensitive 3DS SDK data elements identified in T.2.1.1, the tester shall confirm that methods are implemented by the 3DS SDK to mitigate capture of each of these elements through use of shared resources such as memory or file systems.

T.2.4.5 Referring to testing performed in Requirement 2.3, “Use of Third-Party Services,” the tester shall confirm that methods are implemented to mitigate the capture or exposure of each sensitive 3DS SDK data element as it is passed between the 3DS SDK and any third-party services or components.

T.2.4.6 Referring to the information produced in T.2.1.1, the tester shall examine vendor materials and other evidence, including source code, to confirm that only sensitive 3DS SDK data elements that are explicitly permitted to be hard-coded are stored in the source code.
T.2.4.7 The tester shall examine source code to determine whether sensitive 3DS SDK data elements which are externally generated or provided are processed in a way that indicates they are static⎯for example, where they utilize a third-party service or component, covered under Requirement 2.3, “Use of Third-Party Services,” which implements static values; or where the 3DS SDK processing clearly does not accommodate for the expected range of values which may be provided in any particular data element. In such cases, the tester shall confirm that these values are not static, and that any such attestations from the vendor are documented.

T.2.4.8 The tester shall examine vendor materials and other evidence, including source code, to identify all error, debugging, or other output functionality. Where such functionality is found, the tester shall confirm that the functionality does not result in the unintended disclosure or leakage of any sensitive 3DS SDK data elements.

T.2.4.9 The tester shall examine vendor materials and other evidence, including source code, to confirm that any functionality that results in the output of sensitive 3DS SDK data elements is intended. The tester is expected to cross reference any output functionality to the testing performed in Requirement 2.3, “Use of Third-Party Services,” to validate that all communication of sensitive 3DS SDK data elements is intended.
T.2.4.10 The tester shall test the 3DS SDK by performing a series of 3DS operations, ensuring that these cover all functionality provided by the 3DS SDK, and confirm that sensitive 3DS SDK data elements are not disclosed through unintended channels.

T.2.4.10.1 The tester shall test the 3DS SDK by attempting to capture or otherwise determine the values of sensitive 3DS SDK data elements generated, input, or processed by the 3DS SDK. The tester must attempt methods that include both on-device capture, as well as capture through monitoring of communication channels. Communication channel capture shall consider the application of traffic analysis to determine the sensitive 3DS SDK data elements communicated.

T.2.4.10.2 The tester shall attempt to capture or otherwise determine the values of sensitive 3DS SDK data elements generated, input, or processed by the 3DS SDK through capture and analysis of error codes or use of debugging/test features. The tester must attempt methods that utilize both normal and forced error flows of the processing, and determine whether any sensitive 3DS SDK data elements are leaked.
Guidance:
Proactive measures to ensure that sensitive 3DS SDK data elements are not inadvertently “leaked” should be implemented by the 3DS SDK Vendor or within the 3DS SDK. Disclosure of sensitive 3DS SDK data elements to unauthorized parties often occurs via unknown or unintended outputs or channels. For example, sensitive 3DS SDK data elements could be unintentionally disclosed through error- or exception-handling routines, logging or debugging channels, third-party services or components, or the use of shared resources such as memory, disk, files, keyboards, displays, and functions. Protective mechanisms, whether process or programmatic in nature, should be implemented to ensure that sensitive 3DS SDK data elements are not accidentally disclosed through such means. Example implementations of data leakage protection controls can be found in the EMV® 3DS SDK Technical Guide.

Sensitive 3DS SDK data elements are not hard-coded in 3DS SDK code unless explicitly permitted.
Assessment Procedures:
T.2.5.1 Referring to testing performed in Requirement 2.4, “Protection against Disclosure through Unintended Channels,” the tester shall confirm that sensitive 3DS SDK data elements are not hardcoded in the 3DS SDK except where the vendor has maintained reasonable and documented justification for their use.

T.2.5.2 The tester shall test the 3DS SDK by performing a series of 3DS operations, ensuring that these cover all functionality provided by the 3DS SDK, and observe the use of sensitive 3DS SDK data elements across multiple operations and executions of the 3DS SDK. Where sensitive 3DS SDK data elements appear to have the same value or a limited range of values, the tester shall confirm that these values correctly and completely align with those values noted in T.2.5.1.

Note: This testing must be performed against a 3DS test host/harness that has been confirmed to provide all required 3DS functionality and data elements.
Guidance:
The 3DS SDK, as part of its normal functionality, will be exposed to and handle various sensitive 3DS data elements. For example, the directoryServerIDs public keys will be issued after certification and stored by the 3DS SDK. It is fairly trivial to reverse-engineer mobile applications (for example, using dex2jar or JAD) and perform analysis on the source code itself with intent to harvest hard-coded sensitive information. To prevent that, the 3DS SDK should not store any sensitive 3DS SDK data elements in the source code unless explicitly permitted. Instead⎯in the case of cryptographic keys, for example⎯the 3DS SDK could fetch the data from an HSM, then store the keys locally utilizing the most secure storage options (for example, keychain, key store, or shared preferences) provided by the operating system where appropriate. Refer to Table 2, “Sensitive 3DS SDK Data Elements,” in the “Scope of Security Requirements” section for more information on which sensitive 3DS SDK data elements are permitted to be retained.

The 3DS SDK implements run-time data protection techniques to protect the 3DS SDK instance from being accessed by unauthorized third-party applications and/or libraries.
Assessment Procedures:
T.2.6.1 Referencing the sensitive 3DS SDK data elements identified in T.2.1.1 and the protection features determined through other testing, the tester shall confirm that protections against extraction or determination are provided for each sensitive 3DS SDK data element.
T.2.6.2 The tester shall examine vendor materials and other evidence, including source code, and test the 3DS SDK to determine what sensitive 3DS SDK data elements may be most susceptible to side-channel attacks, such as cache timing or other attack methods, and to confirm that such attacks are not feasible given the implemented protections.

T.2.6.3 The tester shall examine vendor materials and other evidence, including source code, and test the software to determine what sensitive 3DS SDK data elements may be most susceptible to exposure through code injection or code reuse attacks, and to confirm such attacks are not feasible given implemented protections.

T.2.6.4 The tester shall examine vendor materials and other evidence, including source code, and test the 3DS SDK to determine what sensitive 3DS SDK data elements may be most susceptible to exposure through hooking methods (remote and local) and reverse-engineering attacks, and to confirm that such attacks are not feasible given other protections.

T.2.6.5 The tester shall test the 3DS SDK by attempting to subvert any third-party components or services relied upon by the 3DS SDK to determine whether any sensitive 3DS SDK data elements are used by the 3DS SDK that are not already confirmed to be passed to that third-party component or service as per testing under Requirement 2.3, “Use of Third-Party Services”. Where third-party components or services are known to receive sensitive 3DS SDK data elements, the tester shall attempt to extract the sensitive values from these services during operation of the 3DS SDK to confirm the sensitive 3DS SDK data elements are not exposed to extraction or determination through code injection, code reuse, reverse engineering, and the use of hooking (remote or local) methods.
Guidance:
Code injection, code reuse, local and remote hooks, reverse-engineering attacks and side-channel attacks (for example, cache side-channel or timing attack) are often used to execute code in the context of target process or to extract sensitive information from the target systems and applications. Various defense techniques exist to make attacks significantly harder, including dynamic or artificial software diversity, compression and randomization, etc. Properly implemented runtime application self-protection (RASP) and/or anti-debugging or anti-hooking techniques may be used to satisfy this requirement.

The 3DS SDK intercepts all external URL requests made by the HTML UI rendered (both during loading of the UI and on user action) and handles these requests within the 3DS SDK. Such requests are not passed to the device’s operating system or the Internet.
Assessment Procedures:
T.2.8.1 The tester shall examine vendor materials and other evidence, including source code, and the findings in T.2.7.1 to confirm that URL requests made by the UI in HTML mode are handled within the 3DS SDK itself and are not passed to the device’s operating system or any other component (internal or external).

T.2.8.2 The tester shall examine vendor materials and other evidence, including source code, to determine what web elements the 3DS SDK is configured to handle, and to confirm that these methods are created and used in a way that mitigates attacks and prevents references to external content that is not supplied by the Access Control Server (ACS).
T.2.8.3 Using the information determined in T.2.8.2, the tester shall test the 3DS SDK by attempting to inject HTML references in ACS response(s), and observe the operation of the 3DS SDK to confirm that the UI processes running in HTML mode are handled by the 3DS SDK and are not passed to the device operating system or other component(s)(internal or external).

Note: This testing must be performed with a test host/harness that allows for such injection.
Guidance:
When the 3DS SDK makes API calls to the ACS that are rendered in HTML mode, those calls, as well as the responses, should not be available outside the 3DS SDK. HTML content generated by the ACS and displayed in HTML mode by the 3DS SDK should not reference content from other external sites. The intent of this requirement is to reduce the 3DS SDK’s attack profile and to protect against the inadvertent leakage of sensitive 3DS SDK data elements to unauthorized parties.