9

According to PSD2 the elements of the multi-factor authentication must be independent so the compromise of one element does not compromise the other.

Here is the article from the directive:

*Article 9

Independence of the elements,

  1. Payment service providers shall ensure that the use of the elements of strong customer authentication referred to in Articles 6, 7 and 8 shall be subject to measures in terms of technology, algorithms and parameters, which ensure that the breach of one of the elements does not compromise the reliability of the other elements.
  2. Where any of the elements of strong customer authentication or the authentication code is used through a multi-purpose device including mobile phones and tablets, payment service providers shall adopt security measures to mitigate the risk resulting from the multi-purpose device being compromised.
  3. 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 or mechanisms to mitigate the consequences of such alteration where this has taken place.*

The question is what could be considered independent in this case?

Let's imagine the following scenario:

The customer uses his/her phone's browser to access the online banking website. Password and another element (based on possession) is required for authentication.

In case the second factor is a one-time-password sent via SMS to the phone, a single malware is enough to compromise the phone, install a keylogger to steal the password, and steal the SMS as it arrives.

Based on this OTP via SMS is a no go.

Now let's suppose the SMS OTP is replaced by a push notification (the customer should install the Bank's mobile application previously). There are few possibilities for the exact implementation:

  • an OTP is sent via push

  • a approval window pops up and the user needs to tap on the approve button (just as Google does it)

  • a CAPTCHA pops up and the user needs to solve it

  • OTP generation with soft token

  • etc.

In case of any of the above mentioned solutions, if the attacker could exploit a vulnerability in the phone's OS and gain root permission, he is able to steal the customers password and validate the transaction with the second authentication factor at least theoretically (by installing some kind of remote access tool).

Hard tokens are a no go as well because of user experience reasons.

Could the separate sandbox which is used by both Android and iOS considered as a secure execution environment which would meet the following part of the directive?

The use of separated secure execution environments through the software installed inside the multi-purpose device

What could be an effective solution which meets the regulation and is also convenient for the customer?

1 Answer 1

4

tl;dr; Nobody can say for sure and this is highly debatable

Little history: there was a change from "trusted execution environment" to "secure execution environment". It is documented here: https://www.eba.europa.eu/documents/10180/1761863/Final+draft+RTS+on+SCA+and+CSC+under+PSD2+(EBA-RTS-2017-02).pdf

Most of the industry (that I know of) agrees that this implies hardware based TEE is not a requirement. There are some reasons provided in that document:

Article 6(2) (now Article 9(2)) does not refer to segregation, only Article 2.2.b does. See comments [10] and [11] on that. The EBA has therefore not made any changes to the Article. However, in relation to comment i), the EBA agrees that PSPs can mitigate only the risks within their realm of competence. The EBA has made changes to Article 6(3) (now Article 9(3)) to specify that the focus is on the software used by the PSP rather than the hardware itself.

EBA refused multiple requests to be more specific on how to achieve execution environments separation. From this we can understand that you should care only about proper software implementation, but what does that mean? Lets dig deeper.

There is this older document with some less vague language: https://www.eba.europa.eu/documents/10180/1548183/Consultation+Paper+on+draft+RTS+on+SCA+and+CSC+%28EBA-CP-2016-11%29.pdf

  1. Furthermore, the authentication procedure should ensure the confidentiality, authenticity and integrity of the information displayed to the payer through all phases of the authentication procedure including generation, transmission and use of the authentication code. To that end, the channel, device or mobile application where the information about the amount and the payee of the transaction is displayed should be independent or segregated from the channel, device or mobile application used for initiating the payment. This can be done, for example, via an independent channel to prevent any manipulation of the transaction details through the initiation process of the payment transaction.

Considering all this, I'm of the opinion, that using platform sandbox is a completely compliant solution. It might be not safest one though. It's all makes sense when talking about mobile platforms, web environment is even more confusing, because it doesn't have any sandbox.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .