Secure Execution Environments
One of the most interesting new developments with the PSD2 in the last couple of years is that the regulatory authorities are now apparently more open to single-device solutions. This is made clear in article 9 of the RTS.
Article 9: Independence of the elements
- Payment service providers shall ensure that the use of the elements of strong customer authentication referred to in Articles 6, 7 and 8 is subject to measures which ensure that, in terms of technology, algorithms and parameters, the breach of one of the elements does not compromise the reliability of the other elements.
- Payment service providers shall adopt security measures, where any of the elements of strong customer authentication or the authentication code itself is used through a multi-purpose device, to mitigate the risk which would result from that multi-purpose device being compromised.
- For the purposes of paragraph 2, the mitigating measures shall include each of the following:
(a) the use of separated secure execution environments through the software installed inside the multi-purpose device;
(b) mechanisms to ensure that the software or device has not been altered by the payer or by a third party;
(c) where alterations have taken place, mechanisms to mitigate the consequences thereof.
Technology, algorithms, and parameters
At a glance, the first paragraph does not appear to be new. It is a basic rule of computer security that breaking one security factor should not compromise the reliability of other factors. But, the paragraph is actually about “technology, algorithms and parameters”, so a practical interpretation is that “if the security of your networking protocol is broken it should not break the security of the PIN entered by the user”. This is a much stricter requirement than simply requiring that a knowledge break does not impact possession.
With Okay we mitigate this by adding a second layer of security to the user input, using a PKI encryption, making this sensitive information not known to the Okay server. This means that even if the security of our data center is broken, it will not allow any access to the users’ inputs, this information can only be decrypted by our customers.
In the second paragraph, there is an acknowledgment that any kind of multi-purpose device can be compromised. With Okay we are able to take this a bit further.
In our opinion, we should make the assumption that any device is already compromised, and if it is not yet, it can easily be. The vast majority of devices are running out-of-date operating systems, with many known security vulnerabilities, some of which can even be deployed with the attacker only knowing your phone number.
There are also simple ways for attackers to gain “root” access to devices, making it possible to read and change executed code and data shown on the device. This does not trigger “jailbreak detection” of the device, as this type of detection only checks for common software installed by jailbreaking solutions.
Secure execution environment
Fundamentally, the RTS requires payment service providers to take mobile malware seriously.
In the next paragraph, the required mitigation mechanisms are listed:
A separate secure execution environment through software
Integrity tests of the software and the device
Mitigation mechanisms if any of the first two requirements have been broken
With Okay we provide a highly secure execution environment, which can even provide unique environments for each individual transaction verification. This is far safer than what is provided by other solutions, where the secure execution environment is at best unique to the software release. This makes it much harder for an attacker to make an attack on your app. It is also important to note that the execution environment should be separate, which means that simply running obfuscation software on your app before release is not enough.
The secure Okay execution environment can be provided through a separate app, or even as a library that can be included with your existing app with our SDK. As the environment is downloaded just-in-time it is sufficient to claim that it provides a separate environment.
Integrity tests are also fundamental to protecting against malware. We do a lot of these, to the extent that we even analyze that the device is not being remotely controlled by comparing the movement of the device (e.g. accelerometer readings) with user input.
It is important to note that if there is a security breach, we leave the decision regarding what should be done to the PSP requiring security. Note that informing the end-user that there has been a security breach will give important information to the attacker. It is much better if this is handled on the back-end so that an attacker has no clue as to when the security breach was detected.