Wie unterscheidet sich der Schutz der FAPI 1.0 Profile?

FAPI verstehen #03: Wie unterscheidet sich der Schutz der FAPI 1.0 Profile?
FAPI #03 Banner

FAPI verstehen – Blogserie – Teil #03

Die FAPI wurde entwickelt, um OAuth und OpenID Connect auch in sensiblen Bereichen mit einem hohen Sicherheitsanspruch, wie zum Beispiel im Finanzsektor oder im e-Health Kontext, sicher einsetzen zu können. Die verschiedenen Profile der FAPI 1.0 bieten unterschiedliche Sicherheitslevel, welche je nach Kontext optimal eingesetzt werden können.

Die FAPI 1.0 schützt Access Tokens vor Diebstahl und Protokoll-Nachrichten vor Manipulationen auf eine Weise, die mit den Regulierungen übereinstimmt und die Interoperabilität ermöglicht. Die vollständige Absicherung eines OAuth/OpenID Connect Protokoll-Flows gelingt durch Einschränkung von Client-Typen, Protokoll-Flows und Client-Authentifizierungsmethoden sowie durch verpflichtende Sicherheitserweiterungen. Dazu gehören signierte Authorization Requests und Responses (JAR, PAR, JARM), absender-beschränkte Access Tokens (mTLS) und CSRF-Schutz (state, nonce, PCKE).

In diesem dritten Teil der Blogserie “FAPI verstehen” erfahren Sie, in welchen Eigenschaften sich die Profile der FAPI 1.0 unterscheiden und welche Auswirkungen diese auf das erreichte Sicherheitslevel haben.
Eine Gemeinsamkeit der FAPI Profile ist es, dass sie eine sichere und effiziente Alternative zur weit verbreiteten Technik des “Screen Scrapings” bieten. Das Sicherheitsproblem beim Einsatz der  “Screen Scraping”-Technik wurde in Teil #01 der Blogserie erläutert.
Einen ersten Überblick über die FAPI mit ihren verschiedenen Profilen, sowie deren Sicherheitsziele und einen Vergleich mit OAuth und OpenID Connect finden Sie in Teil #02 der Blogserie.

 

Rückblick: Was ist die FAPI?

Die FAPI bietet verschiedene Sicherheitsprofile für OAuth und OpenID Connect. Diese können als interoperable Lösung für Open-Banking-Szenarien dienen. 
Die FAPI wurde als Reaktion auf die europäische Payment Service Directive 2 (PSD2) entwickelt, die 2015 veröffentlicht wurde. Trotz ihres Ursprungs im Finanzbereich sind die FAPI Profile auch in anderen Hochsicherheits-Szenarien, wie im Kontext von e-Health-Lösungen, einsetzbar. 
Die FAPI zielt darauf ab, dem hohen Bedarf an Cyber Sicherheit und großen Maß an regulatorischen Vorschriften im Finanzbereich gerecht zu werden. Dazu definiert sie die drei Sicherheitsziele: Autorisierung, Authentifizierung und die Integrität der Session.

 

Wie unterscheiden sich die verschiedenen FAPI-Profile?

Die FAPI 1.0 besteht aus drei Profilen: dem FAPI 1.0 Baseline Profile, dem FAPI 1.0 Advanced Profile und dem FAPI-CIBA Profile.
Die FAPI 2.0 befindet sich zur Zeit noch in der Entwicklung. Aktuell beinhaltet die FAPI 2.0 ein Security Profile und das FAPI 2.0 Message Singing Addon. Zusätzlich gibt es ein Attackermodel, das beschreibt, welche Fähigkeiten potenzielle angreifende Personen haben könnten und gegen die die FAPI schützen soll. Auf der Basis dieses Modells wird momentan an den FAPI 2.0 Drafts gearbeitet. Dabei soll die FAPI 2.0 mehr Sicherheit und mehr Interoperabilität bieten als die Vorgängerin. Eine detaillierte Untersuchung der Unterschiede von FAPI 2.0 zu FAPI 1.0 werden Sie in einem zukünftigen Blogpost finden.

Welchen Schutz bietet das FAPI 1.0 Baseline Profile?

Das FAPI 1.0 Baseline Profile zielt darauf ab, APIs mit einem mittleren Risiko zu schützen.
Dazu werden diverse Sicherheitsmaßnahmen eingesetzt.
Kernelemente des Baseline Profiles beinhalten die Pflicht zur sicheren Authentifizierung von Confidential Clients durch den Authorization Server, Vorgaben für die Handhabung von Redirect URIs für Authorization Server und Clients, Richtlinien zum Einsatz starker Kryptographie und TLS, sowie Vorgaben zur Gültigkeit von Authorization Codes und Tokens und den vorgeschriebenen Einsatz von bestimmten OAuth und OpenID Connect Erweiterungen.

Konkret schreibt das FAPI 1.0 Baseline Profile folgende Maßnahmen vor:

