[REPLAY WEBINAR] Cyberisque : anatomie des attaques sur le DNS et le nom de domaine, exemples et solutions à mettre en place

WEBINAR - Cyberisque : anatomie des attaques sur le DNS et le nom de domaine, exemples et solutions à mettre en place

Retrouvez sur le site de Nameshield et la plateforme Webikeo, le replay du webinar « Cyberisque : anatomie des attaques sur le DNS et le nom de domaine, exemples et solutions à mettre en place », animé par Christophe GERARD, Security Product Manager de Nameshield.

Dans un monde qui continue sa mue vers la digitalisation, les entreprises déjà bien au fait du cyberisque pesant sur les organisations, ont vu les menaces augmenter pendant la période COVID. La nécessité de sécuriser ses actifs numériques est plus que jamais au cœur des sujets IT.

Au programme de ce webinar :

  • L’importance stratégique du DNS et des noms de domaine
  • Les risques liés à la gestion administrative
  • Les risques de détournement d’accès
  • Les risques liés à la gestion technique
  • Les mesures indispensables à mettre en place
Visionner le replay

ICANN73 ou la difficile équation de préserver un modèle fragilisé

ICANN73 ou la difficile équation de préserver un modèle fragilisé

L’ICANN garante d’une « résolution universelle » de l’Internet pour tous les internautes, est ces dernières années confrontée à des difficultés nouvelles qui fragilisent l’instance et son modèle. Son mode de fonctionnement a dû être adapté à une pandémie mondiale inédite et son modèle d’un Internet global est aujourd’hui questionné par les velléités croissantes d’États de s’émanciper de ce dernier, le conflit tragique en Ukraine éloignant un peu plus l’Oural des Rocheuses. Mais les difficultés viennent aussi de son environnement immédiat avec l’essor des racines alternatives. C’est dans ce contexte et suite à une précédente édition marquée par des crispations autour des sujets qui font son actualité et qui peinent à avancer, que s’est ouvert un 73ième sommet très attendu.

Une fois n’est pas coutume, le coup d’envoi du 73ième sommet de l’ICANN n’a pas été donné un lundi, jour prévu pour les premières sessions de travail. Le dimanche 6 mars, l’ICANN a en effet publié un communiqué indiquant que son conseil d’administration a décidé d’allouer une somme initiale de 1 million de dollars US d’assistance financière afin de soutenir l’accès à l’infrastructure Internet dans les situations d’urgence de l’Ukraine. Une façon de lancer une édition où le conflit en Ukraine allait forcément être présent dans tous les esprits et dans bien des débats.

Le conflit en Ukraine en filigrane

En effet le lundi après-midi la toute première session plénière du sommet, celle du GAC, l’instance représentant les gouvernements, a débuté sur une condamnation des actions de la Russie en Ukraine. Plusieurs membres du GAC dont celui de la France ont pris la parole.

Deux semaines plus tôt, l’Ukraine était en proie aux premières frappes russes. L’Ukraine par la voie de Mykhailo Fedorov, Vice premier ministre et ministre de la transformation numérique avait alors demandé à l’ICANN de cibler l’accès de la Russie à l’Internet en révoquant les domaines de premier niveau des codes pays spécifiques opérés depuis la Russie, la révocation des certificats SSL associés aux noms et à fermer un sous-ensemble de serveurs racines localisés en Russie. Une demande à laquelle ICANN avait répondu par la négative dans une lettre adressée par Goran Marby, patron de l’ICANN, au Ministre rappelant que la mission de l’ICANN était de prendre des mesures pour assurer un fonctionnement de l’Internet global et non politisé. L’ICANN est une instance neutre a ainsi répété Goran Marby lors du Forum public qui clôturait le sommet.

Des perspectives pour les processus de développements de politiques en cours

On se souviendra que lors du précédent sommet de l’ICANN, les crispations étaient palpables dans certaines instances, notamment celle représentant les registres en raison de processus de développements de politiques qui se sont allongés avec des étapes additionnelles comme les ODP (Operational Design Phase) qui interviennent désormais entre la restitution des recommandations et le vote du Board sur ces dernières.

