Security Features

This section is about the security aspects concerning the SDK integration.

The SDK implements a number of security functions that are defined in more detail in EMVCo 3DS SDK Specification and in PCI 3DS SDK Security Standard.

Security Warnings

During SDK initialization, the SDK performs a number of security checks as specified by the EMVCo 3DS SDK Specification. These checks may result in warnings that are handed over to the 3DS Requestor App. The Requestor App decides how to act upon these warnings and whether to proceed executing the transaction.

Security Warning Severity Description
SW01 HIGH Jailbroken device
SW02 HIGH The SDK has been tempered
SW03 HIGH An emulator is being used to run the app
SM04 MEDIUM Debugger is attached
SW05 HIGH Unsupported OS version

After the initialization, in order to retrieve the warnings, call ThreeDS2Service.getWarnings(). It is up to the implementor to act on the warnings, the SDK continues to operate regularly.

Secure communication

The SDK uses several cryptographic methods to secure the communication and the transfer of data.

The device data collected during the initialization of the SDK is being sent to the 3DS Server and to DS, which then forwards it to the ACS. In order to secure the data transmission, the SDK encrypts the data with the DS public key in JWE format. The encrypted data can be retrieved by invoking AuthenticationRequestParameters.getDeviceData().

After the DS receives the encrypted data, it decrypts it and sends it to the ACS. Using data transferred in the Authentication, the 3DS SDK and ACS exchange the keys according to the Diffie-Hellman protocol, with that establishing the secure channel that is used for the message flows during the Challenge Flow.

The ephemeral key used for the key exchange is generated by the SDK. This key can be retrieved in JWK format by invoking AuthenticationRequestParameters.getSDKEphemeralPublicKey(). It should be send in the authentication response to the 3DS Server together with the other parameters.

PCI 3-D Secure SDK Compliance

This section describes the PCI requirements that are met by the Netcetera iOS 3DS SDK.

Requirement Description Reference
1.1 Security Checks Conduct several security checks of the Requestor environment and display warnings, including: Jailbreak detection, Emulator detection, 3DS SDK Integrity, Debugger detection As described in Security Objective 1 - Page 11
1.2 Installed from Approved Source Ensure the Requestor App is installed from a trusted source (Platform Store) As described in Security Objective 1 - Page 12
1.3 Run-Time Integrity Checks to detect when its functionality has been modified As described in Security Objective 1 - Page 12
1.4 Protection against Reverse Engineering Protection of reverse engineering As described in Security Objective 1 - Page 13
1.5 Protection of 3DS SDK Reference Data Data is securely stored within the 3DS SDK As described in Security Objective 1 - Page 13
2.1 Collection of Sensitive 3DS SDK Data Elements Only data that is essential for functionality is collected and retained for the necessary duration As described in Security Objective 2 - Page 14
2.2 Clearing of Sensitive 3DS SDK Data Elements All sensitive data is removed after needed used, unless permitted As described in Security Objective 2 - Page 15
2.3 Use of Third-Party Services Third party services are used only when documented and justified As described in Security Objective 2 - Page 15
2.4 Protection against Disclosure through Unintended Channels Sensitive data is not disclosed outside of the SDK As described in Security Objective 2 - Page 16
2.5 Hardcoded 3DS SDK Data Element Sensitive data is not hardcoded in the SDK As described in Security Objective 2 - Page 17
2.6 Run-Time Data Protection Run-time data protection against unauthorized third-party access As described in Security Objective 2 - Page 17
2.7 UI Protection The UI is secured, and data from it cannot be accessed outside the SDK As described in Security Objective 2 - Page 18
2.8 HTML Rendering All requests are intercepted and are handled inside the SDK As described in Security Objective 2 - Page 18
2.9 Prevention of External Code or Script Execution Prevent JS Code execution outside the SDK As described in Security Objective 2 - Page 19
3.1 Approved Algorithms and Modes of Operation Only approved cryptographic algorithms and methods are used As described in Security Objective 3 - Page 20
3.2 Random Number Generator(s) Approved RNG algorithms or libraries are used As described in Security Objective 3 - Page 21
3.3 Random Number Entropy Random numbers meet minimum effective security strength As described in Security Objective 3 - Page 21
4.1 Threat and Vulnerability Analysis Threats, attack scenarios and/or attack vectors applicable are known and are documented As described in Security Objective 4 - Page 22
4.2 Development of Defensive Strategies Mechanisms are implemented to protect against attack vectors and/or scenarios are designed and implemented As described in Security Objective 4 - Page 23
4.3 Software Security Testing Code is tested during it’s life cycle As described in Security Objective 4 - Page 23
4.4 Vulnerability Identification and Monitoring The SDK is monitored for vulnerabilities and there exists an infrastructure to report such things As described in Security Objective 4 - Page 24
4.5 Updates During Transaction Processing The SDK will not update while processing As described in Security Objective 4 - Page 24
5.1 Availability of Stakeholder Guidance Guidance is made available and maintained to all stakeholders As described in Security Objective 5 - Page 25
5.2 Disclosure of Updates to Stakeholders Stakeholders are updated and informed about changes made to the SDK As described in Security Objective 5 - Page 25
5.3 Frequency of Updates to Stakeholder Guidance Updates are made to the SDK as changes as warrant updates As described in Security Objective 5 - Page 26