Schutz von Access Tokens

  • Replay-Angriffe auf Authorization Codes müssen verhindert werden (siehe Punkt 13 in FAPI 1.0 Baseline).
  • Access Tokens sollten nur eine Gültigkeit von maximal 10 Minuten haben, wenn diese nicht sender-beschränkt sind (siehe Punkt 21 in FAPI 1.0 Baseline).
  • Authorization Server und Clients müssen die Proof Key of Code Exchange (PKCE) Erweiterung mit der Code Challenge Method S256 (siehe Punkt 7 in FAPI 1.0 Baseline) unterstützen.

CSRF-Schutz

  • Verwendet der Client OpenID Connect, muss der nonce Parameter verwendet werden. Verwendet der Client nur OAuth, muss stattdessen der state Parameter eingesetzt werden (siehe Punkt 8 und 9 in FAPI 1.0 Baseline).

Aktuelle Security Best Practices

  • Redirect URIs müssen vorab registriert sein und im Authorization Request durch den Client mitgesendet werden. Der Authorization Server muss die mitgesendete URI mit der Registrierten URI vergleichen und den Request bei Ungleichheit ablehnen (siehe Punkt 8 - 10 in FAPI 1.0 Baseline).
  • Sowohl Public, als auch Confidential Clients müssen für jeden unterstützten Authorization Server eine separate Redirect URI verwenden (siehe Punkt 3 in FAPI 1.0 Baseline). Sie müssen ebenfalls ihre verwendete Redirect URI mit der URI vergleichen, über welche sie die Authorization Response erhalten haben und den Prozess bei Ungleichheit terminieren (siehe Punkt 4 in FAPI 1.0 Baseline). (Warum diese Maßnahme nicht ausreicht, um einen Client effektiv gegen “Mix-Up”-Angriffe zu schützen und welche Gegenmaßnahme stattdessen verwendet werden sollte, haben wir in diesem Blogpost erläutert: How to Protect Your OAuth Client Against Mix-Up Attacks)

Kryptographie

  • Symmetrische Client Secrets und Schlüssel für RSA- oder ECC-Algorithmen müssen festgelegte Mindestlängen erfüllen (siehe Punkt 3, 5, und 6 in FAPI 1.0 Baseline).
  • Für TLS werden klare Vorgaben definiert (siehe FAPI 1.0 Baseline). Neben der Einhaltung der TLS Best Practices, muss TLS Version 1.2 oder neuer verwendet werden, sowie ein Check des TLS-Serverzertifikats durchgeführt werden.

Weitere Maßnahmen:

  • Confidential Clients müssen mithilfe von mutual TLS (mTLS) oder einer der Methoden client_secret_jwt und private_key_jwt authentifiziert werden (siehe Punkt 3 in FAPI 1.0 Baseline).
  • Die sichere Kommunikation mit dem End-User muss gewährleistet werden, indem der End-User authentifiziert wird, der Grant dem End-User präzise dargestellt wird und die explizite Zustimmung eingeholt wird (siehe Punkt 11, 12 und 17 in FAPI 1.0 Baseline).
  • Es dürfen nur Access Tokens, Authorization Codes und Refresh Tokens mit ausreichender Entropie ausgestellt werden (siehe Punkt 16 in FAPI 1.0 Baseline).
    Die Kommunikation zwischen Client und Resource Server muss Vorgaben zur Absicherung erfüllen (siehe FAPI 1.0 Baseline).

Wie funktioniert das FAPI 1.0 Advanced Profile?

Das FAPI 1.0 Advanced Profile hat das Ziel, APIs zu schützen, die einem hohen Risiko ausgesetzt sind.
Hierfür wird die Sicherheit des Baseline Profiles weiter durch die folgenden zusätzlichen Vorschriften verstärkt:

Schutz von Access Tokens

  • Der Authorization Server darf nur absender-beschränkte Access Tokens ausstellen. Dies muss mittels mutual TLS (mTLS) umgesetzt werden (siehe Punkt 5 und 6 in FAPI 1.0 Advanced).

Manipulations­schutz von Requests

Manipulations­schutz von Responses

  • Das Advanced Profil schreibt die Verwendung des Code Flows mit dem Response Mode jwt oder des Hybrid Flows mit dem Response Type code id_token vor (siehe Punkt 2 in FAPI 1.0 Advanced).
  • Im Code Flow muss die JWT-Secured Authorization Responses (JARM) Erweiterung verwendet werden, um die Authorization Responses zu signieren und so vor Manipulationen zu schützen (siehe FAPI 1.0 Advanced).
  • Im Hybrid Flow muss das ID Token, welches den s_hash beinhalten muss, als losgelöste Signatur in der Authorization Response verwendet werden (siehe FAPI 1.0 Advanced).

Kryptographie

  • Die Richtlinien bezüglich der Absicherung von TLS-Verbindungen sowie starker Kryptografie werden verschärft, u. a. durch die Verwendung von Elliptischen Kurven. Das Profil schreibt erlaubte Cipher Suites vor und definiert, welche Algorithmen verwendet werden dürfen (siehe Abschnitt 8.5 und 8.6 in FAPI 1.0 Advanced). 

