Skip to main content

Le problème avec « les sept clés »

De temps à autre, des articles sur « les sept personnes qui contrôlent l'accès à l'Internet » sont publiés. Ces articles, bien que probablement bien intentionnés, sont complètement incorrects. Soyons donc très clairs : il n'y a pas de clés qui entraînent le fonctionnement de l'Internet (ou le non-fonctionnement).

Les prétendues « clés pour l'Internet » ne concernent qu'une seule fonction, et même dans ce cas, elle ne peuvent être utilisées que dans des cas extrêmement limités. Il est important de comprendre à quoi consistent ces clés pour voir pourquoi elles ne contrôlent pas l'Internet.

D'abord et avant tout, les clés dont on parle  n'appartiennent qu'à une partie unique de l'Internet – le mécanisme permettant d'authentifier les données dans le système des noms de domaine (DNS), dénommé DNSSEC. Ce mécanisme repose sur une hiérarchie de clés cryptographiques commençant à la racine du DNS. Les clés cryptographiques pour la racine du DNS sont gérées par l'ICANN.

Ces clés cryptographiques sont déposées dans deux installations sécurisées à plus de 4000 kilomètres de distance, et sont protégées par plusieurs couches de sécurité physique telles que la sécurité des bâtiments, des caméras, des cages et des coffre-forts surveillés. La couche la plus secrète de la sécurité physique est un appareil spécialisé dénommé module matériel de sécurité (HSM), où sont entreposées les clés cryptographiques actuelles. Un module HSM résiste aux altérations physiques. Par exemple, si quelqu'un tente d'ouvrir le système ou même de le faire tomber, le HSM efface toutes les clés entreposées afin d'éviter toute atteinte à son intégrité. Dans chaque installation, l'ICANN dispose de deux HSM.

La clé cryptographique de la zone racine ne peut pas être utilisée en dehors d'un HSM. Le système qui a été conçu pour opérer un HSM requiert le présence de beaucoup de gens. Parmi eux, certains sont des membres de la communauté technique du monde entier, connus sous le nom de représentants de confiance de la communauté , et d'autres appartiennent au personnel de l'ICANN. Chaque personne joue un rôle spécifique dans l'activation de l'HSM, qui a lieu au cours d'un événement régulier que nous appelons une  « cérémonie de clés ».

Mais que se passe-t-il si les HSM devenaient inutilisables à cause d'un événement quelconque (par exemple, un bogue catastrophique dans le micrologiciel) ? Même ce scénario, extrêmement improbable, a besoin d'un plan de relance. Dans ce cas, l'ICANN possède une sauvegarde pour chaque clé de la racine, sous forme hautement chiffrée, dans un coffre-fort situé dans chacune des installations sécurisées. En cas d'incident dans les quatre HSM, l'ICANN pourrait acheter un nouveau HSM au même fabricant et restaurer les clés de la racine à l'aide de la sauvegarde. Dans ce scénario, notre politique de sécurité exige des représentants de confiance de la communauté supplémentaires pour restaurer les sauvegardes détenues par l'ICANN.

C'est là que de nombreux articles parlant « des clés de l'Internet » racontent la mauvaise histoire. Chacun des représentants de confiance de la communauté reçoit une clé physique (des clés métalliques ou des cartes à puce) qui est utilisée au cours de la cérémonie de clés. Le type de clés physiques dépend de leur rôle spécifique. Certains représentants de confiance de la communauté sont sélectionnés comme « Agents cryptographiques » qui activent les HSM lors des cérémonies de routine. D'autres sont sélectionnés comme « détenteurs des clés de reprise » qui activent la sauvegarde dans le scénario de récupération après le sinistre. Dans les deux cas, la clé physique détenue par  ces représentants sert uniquement à activer les informations qui sont stockées dans l'installation sécurisée et ne contiennent pas les clés cryptographiques de la zone racine. À elles seules et sans avoir accès aux installations sécurisées de l'ICANN, les clés ne peuvent pas être utilisées pour accéder à la clé de la racine protégée. Pour ce faire, tous les représentants devront se trouver à l'intérieur de l'installation sécurisée et le coffre-fort détenant les cartes à puce de sauvegarde devra être ouvert. À moins que toutes les couches multiples de sécurité physique tombent en panne, ce scénario ne peut avoir lieu qu'au cours d'une cérémonie de clés déjà prévue.

L'autre problème avec l'histoire des clés, c'est que l'Internet est beaucoup plus que DNSSEC. L'Internet se compose de nombreux systèmes différents, et le DNS n'en est qu'un. Contrôler un aspect de l'Internet, comme DNSSEC, n'amène pas à un contrôle total des autres aspects.

Ainsi, la prochaine fois que vous lirez un article sur les « sept personnes qui contrôlent les clés de l'Internet », vous saurez que les représentants de confiance de la communauté rendent un service précieux, mais pour une opération très limitée.

Comments

    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."