DSP2 standards, sécurité, quels impacts wavestone

Directive Services de Paiement 2

Standards, sécurité, quels impacts?

Matinée du 25 avril 2017

Bertrand [email protected]

@bertrandcarlier

confidentiel | © WAVESTONE 2confidentiel | © WAVESTONE 2

API or DIE

Report from the Economist Intelligence Unit

””

By 2020 bankers expect more money will flow via fintech firmsthan traditional retail banks

confidentiel | © WAVESTONE 3

Que requiert la DSP2?

La DSP2 (Directive sur les Services de Paiement) définit 3 services :

Informations de compte▪ Cas d’usage : agrégateur multi-bancaire▪ Acteurs : AISP (Account Information Service

Provider)

Initiation de paiement▪ Cas d’usage : initiation d’un paiement par un tiers▪ Acteurs : PISP (Payment Initiation Service Provider)

Demande de couverture d’un paiement

▪ Cas d’usage : demande OK/NOK de couverture d’un paiement

▪ Acteurs : PIISP (institutions bancaires)

Requiert une authentification multi-facteur du client final

L’accès aux services DSP2 de la part d’un acteur requiert l’enregistrement auprès d’une Autorité d’Enregistrement en plus d’un enregistrement auprès de l’AS PSP


Quels standards d’échange ?

Quels outils ?

01


/ Les standards techniques sontconnus et matures : HTTP,REST, JSON, OAuth2, OpenIDConnect…

/ …mais il n’existe aucunstandard d’API bancaire quifasse référence

/ La DSP2 – et les guidesd’implémentation (RTS) publiéspar l’EBA – sont contraignantsmais ne constituent pas unespécification

SE CONFORMER

Quels standards adopter ?

Standards Open Banking


Adopter un standard simplifie le travail dedéfinition des APIs nécessaires

/ Une consolidation de standards dans defutures versions n’est pas à exclure

Intégrer un groupe de travail destandardisation est un moyen d’enrichirsa réflexion et de ne pas simplementsubir

/ Les principaux acteurs bancaires françaiss’intéressent aux travaux de STET

Définir seul son propre standardd’interface est sans doute la seule optionà ne pas suivre!

Standards et solution sont intimement liésSE CONFORMER

Le marché est encore jeune, constituéd’acteurs de taille modeste

/ Majoritairement mono-standard

/ Vulnérables à des acquisitions externes

Par ailleurs, des questions de stratégie sont àévaluer :

/ Build vs Buy

/ On-premises vs SaaS

/ Couverture DSP2 tactique ou OpenAPIstratégique


Quelle sécurité pour les APIs ?


Quels outils ?

01

02


AS PSP

Client

Authorizationserver

API

Tous types de consommateurs- app mobile, serveur, objet

connecté, etc.- maîtrisé ou tierce partie (AISP,

PISP)

OAuth2.0

/ Un standard mature

/ Adapté aux principaux cas d’usage

Des compléments de spécifications àutiliser le cas échéant

/ Contrôle fin sur l’authentification

/ SSO entre applications mobiles

/ Appels chaînés d’APIs & impersonnation

/ Protection contre le vol de jeton

/ etc.

La sécurité des APIs – Les basesS’ADAPTER

Access token


Des besoins spécifiques dans le cadre de la DSP2S’ADAPTER

Authentification contextuelle Protection contre le vol de jeton

Ajustement du niveau d’authentification en fonction de la sensibilité

de l’API consommée

Rendre inopérant le vol d’un jeton de sécurité et

ne pas dépendre de la sécurité d’un terminal non

maîtrisé ou d’un tiers

Les exigences de la DSP2 en matière d’authentification & d’ouverture des données entraînent un besoin plus pointu encore










S’ADAPTER

Authentification contextuelle : le besoin

Opération très sensible

Authentification forte / transactionAjout de bénéficiaire

Opération sensible

Authentification simple / sessionVirement interne

Données personnelles

Authentification simple / 1 semaineMétéo des comptes

Notifications personnelles

Authentification simple / 1 mois

Notification

Le niveau d’authentification dépend

