Browsing by Author "Stötzner, Miles"

Now showing 1 - 3 of 3

Open Access
Design of an Android App2App redirect flow for the FAPI 2.0 standard
(2020) Stötzner, Miles
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.
Open Access
Modeling different deployment variants of a composite application in a single declarative deployment model
(2022) Stötzner, Miles; Becker, Steffen; Breitenbücher, Uwe; Képes, Kálmán; Leymann, Frank
For automating the deployment of composite applications, typically, declarative deployment models are used. Depending on the context, the deployment of an application has to fulfill different requirements, such as costs and elasticity. As a consequence, one and the same application, i.e., its components, and their dependencies, often need to be deployed in different variants. If each different variant of a deployment is described using an individual deployment model, it quickly results in a large number of models, which are error prone to maintain. Deployment technologies, such as Terraform or Ansible, support conditional components and dependencies which allow modeling different deployment variants of a composite application in a single deployment model. However, there are deployment technologies, such as TOSCA and Docker Compose, which do not support such conditional elements. To address this, we extend the Essential Deployment Metamodel (EDMM) by conditional components and dependencies. EDMM is a declarative deployment model which can be mapped to several deployment technologies including Terraform, Ansible, TOSCA, and Docker Compose. Preprocessing such an extended model, i.e., conditional elements are evaluated and either preserved or removed, generates an EDMM conform model. As a result, conditional elements can be integrated on top of existing deployment technologies that are unaware of such concepts. We evaluate this by implementing a preprocessor for TOSCA, called OpenTOSCA Vintner, which employs the open-source TOSCA orchestrators xOpera and Unfurl to execute the generated TOSCA conform models.
Open Access
Über die (Un-)Sicherheit des W3C-WebAuthentication-Entwurfs: Eine Beschreibung und Sicherheitsanalyse
(2018) Stötzner, Miles
Viele Dienste im Internet authentifizieren ihre Nutzer aufgrund der Benutzerfreundlichkeit durch ein Passwort. Dieses Passwort kann leicht von einem Angreifer in Erfahrung gebracht werden. Eine Lösung für dieses Problem ist der Einsatz mehrerer Faktoren. WebAuthentication (WebAuthn) ist ein Entwurf eines Standards, der auf eine benutzerfreundliche Weise einem Nutzer ermöglicht, sich bei einer Relying Party mithilfe eines asymmetrischen Schlüsselpaares durch das Signieren einer von der Relying Party generierten Nonce, die sogenannte Challenge, unter Einsatz von mehreren Faktoren passwortlos zu registrieren und authentifizieren. Während einer Registrierung oder Authentifizierung ist jeweils eine Relying Party, ein WebAuthn Client und ein Authenticator beteiligt. Der Authenticator ist für das Generieren des asymmetrischen Schlüsselpaares und für das Bereitstellen von Signaturen zuständig. Dabei muss jede Aktion von dem Nutzer autorisiert werden. Der WebAuthn Client befindet sich zwischen der Relying Party und dem Authenticator und ist für die Authentifizierung der Relying Party zuständig, sodass keine Aktion im Namen einer anderen Relying Party durchgeführt werden kann. Hierfür wird ein sicherer Kontext benötigt - d.h. die Verbindung ist über HTTPS gesichert. Während einer Registrierung wird ein asymmetrisches Schlüsselpaar generiert, dessen öffentlicher Schlüssel bei der Relying Party hinterlegt wird. Indem eine Signatur über die Challenge mit dem zugehörigen privaten Schlüssel generiert wird, kann sich ein Nutzer daraufhin authentifizieren. Teil dieser Arbeit ist eine Implementierung einer Relying Party, die WebAuthn für die Authentifizierung ihrer Nutzer verwendet. Hierfür betrachten wir neben der Implementierung eines Severs die Verwendung der WebAuthentication API. In einer informellen Sicherheitsanalyse untersuchen wir die Sicherheit des Protokolls, indem wir aufführen, wieso die während einer Registrierung bzw. Authentifizierung durchzuführenden Überprüfungen der einzelnen Parteien notwendig sind und welche Auswirkungen das Verwenden verschiedener Optionen von WebAuthn hat. Des Weiteren untersuchen wir die Kommunikationskanäle im Hinblick auf einen Man-in-the-Middle (MitM) und welche Gefahr von diesem ausgeht. Während der Sicherheitsanalyse betrachten wir einen Angriff auf das Authentifizierungsverfahren und widerlegen die in der Spezifikation aufgeführte Behauptung, dass WebAuthn während einer Registrierung resistent gegenüber einem MitM sei, der den sicheren Kontext ignorieren kann. Beide Probleme wurden von den Autoren der Spezifikation anerkannt. Für den Angriff auf das Authentifizierungsverfahren wurde bereits eine Lösung gefunden. Wir diskutieren, wieso das Authentifizierungsverfahren (nach Beheben unseres Angriffes) unter bestimmten Annahmen sicher ist und verweisen auf Probleme bezüglich der Privatsphäre und der für eine Registrierung oder Authentifizierung notwendige Zustimmung eines Nutzers. Zu den Annahmen zählen, dass der WebAuthn Client und Authenticator des Nutzers sowie die Relying Party sich konform verhalten, dass die Verbindung zwischen WebAuthn Client und Authentictor sicher ist und dass während der Registrierung kein erfolgreicher Angriff stattgefunden hat.