Le premier sujet qui a essuyé les plâtres de cette étape ODP est celui du Système Standardisé d’Accès aux Données. Ce système connu sous l’acronyme SSAD est en discussion depuis plus de trois années dans le cadre d’un processus de développement de politiques dit ‘ePDP’ dont le SSAD est corrélé à la phase 2. Il doit permettre de revenir à un modèle d’accès plus uniforme aux données d’enregistrement des noms de domaine lors de demandes légitimes. Pourtant l’ODP qui vient d’être finalisée avec six mois de délai par rapport au calendrier initial estimé, a mis en lumière la difficulté de cadrer ce projet. Le nombre d’utilisateurs est en effet estimé entre 25 000 et 3 millions pour adresser 100 000 à 12 millions de requêtes, des valeurs qui induisent une fourchette de coûts de mise en place et de maintenance particulièrement large (de 34 à 134 millions de dollars US) et par conséquent des frais d’accès au futur système très difficiles à évaluer, l’idée étant de financer le dispositif exclusivement avec les coûts d’accès. Lors de l’ICANN73 une porte de sortie a pointé son nez : Créer un projet pilote pour limiter les risques, en d’autres termes envisager un SSAD à échelle réduite avant de considérer la suite.

On a pu noter que la phase 1 de l’ePDP précité a désormais une ligne d’arrivée. Elle est estimée à fin 2022. Cette phase vise à créer une politique pérenne pour remplacer une Specification Temporaire qui adressait le RGPD dans l’écosystème des noms de domaine en 2018.

L’autre grand sujet est celui d’une prochaine série de nouvelles extensions génériques. Rappelons en effet que la précédente série va fêter ses dix années en 2022. Depuis, c’est un processus de développement de politiques (PDP) qui s’est étiré de décembre 2015 à février 2021 où l’instance représentant les politiques génériques, le GNSO, avait adopté le rapport final de recommandations. En septembre dernier, le Board ICANN a décidé d’engager un processus ODP qui pourrait durer jusqu’au début de l’année prochaine. Ce sujet a suscité de vives critiques car la ligne d’arrivée semble repoussée de plus en plus alors que dix années se sont écoulées depuis le dernier round. Une piste a néanmoins été discutée lors de l’ICANN73, celle de débuter les travaux d’implémentation sans tarder, une proposition qui, si elle a plutôt déplu au patron de l’ICANN, a été accueillie plutôt positivement par le Board de l’ICANN qui pourtant ne devrait se prononcer sur les recommandations du rapport final du processus PDP qu’après la fin de l’ODP.

Aspects géopolitiques, législatifs et règlementaires, une nouveauté

Parmi les nouveautés de ce sommet, on a pu noter une session plénière consacrée aux aspects géopolitiques, législatifs et règlementaires. Cette session a permis de faire un tour d’horizon des nombreuses initiatives qu’elles viennent d’institutions comme l’Organisation des Nations Unies, l’Union des Télécoms Internationale, du Conseil de l’Europe ou de l’OCDE ou d’Etats comme la Russie avec la loi de souveraineté numérique ou la Chine avec la loi sur la Cybersécurité et la sécurité des données. Cette session a également permis de clarifier des perceptions comme la position de l’ICANN sur la directive européenne NIS2. Goran Marby a indiqué que l’ICANN n’a pas de position officielle sur ce sujet.

Le retour du GDD summit ?

Jusqu’en 2019, l’ICANN proposait en plus des trois sommets consacrés aux politiques, un sommet plus opérationnel appelé GDD Summit. Ce dernier a été abandonné dans le contexte de pandémie mondiale et n’a depuis plus été évoqué. La possibilité de relancer ce dispositif a été remise sur la table lors de l’ICANN73. Il pourrait donc y avoir un quatrième rendez-vous annuel donné par l’ICANN dès la fin de cette année, novembre ayant été évoqué pour sa possible tenue. Il y aura néanmoins d’ici là, l’ICANN74 en juin et l’ICANN75 en septembre, deux événements où le mode hybride, présentiel et distanciel, tient la corde.

Commentaires Nameshield

L’ICANN 73 a indéniablement été marqué par le conflit en Ukraine. Un conflit qui paradoxalement a permis de retrouver un semblant d’unité avec l’esquisse de solutions comme le fait de permettre aux bureaux d’enregistrement ukrainiens de déroger aux politiques ICANN via un dispositif dit de « circonstances extraordinaires » et de rappeler l’ICANN à ses fondamentaux, une instance apolitique œuvrant pour un Internet global. En dressant un panorama des contextes géopolitiques, législatifs et règlementaires, l’instance semble également avoir pris conscience que le monde à venir risque de rendre la préservation de son modèle d’un Internet globalisé encore plus difficile. Le sentiment après ce sommet est que des propositions et perspectives plus concrètes ont été données sur une partie des sujets débattus.