Weitere Maßnahmen:

  • Im Gegensatz zum Baseline Profil sind Public Clients verboten (siehe Punkt 16 in FAPI 1.0 Advanced).

Zur Client-Authentifizierung werden nur noch die Methoden private_key_jwt oder mit mTLS tls_client_auth und self_signed_tls_client_auth unterstützt. Die Methode client_secret_jwt ist anders als im Baseline Profile nicht mehr erlaubt (siehe Punkt 14 in FAPI 1.0 Advanced).

CIBA Profile

Der Client-Initiated Backchannel Authentication (CIBA) Flow stellt eine Erweiterung für OpenID Connect dar. CIBA kann in Szenarien verwendet werden, in denen der Client den Authentifizierungsprozess initiieren muss. Ein Beispiel dafür ist die Autorisierung einer Zahlung an einem "Point of Sale"-Terminal in einem Ladengeschäft. In diesem Fall wird die Zustimmung des Benutzers auf einem Authentication Device (z. B. Smartphone oder Smartwatch) erteilt, während der Kunde den Vorgang auf einem Consumption Device (z. B. dem Terminal) initiiert.
Die FAPI 1.0 stellt einen Draft für ein CIBA Profile zur Verfügung (Änderungen bis zur Finalisierung sind nicht auszuschließen). Dieses Profil stellt eine Konfiguration des CIBA Flows für höchste Sicherheitsanforderungen dar. Neben der Einhaltung der Richtlinien des Baseline und Advanced Profiles, wird der CIBA Poll Mode stark empfohlen. Dieser gilt als sicherster der drei CIBA Modi, da der Client hierbei den Authorization Server so lange anfragt, bis er ein Token erhält. In den anderen Modi sendet der Authorization Server eine Benachrichtigung (“Ping Mode”) oder sogar das Token direkt (“Push Mode”) an den Client. Der Push Mode wird in dem CIBA Profile gänzlich verboten.
Zudem schreibt das Profil die Unterstützung diverser Security Best Practices vor.

 

Fazit

Abschließend lässt sich sagen, dass der Schutz der beiden FAPI Profile essentielle Unterschiede aufweist. Das FAPI Advanced Profile bietet ein höheres Sicherheitsniveau als das FAPI Baseline Profile.  Der Grundschutz des Baseline Profiles wird durch den Einsatz verschiedener OAuth und OpenID Connect Best Practices, Vorschriften zu TLS und eingesetzter Kryptographie, sowie der Implementierung von PKCE, gewährleistet. Dieser Grundschutz wird durch das Advanced Profil verstärkt und erweitert. Dazu werden verschiedene Sicherheitserweiterungen wie JAR, JARM, PAR und mTLS verwendet. Mithilfe dieser Erweiterungen können Nachrichten signiert und absender-beschränkte Access Tokens umgesetzt werden. Das CIBA Profile gewährleistet, dass das hohe Sicherheitsniveau der FAPI Profile auch in speziellen Szenarien, in denen der CIBA Flow zum Einsatz kommt, gewährleistet werden kann.

 

 

Mit welchen Maßnahmen die FAPI Profile das hohe Niveau des Finanzsektors an Cybersicherheit erreichen, und sogar gegen komplexe Mix-Up Angriffe schützen, werden wir Ihnen in weiteren Teilen der “FAPI verstehen”-Serie erläutern.

Demnächst > FAPI verstehen Teil #04: Wie unterscheidet sich FAPI 1.0 von FAPI 2.0?

Folgen Sie uns auf Twitter und verpassen Sie keinen unserer zukünftigen Blogposts mehr.

 

Blogserie – FAPI verstehen – Alle Beiträge im Überblick

Teil #01 – Wie werden mit der FAPI im Finanzsektor hochsichere APIs realisiert?

Teil #02 – Was steckt hinter der FAPI – ein Überblick

Teil #03 – Wie unterscheidet sich der Schutz der FAPI 1.0 Profile?

Teil #04 – Wie unterscheidet sich FAPI 2.0 von FAPI 1.0?

 

 

Unsere Experten entwickeln die optimale Lösung für Sie

APIs – OAuth – FAPI

Stehen Sie vor der Entscheidung, wie Sie Ihre APIs und Kundendaten optimal schützen können? Oder verwenden Sie OAuth bereits und fragen sich, ob Ihre Implementierung sicher ist?

Wir beraten Sie gerne; kontaktieren Sie uns für eine unverbindliche Erstberatung. So stehen wir Ihnen mit folgenden Services und Lösungen zur Seite:

IT-Sicherheitsberatung  |  Schulungen   |  Penetrationstests

Zögern Sie nicht und finden Sie mit uns Ihren Weg zu sicheren APIs. Wir freuen uns darauf Sie bei Ihren Projekten zu unterstützen.

 

Ihr Ansprechpartner für OAuth und sichere API

Dr. Christian Mainka
christian.mainka@hackmanit.de