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 WarningSeverityDescriptionNote
SW01HIGHJailbroken device
SW02HIGHThe SDK has been tempered
SW03HIGHAn emulator is being used to run the app
SM04MEDIUMDebugger is attached
SW05HIGHUnsupported OS version
PCI1.2MEDIUMThe application was not installed from a trusted storeOnly provided with ThreeDS2Service.getWarnings(), not included in the device data that is send to the ACS.

Current trusted stores:
  • Google Play Store
  • Amazon Appstore
  • Galaxy Apps Store
  • HUAWEI AppGallery

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.

RequirementDescriptionReference
1.1 Security ChecksConduct several security checks of the Requestor environment and display warnings, including: Jailbreak detection, Emulator detection, 3DS SDK Integrity, Debugger detectionAs described in Security Objective 1 - Page 11
1.2 Installed from Approved SourceEnsure the Requestor App is installed from a trusted source (Platform Store)As described in Security Objective 1 - Page 12
1.3 Run-Time IntegrityChecks to detect when its functionality has been modifiedAs described in Security Objective 1 - Page 12
1.4 Protection against Reverse EngineeringProtection of reverse engineeringAs described in Security Objective 1 - Page 13
1.5 Protection of 3DS SDK Reference DataData is securely stored within the 3DS SDKAs described in Security Objective 1 - Page 13
2.1 Collection of Sensitive 3DS SDK Data ElementsOnly data that is essential for functionality is collected and retained for the necessary durationAs described in Security Objective 2 - Page 14
2.2 Clearing of Sensitive 3DS SDK Data ElementsAll sensitive data is removed after use, unless permitted to be keptAs described in Security Objective 2 - Page 15
2.3 Use of Third-Party ServicesThird party services are used only when documented and justifiedAs described in Security Objective 2 - Page 15
2.4 Protection against Disclosure through Unintended ChannelsSensitive data is not disclosed outside of the SDKAs described in Security Objective 2 - Page 16
2.5 Hardcoded 3DS SDK Data ElementSensitive data is not hardcoded in the SDKAs described in Security Objective 2 - Page 17
2.6 Run-Time Data ProtectionRun-time data protection against unauthorized third-party accessAs described in Security Objective 2 - Page 17
2.7 UI ProtectionThe UI is secured, and data from it cannot be accessed outside the SDKAs described in Security Objective 2 - Page 18
2.8 HTML RenderingAll requests are intercepted and are handled inside the SDKAs described in Security Objective 2 - Page 18
2.9 Prevention of External Code or Script ExecutionJS Code execution outside the SDK preventedAs described in Security Objective 2 - Page 19
3.1 Approved Algorithms and Modes of OperationOnly approved cryptographic algorithms and methods are usedAs described in Security Objective 3 - Page 20
3.2 Random Number Generator(s)Approved RNG algorithms or libraries are usedAs described in Security Objective 3 - Page 21
3.3 Random Number EntropyRandom numbers meet minimum effective security strengthAs described in Security Objective 3 - Page 21
4.1 Threat and Vulnerability AnalysisThreats, attack scenarios and/or attack vectors applicable are known and are documentedAs described in Security Objective 4 - Page 22
4.2 Development of Defensive StrategiesMechanisms to protect against attack vectors and/or scenarios are designed and implementedAs described in Security Objective 4 - Page 23
4.3 Software Security TestingCode is tested during it's life cycleAs described in Security Objective 4 - Page 23
4.4 Vulnerability Identification and MonitoringThe SDK is monitored for vulnerabilities and there exists an infrastructure to report such thingsAs described in Security Objective 4 - Page 24
4.5 Updates During Transaction ProcessingThe SDK will not update while processingAs described in Security Objective 4 - Page 24
5.1 Availability of Stakeholder GuidanceGuidance is made available and maintained to all stakeholdersAs described in Security Objective 5 - Page 25
5.2 Disclosure of Updates to StakeholdersStakeholders are updated and informed about changes made to the SDKAs described in Security Objective 5 - Page 25
5.3 Frequency of Updates to Stakeholder GuidanceUpdates are made to the SDK as warrantedAs described in Security Objective 5 - Page 26