On notera pour le prochain round, que c’est la menace des racines alternatives au DNS qui se développent qui pourrait donner un coup de boost inattendu au processus en cours. Ces racines qui tendent en effet à se développer pourraient occasionner des collisions entre requêtes si un jour des TLDs identiques cohabitent dans deux environnements, risque d’autant plus accru si ICANN marque le pas sur un futur round. Autre risque : se voir contester l’attribution de TLDs règlementaires alors qu’un TLD identique existerait sur une racine alternative.

Nameshield sera présent au Security Forum – Le 5 avril 2022 à Paris

Nameshield sera présent au Security Forum - Le 5 avril 2022 à Paris

Après plusieurs éditions réussies en Belgique, Security Forum arrive en France pour la toute première fois et se tiendra le 5 avril 2022 à la Cité Internationale Universitaire de Paris.

Une opportunité pour faire le point sur la cybersécurité, sur les attentes du secteur et des sociétés, ainsi que sur les enjeux liés à la sécurité.

Cet événement a pour objectif d’apporter aux responsables d’entreprises françaises une réponse pratique à leurs préoccupations en leur présentant les dernières évolutions technologiques dans ce domaine ainsi qu’en leur permettant de rencontrer les acteurs de terrain susceptibles de les accompagner dans leur démarche.

Venez nous rencontrer sur place pour échanger avec nos experts cybersécurité et découvrir nos solutions globales répondant aux impératifs de sécurité DNS et à la nécessité de surveiller, protéger et défendre votre marque en ligne.

Prendre rendez-vous

ALERTE : Certificats TLS/SSL – Vigilance phishing

ALERTE : Certificats TLS/SSL - Vigilance phishing

Important : information relative à la situation en Russie, Biélorussie et Ukraine.

Au regard de la situation géopolitique en Ukraine, nous tenons à vous informer que de nombreuses autorités de certifications suspendent l’émission et la réémission de tous les types de certificats affiliés à la Russie et à la Biélorussie.

Cela inclut la suspension de la délivrance et de la réémission de certificats liés aux TLDs de la Russie et de la Biélorussie, à savoir .ru, .su, .by, .рф, ainsi qu’aux organisations ayant des adresses en Russie ou en Biélorussie. Nous vous tiendrons informés dès le retour à la normale.

Par ailleurs, nous constatons une augmentation importante des attaques par phishing. Nous vous invitons à une vigilance accrue, en surveillant notamment les nouveaux dépôts de noms de domaine reprenant vos marques.

Nameshield se tient bien sûr à votre disposition pour vous accompagner et vous conseiller dans ce contexte complexe.

Source de l’image : Freepik Storyset

Ouverture des enregistrements en .TZ

Ouverture des enregistrements en .TZ

Depuis le 1er Mars 2022, le registre tanzanien autorise l’enregistrement des .TZ.

Une première phase de 3 mois (jusqu’au 31/05/2022) permettra l’enregistrement aux titulaires des .CO.TZ enregistrés avant le 01/03/2022.

A compter du 01/06/2022, il sera possible d’enregistrer des .TZ équivalents aux noms récemment enregistrés en .CO.TZ (.co.tz enregistrés après le 01/03/2022).

Une ouverture générale est prévue le 1er Juillet 2022.

L’équipe Nameshield se tient à votre disposition pour toute question.

Source de l’image : carboblock via Pixabay

Lancement des enregistrements en .AU le 24/03/2022 – Rappel

Ouverture des enregistrements de noms de domaine en .AU

La date de l’ouverture des enregistrements de noms de domaine en .AU est annoncée au 24/03/2022.

Pour rappel, pendant les six premiers mois, le processus d’allocation prioritaire mis en place vous offrira l’opportunité de :

  • demander la correspondance exacte de vos noms de domaine déjà existants (.com.au / .net.au / .org.au etc) en .AU ;
  • d’enregistrer de « nouveaux » noms directement en .AU (noms qui n’existeraient pas dans d’autres extensions telles que .com.au, .net.au, .org.au etc.).

A noter : vos noms de domaine existants continueront à fonctionner normalement et conformément à la politique du registre auDA, indépendamment d’un enregistrement en .AU.