/ De la nature de la transaction

/ De ses caractéristiques (montant, compte cible, etc.)

/ Du contexte utilisateur

/ Des habitudes utilisateurs

/ etc.


Authentification contextuelle : la solutionS’ADAPTER

/ Les standards sont écrits dans cette logique initiée par le client

/ Les solutions du marché fonctionnent comme ça

/ Mais les besoins sur le terrain sont différents !

Ce que l’on voit fréquemment

Jeton pour le Service A (LOA x)

Je souhaite accéder au service A avec LOA x

Je veux accéder au service A, il me faut donc le LOA x (Level of

Assurance)

Jeton pour le Service A (LOA x)

Je souhaite accéder au service A

Le service A requiert le LOA x

Ce vers quoi il faut tendre

/ Le serveur d’autorisation doit prendre la décision en fonction de lasensibilité de l’opération et du contexte

/ Ce fonctionnement de l’authorization server est permis mais pas décrit

/ Encore beaucoup de déploiements spécifiques

Client Authorizationserver

Client Authorizationserver










Protection contre le vol de jeton : le besoinS’ADAPTER

Authorizationserver

API (Resource server)

Authorizationserver

API (Resource server)

Aggrégateur

Le principe même de « bearer token » entraîne un risque important lors du vol de ce dernier.

La détection du vol étant très difficile, seule l’expiration du jeton est une mesure relativement efficace

Vol de jeton

Dans un contexte d’intermédiation (eg. DSP2), un tiers peut se retrouver en possession de très nombreux jetons.

Le propriétaire de l’API est à la merci de ce tiers et de son niveau de sécurité

Vol d’une base de jetons


ClientAuthorizationserver

API

Token Binding

/ La négociation à deux (ou trois) composantspermet de lier un jeton (ou un cookie) à uneclé publique et la clé privée associée

/ Le client doit prouver qu’il possède la clé privéecorrespondante en établissant une connexionTLS mutuelle

/ Le jeton contient (un hash de) la clé publiquedu client, distincte pour chaque serveurd’API

/ Si le jeton (ou cookie) est intercepté, il estinutilisable

/ Requiert compatibilité du client et des serveurs

› Edge, IE & Chrome disponibles en channels dev

› Module Apache disponible

Protection contre le vol de jeton : la solutionS’ADAPTER

Ok, vois donc avec l’AS et ce tokenBindingID

Génération d’un biclépour l’API cible

Je voudrais un jeton avec ce tokenBindingID

Le voici

Je souhaite un accès, voici ma clé publique

(TLS mutuel)

Voici mon jeton, lié à ma clé publique et tokenBindingID

(TLS mutuel)


Comment en tirer partie ?


Quels outils ?

Quelle sécurité pour les APIs ?

01

02

03


Quelle organisation pour innover?INNOVER

Collaboration avec les fintechs

Partenariat?

Incubation?

Acquisition?

Identification des nouveaux usages

Expérimentation

Viser au delà du périmètre imposé par la DSP2 :

Épargne, crédit, IoT, etc.

Laboratoire interne

Outsourcing

Open Innovation

wavestone.com @wavestone_

riskinsight-wavestone.com@Risk_Insight

securityinsider-solucom.fr@SecuInsider

Bertrand CARLIERSenior Manager

M +33 (0)6 18 64 42 52

[email protected]

PARIS

LONDRES

NEW YORK

HONG KONG

SINGAPORE *

DUBAI *

SAO PAULO *

LUXEMBOURG

MADRID *

MILAN *

BRUXELLES

GENEVE

CASABLANCA

ISTAMBUL *

LYON

MARSEILLE

NANTES

* Partenariats

Directive Services de Paiement 2

Standards, sécurité, quels impacts?

Matinée du 25 avril 2017

Bertrand CARLIERSenior Manager

Wavestone

Léonard MOUSTACCHISSenior Customer Engineer

Forgerock

Jean DIEDERICHPartner

Wavestone

Clément CŒURDEUILPrésident

Budget Insight

Technology

DSP2 standards, sécurité, quels impacts wavestone