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 the EMVCo 3DS SDK Specification and in the 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, plus a few PCI requirement checks. 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 | Note |
|---|---|---|---|
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 | |
PCI1.2 | MEDIUM | The application was not installed from a trusted store | Only provided with ThreeDS2Service.getWarnings(), not included in the device data that is send to the ACS. Current trusted stores:
|
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 sent in the authentication response to the 3DS Server together with the other parameters.
Ensuring the security provider is up to date
To protect against known vulnerabilities (such as SSL exploits) found in the default Android security provider, the Netcetera Android 3DS SDK will try to update it during initialization.
In order for the Netcetera Android 3DS SDK to be able to perform this update, it requires the Google Play Services API. The least intrusive way to do this, is to include the Google Play Service Base library as a dependency.
Note: If the device does not have/support Google Play Services API, the Netcetera Android 3DS SDK will continue to function as intended without updating the security provider. In such case, the integrating app might be vulnerable.
Application resources integrity
All the sensitive resources that are included in the Netcetera 3DS SDK have protection to make sure that their integrity isn't compromised. However, protection of additional resources that integrating library or application may define, it is up to the integration to make sure that the those resources have appropriate integrity protection. For example, such additional resources may be certificates or keys that are defined for the Directory Server Configuration.
PCI 3-D Secure SDK Compliance
This section describes the PCI requirements that are met by the Netcetera Android 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 use, unless permitted to be kept | 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 | JS Code execution outside the SDK prevented | 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 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 warranted | As described in Security Objective 5 - Page 26 |