L’équipe Nameshield se tient à votre disposition pour toute question.

Source de l’image : kitkatty007 via Pixabay

Nameshield sera présent aux Rencontres de SOLAINN – Le 24 mars 2022 à TROYES

Le Numérique de France à l’honneur dans le Grand Est !

Rencontres de SOLAINN

Le 24 mars 2022, se tiendra au Centre des Congrès de l’Aube à TROYES, les rencontres B2B organisées par SOLAINN, le référentiel des solutions numériques créées et développées par 300 entreprises françaises pour répondre aux enjeux numériques de toutes les organisations.

Vous êtes décideur en charge des SI, de l’IT, des applications métiers, dans les entreprises et collectivités ?

Retrouvez Nameshield à la première journée des Rencontres B2B de SOLAINN qui réunira décideurs et 30 fournisseurs de solutions logicielles et infrastructures français.

Plus d’informations et inscriptions à la journée rencontres via ce lien : www.solainn-grandest.fr

[WEBINAR] Cyberisque : anatomie des attaques sur le DNS et le nom de domaine, exemples et solutions à mettre en place – Le 31 mars à 14h

[WEBINAR] Cyberisque : anatomie des attaques sur le DNS et le nom de domaine, exemples et solutions à mettre en place

Rendez-vous le 31 mars 2022 à 14h pour assister au webinar « Cyberisque : anatomie des attaques sur le DNS et le nom de domaine, exemples et solutions à mettre en place », animé par Christophe GÉRARD, Security Product Manager de Nameshield group.

Dans un monde qui continue sa mue vers la digitalisation, les entreprises déjà bien au fait du cyberisque pesant sur les organisations, ont vu les menaces augmenter pendant la période COVID. La nécessité de sécuriser ses actifs numériques est plus que jamais au cœur des sujets IT.

Au cours de ce webinar, notre expert reviendra sur l’importance stratégique du DNS et des noms de domaine, et vous présentera les attaques potentielles et les solutions pour s’en prémunir.

Je m’inscris au webinar

Pour y assister, il faudra au préalable vous inscrire sur la plateforme Webikeo (inscription gratuite) puis réserver votre place pour ce webinar. Vous pourrez ainsi participer en live à cette web-conférence et poser vos questions en direct.

Vous ne serez pas disponible ? Pas d’inquiétude, ce webinar sera également disponible en replay.

ION : l’identité décentralisée sur Bitcoin

ION : l'identité décentralisée sur Bitcoin

L’identité numérique de demain 

L’identité est une partie intégrante du monde numérique dans lequel nous vivons. Tout individu, organisme ou ordinateur est représenté virtuellement par un ou plusieurs identifiants, liés de près ou de loin à différentes données. L’identité numérique permet de faire le lien entre une entité réelle et sa représentation virtuelle.

Que ce soit pour s’authentifier, communiquer ou utiliser un service sur le Web, nous utilisons des identifiants uniques, qui sont associés à plusieurs informations personnelles (adresses mail, pseudonymes, id aléatoires, etc.). Ces identifiants sont en général gérés par des organismes qui ont le contrôle sur nos données. Celles-ci peuvent être analysées, altérées, revendues ou encore volées, sans avoir le consentement des utilisateurs ; cela représente des menaces vis-à-vis de leurs vies privées. Il ne faut pas oublier que le business des données représente plusieurs milliards d’euros ; les utilisateurs n’ont pas toujours en tête que leurs données ont une véritable valeur.

C’est à partir de ce constat que le concept d’identité décentralisée, aussi appelée l’identité auto-souveraine (self-sovereign identity / SSI), est né.

L’identité décentralisée a pour objectif de redonner aux utilisateurs le contrôle sur leurs données, en étant au cœur du Web3. Elle s’appuie sur des identifiants décentralisés (DID), déployés sur un registre distribué. Les utilisateurs sont les seuls à pouvoir gérer leurs DID et les données qui y sont liées. Ils peuvent y associer seulement les informations qu’ils souhaitent partager.

Plusieurs acteurs développent des solutions pour mettre au point des systèmes d’identités décentralisées. Aujourd’hui nous allons nous intéresser à l’une d’entre elles : ION (Identity Overlay Network). Il s’agit d’un réseau décentralisé de gestion d’identité, basé sur Bitcoin.

Source : https://identity.foundation/ion/

SideTree : un protocole de gestion d’identifiants

