Android Protected Confirmation: Confirm and sign messages displayed on a Trusted User Interface

Motivation

Building trust in the online environment is key to economic and social development is stated in the EU Regulation on electronic identification and trust services for electronic transactions in the internal market - eIDAS. Android Protected Confirmation (APC) could contribute to that in an important way.

Android Protected Confirmation (APC) can be applied to a wide range of security critical operations such as “authentication”, “authentication with linking”, “transaction confirmation” (such as EMV «3DS confirmation»), “shareholder voting”, “medical device steering”, “access un-locking”, “electronic signing” and many more

APC provides a market-ready high security solution for Trusted Confirmation as an easy-to-use common API – preferable available on all Android devices.

Meeting Regulatory Requirements

Payment Card Industry Security Standards Council – POS Terminal

POS (Point Of Sales) terminals are subject to regulatory requirements that are designed to protect consumers and ensure that payment transactions are safe and secure. They must comply with PCI DSS (Payment Card Industry Data Security Standard), which is a set of security standards that aim to protect cardholder data. Compliance with PCI DSS ensures that payment transactions are processed securely and that customer data is protected.

In 2018 the PCI SSC (Payment Card Industry Security Standards Council) has introduced payment standards for smartphones, including the Secure PIN on COTS (Components Of The Shelf) and Contactless Payments on COTS. Its latest version is 1.0.1 was published in January 2023.

The standard states as follows [2]:

The MPoC Application that resides on the COTS:

• collects and passes attestation data about any attached hardware systems (such as a PCI PTS SCRP or non-PTS approved MSR), COTS platform, and MPoC Application to the attestation and monitoring back-end systems.
• contains software protection mechanisms to maintain its own integrity against attack.
• [contains] a secure UI for entry of account data entry methods (such as PIN, PAN, or security codes), and encryption of this data. (Optional)

APC (Android Protected Confirmation) fulfils the prerequisites of MPoC components considered in the PCI standard [3]:

Software that is designed and implemented as an entirely separate MPoC Application from a “calling application” executed in a completely separated execution environment (e.g. SE/TEE).
...
If the security mechanisms used by the MPoC SDK depend on an underlying system such as a TEE, SE, etc., there needs to be assurance on the security of the underlying system. Examples of certifications that may be acceptable, include, but are not limited to:

• Common Criteria (at EAL4 with AVA_VAN 5)
• Common Criteria with Global Platform TEE PP
• EMVCo Chip and Global Platform
• EMVCo SBMP for TEE
• PCI-PTS POI, PCI HSM
• FIPS 140-2/FIPS 140-3 (Level 3+)

The standard concludes [4]:

The proactive attestation of the platform is the key aspect of the security protection against the attacks that require rooting. Attestation of the platform that relays on hardware mechanisms within the platform (e.g., TEE, Secure processors) usually provide a significant barrier for an attacker.

ISO 9564-1:2017 «Financial Services - PIN Management and Security» requires more or less a class 4 reader [5]:

5.1 PIN handling device security requirements

A PIN handling device is a device that handles clear text PINs, e.g. PIN entry device, IC reader and host security module (HSM), etc. Any additional functionality provided by the device or the system into which it is integrated shall not impair the security of the device or the PIN entry process. A PIN handling device, other than an ICC, shall be an SCD meeting the requirements of ISO 13491-1. The security requirements for ICC are specified in 7.3.

A PIN entry device shall not rely on tamper evidence as its sole physical security characteristic.

The PIN entry device shall include tamper-detection and response mechanisms which, if attacked, cause the PED to become immediately inoperable and result in the automatic and immediate erasure of any secret information that might be stored in the PED, such that it becomes infeasible to recover the secret information.

The PIN entry device should be able to authenticate itself to the acquirer such that, once compromised, it is no longer able to authenticate itself to the acquirer. An example method to support this requirement is where Message Authentication Codes (MAC) are calculated over online transaction messages and the MAC key is erased if the PIN entry device is attacked.

NOTE Systems supporting online PIN verification typically meet this requirement in that the acquirer authenticates the validity of the PIN entry device each time a PIN is processed. (The authentication of the PIN entry device is implicit in the usage of the PIN encryption key.)

The display used to prompt a cardholder to enter their PIN shall be controlled such that modification and/or improper use of the prompts is not feasible (see ISO 13491-2:2017, Table B.1 number B2 and Table B.3 number B22).

The card reader shall be protected to prevent unauthorized access, substitution or alteration of the card data read from the card (see ISO 13491-2:2017, Table B.1 number B3 and Table B.3 number B28).

The Annex B of ISO 13491-2:2023 «Financial Services – Secure Cryptographic Devices» provides a checklist for devices with PIN entry funktionality [6]:

Table B1 number B2

If the PIN entry device can be used to enter data that will not be enciphered, then the path to the display is physically protected or the requirements of B22 are met.

Table B2 number B22

Where the keypad is used for PIN entry as well as other data, the display is under the control of the device such that an “enter PIN” or an equivalent message cannot be displayed when data will be output in the clear or the requirements of B2 are met.

Revised Payment Services Directive (PSD2)

APC can fulfil the requirement for strong customer authentication (SCA) with dynamic linking according Article 97 of directive 2015/2366 of the EU on payment services in the internal market [7]) in an exemplary manner.

Dynamic linking is further specified in Article 5 of the supplementing Directive (EU) 2015/2366 of the European Parliament and of the Council with regard to regulatory technical standards for strong customer authentication and common and secure open standards of communication [8]; Article 4 specifies the Authentication Code to be confirmed.

The factors for SCA are pinpointed in document Opinion of the European Banking Authority on the elements of strong customer authentication under PSD2 [9].

To mitigate risk, article 9 of the supplementing directive 2015/2366 suggests «the use of separated secure execution environments through the software installed inside the multi-purpose device» - a generic term for the TEE.

APC with signing keys which require biometric authentication can literally be seen as model solution for SCA with dynamic linking.

APC is to our knowledge the only technology available on COTS combining a Trusted Confirmation on a “Trusted UI” in a TEE environment with hardware backed keys – all fully attested. It leverages and combines the full power of the TEE security components to a single API available on the REE. APC reaches a security level which is compliant with the Payment Card Industry Data Security Standard and as such provides a strong security solution also for various other payment and non-payment use cases.

eIDAS (electronic IDentification, Authentication and trust Services)

eIDAS is an EU regulation on electronic identification and trust services for electronic transactions in the European Single Market.

Chapter 4.3.2 "Trusted environments" of the European Digital Identity Architecture and Reference Framework [10] explicitly states:

Certain computations require an additional level of trust, which may not be provided by standard software execution environments. In those cases, the EUDI Wallet may rely on a Trusted Execution Environment (TEE) and Secure Elements (SE) locally or a remote equivalent or similar technology depending on the device to execute those computations. Identifying means to enforce a common standard to access a TEE or SE in the EUDI Wallet will be defined as it will provide higher level of trust to the whole implementation.

---