• 2 Votes
    1 Messages
    67 Vues

    Dans cet article, nous abordons un aspect important du chiffrement des données : les bonnes pratiques à adopter pour éviter toute compromission. Quelles sont les recommandations du RGS, de l’eIADS et de l’ANSSI en la matière.

    Recommandations du RGS

    Les principales recommandations de l’ANSSI (Agence nationale de la sécurité des systèmes d’information en France) faites dans le RGS (Référentiel général de sécurité) v2 à propos de la cryptographie symétrique sont les suivantes :

    – « La taille minimale recommandée des clés symétriques est de 128 bits. » ;
    – « La taille recommandée des blocs de mécanismes de chiffrement par bloc est de 128 bits. » ;
    – « L’AES, tel qu’il est spécifié dans le FIPS 197, est un mécanisme de chiffrement par bloc conforme au référentiel. ».

    Réglementation eIDAS

    Dans la réglementation eIDAS, les recommandations sur les algorithmes cryptographiques symétriques sont relativement rares, car eIDAS couvre principalement la cryptographie asymétrique avec les mécanismes de signature électronique. En revanche, on trouve une recommandation pour le protocole TLS, avec l’algorithme AES et les tailles de clé de 128 bits et de 256 bits.

    Recommandations de l’ANSSI

    Outre le RGS (Référentiel général de sécurité) – et au même titre que l’AES, l’ANSSI recommande également l’algorithme symétrique ChaCha20, en particulier pour le protocole TLS.

    Par ailleurs, l’ANSSI accepte en mode dégradé les algorithmes de chiffrement Camellia et ARIA, qui ne présentent aucune faille ni faiblesse à ce jour (septembre 2020). Selon l’ANSSI, un algorithme peut être utilisé en mode dégradé lorsque les algorithmes recommandés ne peuventpas être utilisés (c’est-à-dire les algorithmes AES et ChaCha20, dans ce cas).

    L’algorithme ChaCha qui est une variante de l’algorithme Salsa20, a été créé en 2005 par Daniel J. Bernstein – également auteur de la courbe elliptique Curve25519. Les 20 rondes de cet algorithme sont plus rapides que les 10 et 14 rondes de l’algorithme AES.

    L’algorithme Camellia a été créé en 2000 au Japon et est un standard du gouvernement japonais. Cet algorithme Camellia est également approuvé par l’organisme ISO, et recommandé par l’Union européenne, via le projet NESSIE (New European Schemes for Signatures, Integrity and Encryption).

    L’algorithme ARIA a été créé en 2003 par des cryptographes sud-coréens et est recommandé et très utilisé en Corée.

    Le sujet du chiffrement vous intéresse ? Découvrez l’expertise et l’accompagnement de Linagora pour votre entreprise.

    - Valentin BOUILLER et David CARELLA, Linagora.

    Allez plus loin

    Cet article fait partie d’une série de guides sur le chiffrement des données.

    Comprendre le chiffrement homomorphe et ses schémas
    Qu’est-ce que le protocole TLS et à quoi sert-il ?
    Ce qu’il faut savoir sur le chiffrement des données
    Chiffrement des données : conformité et bonnes pratiques

    Source : www.toolinux.com

  • 2 Votes
    1 Messages
    99 Vues

    Une révision du règlement eIDAS, qui régule les procédures électroniques transfrontières pour l’identification, l’authentification et la certification de sites web au sein de l’UE, est en ce moment étudiée par l’Union européenne. L’article 45 de la proposition concerne l’un des mécanismes clés de la sécurité web pour vérifier si un site sécurisé est celui qu’il prétend être. Chaque navigateur web possède une liste d’ « Autorités de certification racine » (appelées « Root Certificate Authorities » ou « Root CAs » en anglais) jugées dignes de confiance pour, dit simplement, valider les certificats TLS (pour « Transport Layer Security », certificats destinés à garantir la sécurité de la connexion Internet) utilisés par les sites. Chaque éditeur de navigateur web – tel que Mozilla, Google, Apple et Microsoft – dirige son propre programme d’audit indépendant pour valider ces Autorités de certification.
    Problème : l’article 45.2 du règlement eIDAS révisé obligerait ces programmes à valider et intégrer automatiquement certaines Autorités de certification soutenues par les États membres de l’Union Européenne, qu’elles remplissent ou non les critères de sécurité exigés jusque-là par les navigateurs web. L’adoption de cette proposition créerait un dangereux précédent mondial : le risque, bien réel, est ni plus ni moins que de rendre possible l’abaissement du niveau de sécurité web pour les internautes.

    Naviguer sur un site sécurisé sur Internet est rendu possible grâce à une série d’opérations de vérification et d’audits de sécurité. Ceci permet de s’assurer que le site est bien celui qu’il prétend être et que les informations qui transitent entre le navigateur et le site en question sont chiffrées de manière confidentielle.

    Pour cela, le navigateur web vérifie deux choses :

    que le certificat TLS d’authentification utilisé par le site sécurisé est valide et digne de confiance. que l’Autorité de certification qui a validé et signé ce certificat est digne de confiance.

    Si ces conditions ne sont pas réunies, le navigateur vous préviendra que le site est peut-être malveillant. Ce sont les fameux messages que vous avez sans doute déjà rencontrés : « Attention risque probable de sécurité » sur Firefox ou « Votre navigation n’est pas privée » sur Chrome.

    Si une Autorité de certification rencontre des défaillances en termes de sécurité, il devient possible pour des acteurs malveillants d’émettre des faux certificats TLS, par exemple pour des sites très fréquentés comme www.google.com. Les attaquants peuvent ensuite consulter le trafic des internautes qui tapent leur requête sur le site malveillant qui se fait passer pour www.google.com. Ce type d’attaque a été conduit par le passé contre de multiples Autorités de certification en raison de failles de sécurité sur leurs systèmes (par exemple DigiNotar CA et Comodo CA en 2011).

    Des acteurs étatiques malveillants qui veulent mener des opérations de surveillance de masse dans leur pays peuvent aussi créer et contrôler une Autorité de certification pour contourner les protocoles de sécurité sur Internet. Tous les certificats émis par l’Autorité de certification en question peuvent alors potentiellement être utilisés pour espionner les communications des internautes ciblés.

    Pour limiter les risques pour leurs utilisateur-rice-s, les navigateurs web auditent et sélectionnent de manière indépendante les Autorités de certification qui sont jugées dignes de confiance. Les critères de validation sont consultables en ligne, tel le « Root Program » de Mozilla ou celui d’Apple.

    En cas de problème de sécurité, les navigateurs peuvent décider de ne pas inclure ou de retirer une Autorité de certification de leurs listes. Par exemple, une Autorité de certification gérée par le gouvernement du Kazakhstan a été bloquée de concert par Google, Apple et Mozilla en 2019. Autre exemple en 2014, lorsque Google avait détecté des faux certificats pour des noms de domaines de Google émis par le centre national d’informatique du gouvernement indien suite à une faille de sécurité : ceux-ci étaient alors inclus dans le « Root Store » de Microsoft, qui a dû les révoquer.
    Le processus d’évaluation pour révoquer ou rejeter une Autorité de certification est particulièrement transparent dans le cas des programmes publics à but non lucratif : Mozilla documente ainsi publiquement les audits et les problèmes rencontrés, comme dans le cas de la révocation en 2019 du CA français Certinomis.

    Que propose la nouvelle révision du règlement eIDAS ?

    La version initiale du règlement eIDAS a été adoptée en 2014 pour fournir « la base des procédures électroniques transfrontières pour l’identification, l’authentification et la certification de sites web au sein de l’UE » (dossier de presse).
    Concrètement, le règlement a pour ambition de réguler la manière dont les transactions électroniques s’effectuent au sein de l’Union Européenne, en établissant, pour citer l’ANSSI, un « socle commun pour les interactions sécurisées entre les citoyens, les entreprises et les autorités publiques ».

    La section 8 du règlement est dédiée à l’ « Authentification de site internet ». L’article 45 présente les « Exigences applicables aux certificats qualifiés d’authentification de site internet » qui sont fixées à l’annexe IV. Ces certificats qualifiés (« Qualified Web Authentication Certificates », ou QWAC en anglais) sont délivrés par des prestataires de service de confiance (« Trust Service Providers » ou TSP) régis par le règlement eIDAS et qui sont des Autorités de certification soutenues par les gouvernements des États membres de l’Union Européenne.

    L’article 45.2 de la proposition de révision pose que « Les certificats qualifiés d’authentification de site internet visés au paragraphe 1 sont reconnus par les navigateurs internet. À cette fin, les navigateurs garantissent que les données d’identité fournies au moyen de l’une des méthodes s’affichent de manière conviviale. À l’exception des entreprises considérées comme des micro et petites entreprises au sens de la recommandation 2003/361/CE de la Commission pendant leurs cinq premières années d’activité en tant que prestataires de services de navigation sur internet, les navigateurs acceptent les certificats qualifiés d’authentification de site internet visés au paragraphe 1 et garantissent l’interopérabilité avec ces derniers. »

    Ceci implique que les navigateurs webs sont légalement tenus de reconnaître ces certificats qualifiés comme valides, et donc d’intégrer dans leur liste de confiance les prestataires de service de confiance régis par eIDAS.

    Quelles sont les conséquences de cette révision pour les internautes ?

    Malheureusement, ces certificats qualifiés d’authentification posent plusieurs problèmes de sécurité et d’interopérabilité dans leur modèle d’implémentation. Depuis leur introduction en 2014, ils n’ont donc pas été adoptés dans l’écosystème web. La Common CA Database, une initiative rassemblant plusieurs éditeurs de navigateurs web autour de la gestion des Autorités de certification et gérée par la fondation à but non-lucratif Mozilla, expose en détails les problèmes techniques rencontrés par les navigateurs avec les spécifications proposées pour les certificats qualifiés : notamment son absence de compatibilité avec le fonctionnement technique des navigateurs web et du déploiement de TLS sur les site, ainsi que ses manques en terme de respect de la vie privée des internautes.

    Concrètement, l’article 45.2 reviendrait à obliger les navigateurs web à accepter des prestataires de service de confiance régis par eIDAS, même s’ils ne remplissent pas les critères de sécurité exigés habituellement par les navigateurs. Le risque que des certificats soient émis et utilisés à des fins malveillantes par des cybercriminels serait accru. C’est sur quoi alertent trente-cinq experts mondiaux en cybersécurité et en cryptographie dans une lettre ouverte adressée aux membres du Parlement Européen et publiée sur le site de l’organisation à but non lucratif Electronic Frontier Foundation en mars 2022.

    Pire, si une Autorité de certification intégrée à la liste de confiance des navigateurs est vulnérable à des problèmes de sécurité, les navigateurs web ne seraient pas légalement en mesure de refuser ou de retirer l’Autorité de certification de leur liste de confiance pour protéger les internautes.

    Par ailleurs, les connaissances techniques en sécurité peuvent vite évoluer : la découverte d’une nouvelle faille de sécurité peut requérir une réponse rapide de la part des éditeurs de navigateurs web afin de protéger les internautes, par exemple en retirant une Autorité de certification du « Root Store ». De plus, les règles de gestion des « Root Store » sont mises à jour régulièrement afin de suivre les évolutions technologiques et se protéger contre les tentatives des acteurs malveillants qui tentent de les contourner. Cette réactivité (quelques semaines) n’est malheureusement pas compatible avec les délais requis pour des changements législatifs (un an ou plus).

    Enfin, si elle était adoptée, cette proposition de révision du règlement eIDAS créerait un précédent au niveau mondial. Les navigateurs web pourraient dès lors difficilement refuser ou retirer une Autorité de certification racine provenant d’un autre gouvernement qui ne respecterait pas les critères de sécurité requis. Des tentatives précédentes, au Kazakhstan comme mentionné précédemment ou en Iran comme l’explique l’ONG Article19, prouvent qu’il s’agit d’un danger bien réel. Autre exemple plus récent : suite au retrait de plusieurs Autorités de certification en Russie pour sanctionner la guerre qu’elle mène en Ukraine, le gouvernement russe a dû mettre en place une Autorité de certification de remplacement pour assurer le fonctionnement de plusieurs de ses sites web et a demandé aux internautes d’autoriser manuellement cette Autorité au sein de leur navigateur. Si cette opération peut être justifiée par un motif légitime et qu’il n’y pour l’instant aucune preuve qu’elle ait été rendue obligatoire et utilisée à des fins de surveillance, elle a aussi pour conséquence de rendre possible, justement, la surveillance de masse de la population russe comme le souligne l’Electronic Frontier Foundation.

    Bien que cela ne soit clairement pas l’intention visée, la proposition du règlement eIDAS risque de normaliser des dispositifs jusque-là largement condamnés au sein de l’Union Européenne et hors de ses frontières.

    Par ailleurs, ce n’est pas la première fois que l’Union Européenne cherche à intervenir directement sur les technologies et l’infrastructure d’Internet. Les controverses autour de la nouvelle directive Network and System of Information Security (NIS2), de la proposition d’établissement d’un DNS européen DNS4EU ou même du Digital Service Act témoignent de cette nouvelle volonté d’intervention directe de l’UE sur les technologies/l’infrastructure et de sa légitimation à travers des biais sécuritaires et économiques, mais qui peuvent aussi avoir des conséquences dommageables sur l’interopérabilité des systèmes et la sécurité des internautes.

    Nous nous joignons donc à Mozilla et à l’Electronic Frontier Foundation pour alerter sur les dangers introduits par l’article 45.2 de la proposition de révision du règlement eIDAS.
    Nous appelons en conséquence le gouvernement et les élus français à demander la modification ou le retrait de l’article 45.2 afin que les navigateurs web restent en mesure de protéger les internautes en appliquant des standards élevés en termes de sécurité et de transparence.