Response to discussion on RTS on strong customer authentication and secure communication under PSD2

Go back

3. Do you consider that in the context of “inherence” elements, behaviour-based characteristics are appropriate to be used in the context of strong customer authentication? If so, can you specify under which conditions?

Behaviour-based characteristics may contribute evidence of authenticity, provided two conditions are met which must be common to all inherence tests. These are:

-no local processing on a programmable device: any such local processing must by necessity rely upon hardware and/or software which is available for and susceptible to reverse engineering and repeated experimentation. This combination will inevitably reveal to attackers the underlying data structures upon which authenticity decisions are based, exposing any regularities in the algorithms and enabling brute force, scaleable attacks. Behavioural-based authentication may also rely upon sensor inputs that are available to the platform operating system, and hence accessible to interception and copying by an attacker, permitting replay and forgery attacks.

-high complexity of data inputs: low-dimensional behavioural data feeds will further reduce the complexity of exploring the decision space, making it easier for attackers to create convincing forgeries.

4. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to the independence of the authentication elements used (e.g. for mobile devices)?

Any combination of tests that rely upon the integrity of the security of the user device does not deliver the independence required. The point made in para 32 of the Discussion Document is of crucial importance. History and analysis suggest it is overwhelmingly likely that exploits will be found in devices rendering them vulnerable, and such vulnerabilities will mean that no information or decisions taken on the device can be trusted. Furthermore, if there is no means for trusted monitoring such exploits will remain zero-day for an indefinite period. Thus for there to be true element independence, one of the elements must assume device compromise. This means that the test of authenticity for such an element must be impervious – to a very high degree of probability and on the presumption of sustained and expert attack – to interception and modification of all data outside of physically and logically secure, monitored and independently logged computing environments.

One way to accomplish this is to force the consumer to use multiple physical elements during authentication. However, primary regard must be given to the human usability of any solution, and such an approach is poor in this regard. There are many drawbacks arising from poor usability, not the least of which is its poor accessibility to aged or cognitively impaired citizens. Even the requirement to carry around a special physical item to demonstrate possession is poorly usable, in a future world in which the mobile phone replaces wallets and keys.

We conclude that in a mobile phone-dependent context the only viable way to deliver at least one element which is wholly independent of device integrity is to feed raw data from device sensors back to a network-based secure environment, the data containing so much natural redundancy and structure that neither modification nor forgery is feasible without leaving a detectable trace in the data.

5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?

Dynamic linking creates challenges in balancing security and usability, and it is vital that the RTS does not mandate approaches that are poorly usable. Two challenges arise – the certainty of disclosure, and the theft of the consent.

The correct and full disclosure of the transaction details – payee and amount – to the user is vital to ensure that they give informed consent. Hidden or amended disclosures can con the user into giving authenticated consent to a fraudulent transaction.

The biggest challenges to correct disclosure arise from the use by the citizen of programmable devices such as mobile smartphones, in which the risk is that any means to present a user interface has been subverted by attackers. Malware substituting or amending out of band communications is already a proven means to corrupt disclosure transmitted by this means. If disclosure is executed in-band via an app or a web page, scaleable attacks are much more difficult to mount and harder to scale, as they require the user to install a bogus app masquerading as a genuine payment provider app. A degree of vulnerability to such attacks may be structurally acceptable in order to deliver reasonable usability. If this judgement is not made, then it is necessary to revert to solutions based on active challenge and response, involving the citizen using a secondary device. This can have a severely negative impact on usability, which must be a priority in all considerations.

If the user interface is trusted, then dynamic linking is required to ensure prevent theft of consent. This can be readily accomplished by means of a transaction-specific token exchanged securely between the payment service provider and an authentication service provider whose authentication decision is taken in a secure environment and who can therefore securely associate an instance of an authenticated consent with such a token. Providing that the authentication process involves a disclosure and some form of active user consent action, relying parties can then infer from a secure authentication that consent was given to that transaction.

6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?