En 2017, les membres de la Decentralized Identity Foundation (DIF) ont commencé à travailler sur une solution pour gérer des identifiants décentralisés, notamment en utilisant des Blockchains comme registres. L’idée étant d’inscrire des références sur une chaîne de blocs, afin qu’elles soient vérifiables et autocontrôlées par leurs titulaires. De par ses propriétés de registre décentralisé, les Blockchains répondent particulièrement au besoin. Plusieurs projets autour de l’identité décentralisée ont recours à ce type de technologie pour gérer des DID.

L’une des problématiques des Blockchains, c’est la difficulté à monter en charge : la scalabilitée. Par exemple, sur Ethereum le réseau est souvent saturé, ce qui provoque des lenteurs dans le traitement des transactions et des frais qui augmentent. D’autres Blockchains proposent de meilleures performances, mais font un compromis sur la sécurité ou la décentralisation du système. On parle du trilemme des Blockchains.

Pour qu’un système d’identité puisse fonctionner à l’échelle globale, il doit être scalable. Pour cela, il existe des solutions dites de Layer 2. Ce sont des solutions construites “au-dessus” d’une Blockchain existante, de manière à agréger plusieurs opérations en une seule transaction. Cela permet d’augmenter significativement le nombre de transactions par seconde pouvant être traitées, et donc de diminuer les frais. Ce mécanisme est notamment utilisé par le Lighning Network sur Bitcoin, et par différentes applications sur Ethereum.

Les membres de la DIF ont alors développé un protocole de Layer 2 pour gérer des identités décentralisées : SideTree. Ce protocole permet de créer un réseau sur lequel les différents nœuds sont connectés en pair-à-pair. Le protocole peut être adapté à différentes Blockchains sous-jacentes, pour offrir une certaine interopérabilité. Il est aussi important de souligner qu’il suit les préconisations du W3C par rapport aux DID et aux Vérifiable Credentials.

SideTree est construit avec plusieurs composants logiciels :

API REST : une interface pour permettre aux utilisateurs d’interagir avec le système.

SideTree Core : c’est la partie “logique” du système, qui gère les différentes opérations sur les identifiants.

Content Addressble Storage : gère le stockage des identifiants et leurs métadonnées. SideTree utilise notamment IPFS, un protocole permettant de stocker et distribuer des données de manière décentralisée. Une base de données MongoDB est également utilisée pour du stockage local.

Blockchain Adapter : permet de communiquer avec une Blockchain sous-jacente, afin d’y enregistrer des “états”.

ION : le protocole SideTree couplé à Bitcoin

Bitcoin comme layer 1

ION (Identity Overlay Network) est une implémentation du protocole SideTree basé sur Bitcoin et développé par les membres de la DIF. C’est donc un système de gestion d’identité public, décentralisé et qui n’est contrôlé par aucune organisation. Il est capable de gérer plusieurs milliers d’opérations par seconde.

SideTree a également d’autres implémentations, dont Element qui est basé sur la Blockchain Ethereum.

ION a choisi Bitcoin pour :

Sa décentralisation :

  • Le réseau est ouvert à tous
  • Les nœuds sont nombreux et décentralisés
  • Les transactions sont transparentes, vérifiables et immuables

Sa sécurité :

  • Bitcoin a montré sa résistance depuis plus de 10 ans
  • Les participants sont incités à maintenir et faire fonctionner le réseau
  • Le coût d’une attaque à 50% est extrêmement élevé, et considérée impossible

Des DID et documents

Concrètement, un identifiant sur ION ressemble à une suite de caractères unique et complexe : did:ion:EiD3DIbDgBCajj2zCkE48x74FKTV9_Dcu1u_imzZddDKfg

Ce DID il est lié à un document JSON qui contient plusieurs propriétés.

Source : https://cryptoms.fr/

L’utilisateur peut également ajouter toutes les propriétés qu’il souhaite. Il est possible d’obtenir le document à partir de l’identifiant, en effectuant une résolution. Cela peut se faire en utilisant l’API REST d’un nœud ION, ou alors en utilisant un explorateur dédié. L’idée est de pouvoir récupérer les informations associées à un DID, de la même manière que lorsqu’on récupère les adresses IP liées à des noms de domaine (DNS).

Comment ça fonctionne ?

