"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:

1. The use of separated secure execution environments through the software installed inside the multi-purpose device
2. Mechanisms to ensure that the software or device has not been altered by the payer or by a third party
3. Where alterations have taken place, mechanisms to mitigate the consequences thereof”

At a glance, the first paragraph does not appear to be new. It is a basic rule of computer security, the one where breaking a security factor should not compromise the reliability of other factors.

But the paragraph is actually about “technology, algorithms and parameters”. So a more 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. We do this by using a PKI encryption, making sensitive information not known to the Okay server. This means that even if the security of our data centre 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.

We choose to act under the assumption that any device is already compromised. Or if it is not yet already, 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.

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 analyse 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.