Design of an Android App2App redirect flow for the FAPI 2.0 standard

Abstract

OAuth 2.0 Authorization Framework (OAuth 2.0) is an authorization framework used to grant third parties access to resources. OpenID Financial-grade API 2.0 (FAPI 2.0) is a profile for OAuth 2.0 with the goal to reach the security requirements of the financial sector. These requirements contain for example the assumption that an access token might leak to an attacker and that some endpoints are misconfigured due to social engineering attacks. We present a design proposal for a redirect flow for FAPI 2.0 between two Android applications, the client and the auth app. A typical case of usage would be a financial wallet application, the client, that redirects the user to a banking app, the auth app, in order to authorize a financial transaction. Our main goal is to securely redirect the user between the client and the auth app using today's technologies. We require integrity, confidentiality, source authentication and target authentication when redirecting the user. Roughly speaking, this means that the user is redirected from the correct source app to the correct target app and that no attacker is able to read or write the sent data. The secure redirect is achieved by mutually authenticating the intent receiver and sender as well as by using a result callback. Authentication is based on comparing package signing certificates. The motivation for a secured redirect is to mitigate attacks as soon as possible as a defense-in-depth. The secured redirect can not only be applied to OAuth 2.0 but can be used to secure other scenarios. Our proposal further defines the registration process for clients and auth apps. Considering this, we present the OAuth Integrity Attestation which ensures that only the correct applications running on an untampered device can register and that generated keys are hardware-backed. The OAuth Integrity Attestation contains e.g. a SafetyNet attestation and key attestations. Furthermore, we define the communication between the auth app and the corresponding backend, the authorization server, for interoperability, and security reasons. To show the feasibility of our proposal we implemented the advanced profile in the context of a digital wallet app and a banking app. A user is able to link his bank account and to authorize financial transactions. Additionally, we implemented a malicious app that attacks the user redirect. We discuss the security of our proposal with respect to our attacker model and list identified vulnerabilities. Our attacker model is based on the attacker model defined by FAPI 2.0 and extended by multiple assumptions and attacker capabilities. The additional attacker capabilities include e.g. that the client uses a misconfigured auth app and that the auth app might have some misconfigured endpoints. The motivation for these attacker capabilities are social engineering attacks. We also mitigate known problems with FAPI 1.0 that also apply to FAPI 2.0. One of the identified vulnerabilities is that a physical attacker with knowledge of the device credentials can access the same resources which a client has access to.

OAuth 2.0 Authorization Framework (OAuth 2.0) ist ein Authorizierungs-Framework, das dazu verwendet wird, um Dritten Zugriff auf Resourcen zu geben. OpenID Financial-grade API 2.0 (FAPI 2.0) ist ein Profil für OAuth 2.0 mit dem Ziel die Sicherheit zu gewährleisten, die im Finanzsektor gefordert ist. Zu den Anforderungen gehören zum Beispiel, dass Zugriffstoken in den Besitz eines Angreifers gelangen können und dass, aufgrund von Social Engineering Angriffen, falsche URLs verwendet werden. Wir päsentieren in dieser Arbeit unseren Vorschlag für FAPI 2.0, bei dem der Nutzer von einer Android Applikation, dem Klient, zu einer weiteren Android Applikation, der Auth App, weitergeleitet wird und wieder zurück. Unser Hauptziel ist es den Nutzer sicher weiterzuleiten. Das beinhaltet, dass der Nutzer von der korrekten Ursprungsapplikation zur korrekten Zielapplikation weitergeleitet wird und dass kein Angreifer den Inhalt ausgetauschter Information lesen oder ändern kann. Wir erreichen dieses Ziel, indem die Applikationen sich gegenseitig authentifizieren und ein Antwortchannel registriert wird. Eine Applikation kann authentifiziert werden, indem die Zertifikate überprüft werden, mit der die Applikation signiert wurde. Wir merken an, dass diese abgesicherte Weiterleitung auch in anderen Szenarien angewendet werden kann. Wir spezifizieren den Registrierungsprozess des Kleints und der Auth App und sichern diesen mithilfe der sogenannten OAuth Integrity Attestation ab. Diese stellt sicher, dass nur korrekte Applikationen auf einem nicht kompromitierten Gerät sich registrieren können. Darüber hinaus spezifizieren wir die Kommunikation zwischen der Auth App und dem zugehörigen Server. Wir implementieren unseren Vorschlag im Kontext einer Finanz-App und einer Bank-App. Ein Nutzer kann seinen Bankaccount verlinken und Überweisungen tätigen. Wir diskutieren die Sicherheit unseres Vorschlags im Hinblick auf unser Angreifer-Modell, das auf FAPI 2.0 basiert, und führen verschiedene Schwachstellen auf. Wir gehen zum Beispiel zusätzlich davon aus, dass der Client die falsche Auth App oder dass die Auth App falsche URLs verwendet. Eine der identifizierten Schwachstellen ist, dass ein Angreifer, der Kenntniss der Zugangsdaten zum Gerät hat, auf die gleichen Resourcen zugreifen kann wie auch der Client.