Pour générer un DID, un utilisateur doit soit utiliser son propre nœud, soit en utiliser un disponible sur le réseau. L’opérateur du nœud doit avoir un portefeuille numérique (wallet) avec du Bitcoin, car l’opération nécessite d’effectuer une transaction. La gestion des identifiants se fait en plusieurs étapes, en ligne de commande et via une API REST; ce n’est pas trivial.

Chaque identifiant est lié à 3 paires de clés cryptographiques :

  • Clés de mise à jour
  • Clés de récupération
  • Clés de signature

Les opérations réalisées lors de la création sont inscrites dans un fichier. Ce fichier d’instructions est distribué sur IPFS, et son identifiant unique est inscrit dans une transaction Bitcoin. Les opérations simultanées sur plusieurs identifiants sont regroupées, afin d’avoir une seule transaction Bitcoin exécutée. SideTree utilise notamment des arbres de Merkel afin de structurer les états des différents identifiants, et permettre la gestion d’un grand nombre d’opérations par transaction.

Tous les autres nœuds du réseau ION observent les transactions Bitcoin et extraient celles qui correspondent au protocole ION. Ils récupèrent le fichier d’instructions sur IPFS, grâce à son identifiant unique contenu dans la transaction. Puis ils exécutent les instructions afin de se mettre à jour et contenir les derniers identifiants créés. Ainsi, le nouvel identifiant est distribué sur l’ensemble du réseau. Le temps de synchronisation peut varier ; nous n’avons pas trouvé de mesures par rapport à ce temps.

Par définition, les DID ne sont pas transférables ; l’utilisateur à l’origine d’une opération sur un DID est donc forcément le “propriétaire” et le seul à avoir le contrôle dessus avec sa clé privée. Cette propriété permet notamment de se passer d’un mécanisme de consensus lors des opérations sur les DID, car il n’y a pas de doubles dépenses possibles.

Quel avenir ?

Plusieurs cas d’usage

Le projet ION est développé par les membres de la DIF, et soutenu activement par Microsoft. L’entreprise américaine souhaite exploiter ce protocole afin de proposer de nouveaux services basés sur l’identité décentralisée.

Plusieurs cas d’usage sont possibles :

  • Les utilisateurs peuvent créer leurs DID et utiliser le système d’authentification OpenID. Ainsi, il serait possible de s’authentifier sur diverses applications, sites et services Web avec un identifiant unique et décentralisé. L’authentification sans mot de passe est possible.
  • Les utilisateurs pourraient choisir les données qu’ils souhaitent associer à leur DID et révoquer leurs accès à tout moment. Des modèles économiques pourraient être développés afin de rémunérer directement les utilisateurs en échange de leurs données.
  • Les utilisateurs peuvent gérer différentes identités avec plusieurs DID, à travers leurs portefeuilles numériques.
  • Des entreprises, écoles ou organismes peuvent générer des certificats numériques vérifiables associés à des DID. (Verifiable Credentials).
  • Les DID peuvent être associés à des noms de domaine, afin d’utiliser des noms lisibles plutôt que des adresses complexes.

Des services à développer

L’ambition de ION est de devenir un standard pour l’identité décentralisée de demain. L’ingéniosité du protocole est intéressante, et pourrait se démarquer des autres solutions concurrentes notamment grâce à l’utilisation du protocole Bitcoin. Les solutions Layer 2 sont prometteuses pour de nombreux cas d’usage, et permettent d’augmenter significativement la scalabilitée des registres décentralisés.

Cependant, aujourd’hui le protocole reste complexe à utiliser ; des outils et applications pour faciliter l’usage devront être développés. Microsoft proposera certainement des services utilisant ION, mais il faut espérer que d’autres acteurs suivront ce pas, notamment avec des “solutions finales” non-propriétaires.

De plus, les spécifications techniques recommandées pour déployer un nœud sont assez gourmandes ; cela peut représenter un coût non négligeable en termes d’hébergement. Les frais lors de l’enregistrement d’un DID sont également à la charge de l’opérateur du nœud, qui va soumettre la transaction sur le réseau. Il n’y a donc pas d’incitation économique pour déployer un nœud, mis à part pour créer un modèle économique en vendant l’enregistrement de DID à d’autres utilisateurs. À première vue, ces éléments peuvent être des freins à la décentralisation et l’adoption de ION, mais il est encore trop tôt pour l’affirmer.

De nombreux concurrents

