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
confidentiel | © WAVESTONE 4
Quels standards d’échange ?
Quels outils ?
01
confidentiel | © WAVESTONE 5
/ 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
confidentiel | © WAVESTONE 6
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
confidentiel | © WAVESTONE 7
Quelle sécurité pour les APIs ?
Quels standards d’échange ?
Quels outils ?
01
02
confidentiel | © WAVESTONE 8
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
confidentiel | © WAVESTONE 9
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
confidentiel | © WAVESTONE 10
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
confidentiel | © WAVESTONE 11
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.
confidentiel | © WAVESTONE 12
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
confidentiel | © WAVESTONE 13
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
confidentiel | © WAVESTONE 14
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
confidentiel | © WAVESTONE 15
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)
confidentiel | © WAVESTONE 16
Comment en tirer partie ?
Quels standards d’échange ?
Quels outils ?
Quelle sécurité pour les APIs ?
01
02
03
confidentiel | © WAVESTONE 17
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
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