iProov Verifier is an example of a class of solution that meets the conditions today. Verifier is a system of strong authentication based on a group of inherence characteristics, face verification primary amongst them, backed up by possession of a mobile device. iProov Verifier assumes that the device has been completely compromised, and transmits unprocessed video imagery back to its secure servers. It has a unique, patented method of detecting forgeries and replays, using the device screen to flash with a unique time-dependent sequence of colours. The illumination of the user’s face is part of the image which is transmitted, and the reflected light is analysed in the network servers to confirm that a real, live human face is present, at the time of the consent request. Each authentication is signed with a unique, transaction-linked token generated by the payment service provider, whose validity is verified by a network-only, trusted exchange between iProov and payment service provider. Thus as long as the transaction disclosure was shown to the user, the consent is both authenticated and protected, independently of any device tampering. The additional factor of possession is verified by means of a device identity and signature, but iProov considers these vulnerable to device compromise, and therefore consider it to be a relatively weak corroboration.

10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?

It is essential that the EBA distinguishes between different elements of the user’s personalised credentials. The Account Identifier, which pay be issued by the PIS/AIS, is used by the citizen to assert ownership of an account. It is desirable that this should be protected, but not essential to the integrity of the system. Associated with this is a means of authenticating this Account Identity. This may be knowledge or possession, in which case protection against theft is extremely important. Or it may be inherence, in which case protection is not credibly, durably possible – all biometrics may eventually be compromised and some, such as faces, are often published by the users. So for inherence, protection of the user credential actually resolves to protection against forged copies of the credential, or replays of the presentation of real credentials. This approach simplifies the security model greatly, since there are many possible points at which to steal inherence credentials, and the assumption that they have been copied clarifies the key choices any standard must make. It shifts the focus, from preventing the theft of such credentials, to denying their use. Such an approach must be recognised by the reference architecture used for the RTS, as it has a number of major benefits in usability. Notably, it relaxes most requirements for hardware specificity or certification within the mobile phone, and removes any need for users to carry around dedicated hardware.

The EBA’s proposed clarification may therefore in some circumstances be excessive, insofar as the user device need not in general meet the requirements of para 52(ii) in the case of network-processed inherence credentials. However, the enrolment process, which is a special case addressed by para 52(i) is a sensitive phase – but this sensitivity is, in the case of online-only relationships, bound up with related problems of KYC and AML checks on the real identity of the user.

11. What other risks with regard to the protection of users’ personalised security credentials do you identify?

A complementary way to address the risks outlined in para 51 is to mitigate the consequences of compromise of the data. As expressed elsewhere in this response, one such strategy for mitigation is to use inherence characteristics with effective methods to distinguish between genuine human characteristics and forgeries or replays created by the means outlined in para 51. Any analysis of risk or system performance against the threats of para 51 must take account of such mitigation.

12. Have you identified innovative solutions for the enrolment process that the EBA should consider which guarantee the confidentiality, integrity and secure transmission (e.g. physical or electronic delivery) of the users’ personalised security credentials?

We believe that the correct approach is to use secure linkage to graduate from an initial enrolment to a repeat authentication method. Whilst the method used to establish trust initially may be complex and demanding for the user, involving some element of KYC or AML with reference to secure network databases of independent data, this should not be perpetuated into the repeat transaction context. Instead, the initial trust relationship should be used to establish a linkage to an equally secure but much easier to use process, which will serve for authentication in future. Its security must be such that it permits the payment service provider to infer the same level of trust as was established in the initial, complex enrolment process. Inherence is a good way to accomplish this latter process, but more complex enrolment processes may be necessary to ensure that an impostor does not enrol their biometrics in place of the genuine user.

14. Can you indicate the segment of the payment chain in which risks to the confidentiality, integrity of users’ personalised security credentials are most likely to occur at present and in the foreseeable future?

We believe that storage and authentication of personal biometric credentials on a user’s device, if it is network-connected, is the single largest source of long-term risk in the chain. The ability of an attacker to run experiments, reverse-engineer authentication methods and discover exploits, without the AIS/PIS or their Authentication Service Provider ever being aware of or able to fully bserve this activity, may be a recipe for irresolvable zero-day exploits that will present an unacceptable systemic risk.

We also believe that the confirmation of trust in the user that occurs between an authentication service provider and a payment institution should require an independent, network-only linkage between the payment institution and the credential authenticator. The alternative method, in which such communication occurs exclusively via the user device and secured by cryptographic methods alone is sustainable but potentially risky.

Name of organisation

iProov Limited

Please select which category best describes you and/or your organisation.

[IT services provider"]"

Please select which category best describes you and/or your organisation.

[Other "]"

If you selected ‘Other’, please provide details

Authentication Service Provider