La concurrence est rude dans le monde de l’identité numérique. D’une part, il y a les solutions d’identité proposées par des géants (Google, Facebook, Thales, etc.), qui dominent aujourd’hui le marché, d’autre part il y a les solutions d’identités souveraines poussées par les gouvernements (France Connect, Essif, etc.). En marge de ces systèmes plus ou moins centralisés, les protocoles d’identité auto-souveraine sont également nombreux. Mise à part ION, il y a également Ethereum Name Service basé sur Ethereum, Evernym, Sovrin et d’innombrables projets en cours de développement.

La réalisation d’applications concrètes et l’adoption par le grand public sont des points essentiels dans la réussite d’un projet ; le temps nous montrera lesquels feront la différence et se rendront indispensables au Web de demain.

Les sujets blockchains et crypto-actifs vous intéressent ? N’hésitez pas pour en savoir plus à consulter le site de notre expert Steve Despres : https://cryptoms.fr/

Source de l’image : TheDigitalArtist via Pixabay

BIMI et VMC : affichez votre logo avec les e-mails

BIMI et VMC : affichez votre logo avec les emails

BIMI (Brand Indicators for Message Identification) permet d’authentifier vos emails et de renforcer la confiance de vos clients en affichant votre logo dans leur boîte de réception. VMC (Verified Mark Certificate) est un certificat associé à BIMI, garantissant l’authenticité du logo affiché.

BIMI et VMC : affichez votre logo avec les emails

Qu’est-ce que BIMI?

BIMI est une initiative de l’industrie visant à normaliser l’utilisation et l’affichage des logos des marques dans les clients de messagerie. En plaçant le logo d’une marque ou d’une entreprise à côté d’un e-mail, celui-ci est plus facilement identifiable par les clients et les utilisateurs, installe un sentiment de légitimité et de confiance, impacte significativement les taux d’ouverture et augmente la protection des consommateurs contre les e-mails frauduleux.

Techniquement parlant, BIMI est une technologie de sécurité émergente qui fonctionne en complément des protocoles DKIM, SPF et DMARC pour protéger votre nom de domaine contre l’utilisation par des acteurs malveillants pour envoyer des e-mails frauduleux.

Avant BIMI, les étapes pour faire apparaître votre logo à côté d’un e-mail étaient spécifiques à chaque service de messagerie auquel votre message était envoyé. Parfois, le processus était entièrement manuel ou s’appuyait sur d’autres applications pour agréger les informations de votre marque et les partager sur les plateformes participantes.

Le groupe AuthIndicators, qui comprend des fournisseurs de services de messagerie tels que Google, Verizon Media, IONOS by 1&1 et Fastmail, travaille à la mise en œuvre de BIMI dans les clients de messagerie les plus courants. De nombreux acteurs ont déjà adopté BIMI, d’autres sont en cours, les positions de Microsoft et d’Apple sont attendues pour faire définitivement adopter ce standard.

Pourquoi BIMI est important ?

Pour compléter l’arsenal de protection d’une marque sur Internet, plus particulièrement contre les tentatives de détournement via des e-mails frauduleux de type spoofing dont le but est de tromper l’utilisateur et de l’amener vers des sites de phishing.

.

306 Milliards d’e-mails ont circulé en 2020 dans le monde, avec une proportion toujours croissante de mails frauduleux détournant des marques.

Pour augmenter la désidérabilité des e-mails, notamment dans les campagnes marketing. L’implémentation de BIMI et plus largement des protocoles et certificats de sécurité sur le nom de domaine associé à une marque est indispensable aujourd’hui et a un impact majeur sur la réputation en ligne.

Parce que c’est en train de devenir un standard du marché, simple à mettre en place contrairement au nombre de solutions de lutte contre les e-mails frauduleux existantes, souvent difficiles à tester et à mettre en œuvre.

Comment BIMI fonctionne ?

BIMI utilise un processus en plusieurs étapes pour valider les e-mails en s’assurant qu’ils sont réellement associés au nom de domaine de l’expéditeur. Les expéditeurs doivent ajouter un enregistrement DNS de type TXT dédié à BIMI.

