LoA — Comment une application peut imposer un niveau de sécurité ? [1/3]
Une application dite sensible peut vouloir s’assurer qu’une authentification réalisée par un serveur d’authentification respecte ses besoins en termes de degré de confiance concernant la personne qui va utiliser ses services.
Cette série, “Comment une application peut imposer un niveau de sécurité ?” est composée de 3 parties :
1. LoA — Level of Assurance
2. SAML 2.0 AuthnContext : [Bientôt]
3. OpenID Connect ACR : [Bientôt]
Dans ce premier volet, avant de nous concentrez sur l’implémentation au sein de WSO2 Identity Server, nous allons prendre de la hauteur et nous intéresser aux concepts d’assurance en terme de sécurité puis nous focaliser sur l’assurance à l’authentification.
Qu’est-ce que c’est que “le niveau d assurance”?
Level of Assurance ou LoA, est une notion de sécurité qui défini le degré de confiance que l’on peut avoir dans l’identité présenté par le service d’authentification à l’application. On parlera également d’identity Assurance.
Quel est le périmètre couvert?
Le niveau d’assurance doit être contextualisé selon son cadre d’emploi. Il va généralement prendre en compte:
- la qualité de chacune des données d’une identité
- qui et comment elle a été renseignée
- les moyens mis en oeuvre pour la vérifier
- son niveau de standardisation ou d’exploitabilité
- sa réactivité de mise à jour - la sûreté des méthodes d’authentification utilisées
- la procédure générale
- les facteurs mis en oeuvre
- l’enchaînement et la complémentarité des facteurs
- les politiques mis en oeuvre sur chacun de ces facteurs - la sécurité de la transmission
- l’assurance que l’on parle bien au bon fournisseur d’identité
- la garantie d’intégrité des messages
- la non répudiation - la robustesse du système du fournisseur
- le respect des standards
- la disponibilité du système
- l’inviolabilité du stockage des identités - la confiance dans le fournisseur d’identité
- la fiabilité des personnes le gérant
- le processus de gestion, de maintenance et d’amélioration
- la reconnaissance par d’autres tiers - la conformité et l’audit
- le respect des réglementations
- la traçabilité des actions
- les contrôles réguliers mis en oeuvre
Existe-t-il des standards?
Il existe de nombreux standards tentant de normaliser les niveaux d’assurances mais dans la pratique c’est une notion fixée de gré a gré par les parties impliquées avec le responsable de l’Identity Provider comme décideur final.
- eIDAS — RÈGLEMENT D’EXÉCUTION (UE) 2015/1502
https://eur-lex.europa.eu/legal-content/FR/TXT/PDF/?uri=CELEX:32015R1502&from=FR - ISO/IEC TS 29003:2018 — Identity Proofing
https://www.iso.org/standard/62290.html - ISO/IEC 29115 — Entity authentication assurance framework,
https://www.iso.org/standard/45138.html - Kantara Initiative Identity Assurance Framework,
https://kantarainitiative.org/confluence/display/LC/Identity+Assurance+Framework - Liberty Identity Assurance Framework,
http://www.projectliberty.org/liberty/content/download/4315/28869/file/liberty-identity-assurance-framework-v1.1.pdf (deprecated) - NIST.SP.800–63 — Electronic Authentication Guideline,
https://pages.nist.gov/800-63-3/ - OMB M-04–04 — E-Authentication Guidance for Federal Agencies,
https://georgewbush-whitehouse.archives.gov/omb/memoranda/fy04/m04-04.pdf (deprecated) - RFC 8445 — Vectors of Trust,
https://datatracker.ietf.org/doc/rfc8485/ - Verifiable Credentials Data Model 1.0,
https://www.w3.org/TR/verifiable-claims-data-model/
Confiance dans les données d’une identité
Une identité est composée de claims, qui représente une assertion, comprenant une ou plusieurs valeurs d’attributs d’une identité, que l’on considérera comme vrai tant que le contraire n’a pas été prouvé.
On préfère utiliser le terme claim plutôt que valeur dans le domaine de la sécurité pour montrer le doute, à un certain degré, que l’on peut avoir sur la véracité des valeurs d’une identité.
L’Assurance de l’authentification
Facteur d’authentification
Les facteurs (ou dispositifs) d’authentification sont classées en 3 catégories :
- «facteur basé sur la possession» — Que possède-t-il?
une information contenue dans un objet.
exemples: une carte à puce, un générateur de token, etc. - «facteur basé sur la connaissance» — Que sait-il?
une information qu’il a mémorisée.
exemples : mot de passe, nom de son chat, etc. - «facteur inhérent» — Qu’est-il?
un attribut biologique.
exemples : empreinte digitale, caractéristique de sa pupille, etc.
2 catégories additionnelles existent :
- «facteur comportemental» — Que sait-il faire?
une action propre.
exemples : signature manuscrite, intonation de la voix, etc. - «facteur contextuel» — Où est-il?
une provenance de la demande
exemples : géolocalisation, horaire, etc.
Niveau d’authentification
Il est communément admis que l’authentification forte doit conjuguer au minimum :
- deux facteurs, de catégories différentes
- dont l’un est utilisé de manière unique
- indépendant entre eux
Par exemple saisir son mot de passe (connaissance) sur son ordinateur et le compléter par une clé générée par une application de son smartphone (possession) est de l’authentification forte.
Par contre saisir son mot de passe (connaissance) sur son smartphone et le compléter par une clé générée par une application (possession) sur le même smartphone n’est pas de l’authentification forte, car la compromission du smartphone compromet les 2 facteurs.
2 référentiels de niveau d’authentification réglementaires majeurs existe, tous les 2 basés sur le standard ISO 29003 :
- NIST SP 800–53 (Etats-Unis) — Authenticator Assurance Level (AAL)
AAL1
gives a low assurance that the claimant has control of an authenticator that is bound to the subscriber account, using single or multi-factor authentication technologies.
AAL2
provides a high assurance that the claimant has control of the authenticators that are bound to a subscriber’s account. Secure authentication protocol(s) for proof and control of two authentication factors, including approved cryptographic processes are required.
AAL3
provides very high assurance that a claimant is in control of the authenticator(s) that are bound to the subscribing account. This level requires the proof of possession of a cryptographic key and the use of a hardware-based cryptographic authenticator that also resists verifier impersonation.
- eIDAS Regulation (Union européenne) — Niveau d’assurance (LoA)
Faible
1. Le moyen d’identification électronique utilise au moins un facteur d’authentification.
2. Le moyen d’identification électronique est conçu pour que l’émetteur prenne des mesures raisonnables afin de vérifier qu’il est utilisé uniquement sous le contrôle de la personne à laquelle il appartient ou en sa possession.
Substantiel
1. Le moyen d’identification électronique utilise au moins deux facteurs d’authentification de différentes catégories.
2. Le moyen d’identification électronique est conçu de sorte qu’on puisse présumer qu’il est utilisé uniquement sous le contrôle de la personne à laquelle il appartient ou en sa possession.
Élevé
Niveau substantiel, plus:
1. Le moyen d’identification électronique protège contre les doubles emplois et les manipulations ainsi que contre les attaquants à potentiel d’attaque élevé.
2. Le moyen d’identification électronique est conçu de sorte que la personne à laquelle il appartient puisse le protéger de façon fiable contre toute utilisation non autorisée.
Dans la prochaine partie nous mettrons en oeuvre la gestion de ces niveaux à l’authentification avec WSO2 Identity Server et l’usage de SAML 2.0.