Pour que BIMI fonctionne, les noms de domaine doivent également disposer de plusieurs autres protections contre la fraude, notamment :

  • SPF (Sender Policy Framework) : authentifie les e-mails en identifiant les serveurs de messagerie autorisés à envoyer à partir de noms de domaine spécifiques ;
  • DKIM (DomainKeys Identified Mail) : ajoute une signature numérique à chaque e-mail pour vérifier qu’il a été envoyé depuis un nom de domaine autorisé ;
  • DMARC (Domain-Based Message Authentication, Reporting, and Conformance) : confirme les enregistrements SPF et DKIM et spécifie comment les e-mails non conformes doivent être traités.

Lorsque des e-mails sont envoyés en utilisant BIMI, le serveur de messagerie de réception effectuera d’abord l’authentification DMARC/DKIM standard et la validation SPF. Si l’e-mail passe ces vérifications, le serveur de messagerie vérifiera s’il a un enregistrement BIMI valide et affichera le logo de la marque.

Comment BIMI interagit-il avec DMARC, DKIM et SPF ?

La première étape vers l’utilisation de BIMI pour afficher un logo consiste à mettre en œuvre DMARC. Ceci est stocké en tant qu’enregistrement DNS de type TXT sur le nom de domaine. Pour que DMARC fonctionne avec BIMI, la politique de rejet dans cet enregistrement doit être p=quarantine ou p=reject pour tous les e-mails envoyés depuis votre domaine.

BIMI nécessite DMARC… et DMARC nécessite que votre nom de domaine ait des enregistrements DKIM pour fonctionner. Si DMARC ne nécessite que SPF ou DKIM pour fonctionner, il est cependant préférable d’inclure des enregistrements SPF pour plus de sécurité lors de l’utilisation de BIMI. Ces 2 outils de sécurité sont également stockés sous forme d’enregistrements DNS TXT dans la zone du nom de domaine.

VMC, le dernier maillon de la chaîne

Un Verified Mark Certificate (ou « certificat de marque vérifié ») est un certificat numérique qui authentifie la propriété d’un logo, et qui vient compléter l’utilisation de BIMI dans les clients de messagerie tels que Gmail.

Le certificat VMC garantit l’authenticité du logo affiché, nécessairement propriété du titulaire du nom de domaine envoyant l’e-mail. C’est le dernier maillon de la chaîne pour garantir l’authenticité du mail reçu.

Lorsque vous envoyez un e-mail à un contact, le serveur de messagerie destinataire qui gère sa boîte de réception prendra l’URL de la balise qui indique où le logo doit être affiché. Il vérifiera ensuite le certificat VMC pour s’assurer que le bon logo est utilisé. Une fois le logo vérifié par le VMC, BIMI l’affichera à côté de l’e-mail dans la boîte de réception.

Pour obtenir un certificat VMC, l’implémentation de DMARC sur le nom de domaine est un prérequis. S’ensuit alors un processus d’authentification renforcé auprès d’une Autorité de Certification qui validera l’identité de l’Organisation, l’enregistrement du logo auprès d’un organisme certifié et délivrera le certificat à la suite d’un one to one devant un notaire.

Selon les pays, les offices d’enregistrement des logos peuvent varier ainsi que les règles d’acceptation pour émettre le certificat. Les notions à garder en tête, les marques déposées autorisées peuvent être :

  • Marques de dessins : composées uniquement d’un dessin ;
  • Marques verbales : contiennent des mots, des lettres et/ou des chiffres, sans police, taille, couleur ou style particulier ;
  • Marques combinées : inclure une combinaison de mots avec un dessin, des lettres stylisées ou des chiffres.

Bien que ce ne soit pas une exigence pour la mise en œuvre de BIMI sur votre nom de domaine pour le moment, VMC devrait faire partie de la norme à l’avenir.

Entrust Datacard et DigiCert sont les 2 premières sociétés à délivrer des certificats VMC pour la norme BIMI. Nameshield est partenaire des deux sociétés et vous accompagne pour l’obtention de certificats VMC. Vous pouvez contacter directement notre service certificats pour toute question sur le sujet.

BIMI + VMC = Garantie d’authenticité

BIMI, VMC… et Nameshield

Nameshield accompagne désormais ses clients sur tous les aspects de la mise en place des protocoles DMARC, SPF, DKIM, mais aussi BIMI et l’obtention des certificats VMC associés. Le nom de domaine est au cœur de la mise en place de ces différents protocoles. Notre métier historique de registrar et de gestionnaire de zones DNS nous permet aujourd’hui d’accompagner nos clients sur ces sujets majeurs de la lutte contre la fraude en ligne et d’augmentation de la désidérabilité des e-mails.