Linux est open source. Le noyau peut être examiné. Les programmes peuvent être compilés indépendamment. Les pare-feu peuvent contrôler le trafic réseau entrant et sortant.
Du moins, c’est ce que nous avons tendance à supposer.
Pourtant, profondément sous le système d’exploitation, de nombreux systèmes Intel abritent un autre monde, largement invisible : l’Intel Management Engine, aujourd’hui intégrée à l’Intel Converged Security and Management Engine (CSME).
Elle fonctionne indépendamment du système d’exploitation principal, dispose de privilèges étendus et utilise un firmware propriétaire. Sur les systèmes compatibles, Intel Active Management Technology (AMT) permet même des communications réseau en dehors du système d’exploitation hôte normal.
Une question dérangeante se pose alors :
Un ordinateur peut-il réellement être considéré comme digne de confiance si son propriétaire ne peut pas contrôler tous les logiciels qui contrôlent son matériel ?
Un ordinateur dans l’ordinateur
L’Intel Management Engine n’est pas une application ordinaire fonctionnant sous Windows ou Linux.
Elle fait partie de la plateforme et fonctionne en dehors du système d’exploitation hôte normal.
De manière simplifiée, un PC ne ressemble donc pas seulement à ceci :
Applications
↓
Linux / Windows
↓
Noyau
↓
Matériel
Une représentation simplifiée plus proche de la réalité serait :
Applications
↓
Linux / Windows
↓
Noyau
↓
┌────────────┴────────────┐
│ │
CPU hôte ME / CSME
│ │
│ Firmware propre
│ │
└────────────┬────────────┘
↓
Matériel
Il existe donc un composant logiciel privilégié que l’utilisateur ordinaire ne peut pas contrôler comme un service classique.
C’est précisément ce qui le rend intéressant du point de vue de la sécurité.
MINIX dans la salle des machines
En 2017, une découverte a attiré beaucoup d’attention : certaines générations de l’Intel Management Engine utilisaient une version adaptée de MINIX 3.
MINIX n’est pas simplement un petit pilote matériel. Il s’agit d’un véritable système d’exploitation basé sur une architecture à micro-noyau.
Cela ne signifie pas que chaque PC Intel exécute une installation MINIX complète et ordinaire avec tous ses services habituels. Intel utilise un environnement firmware spécialement adapté.
Cette découverte permet néanmoins de comprendre l’ampleur du système.
Il ne s’agit pas simplement de quelques centaines d’octets de code d’initialisation.
Il s’agit d’un environnement d’exécution complexe situé profondément dans la plateforme.
Et elle peut communiquer
La situation devient particulièrement intéressante avec les systèmes Intel prenant en charge vPro et Active Management Technology (AMT).
AMT a été développé pour permettre l’administration à distance des ordinateurs d’entreprise.
Les administrateurs peuvent gérer des machines correctement configurées indépendamment du système d’exploitation normal. Selon la plateforme et sa configuration, les fonctions peuvent notamment inclure :
- l’allumage et l’extinction d’un ordinateur ;
- son redémarrage ;
- la consultation d’informations matérielles ;
- Serial over LAN ;
- KVM à distance ;
- la redirection de supports ou de stockage ;
- le diagnostic d’un ordinateur dont le système d’exploitation ne fonctionne plus.
C’est précisément le principe de la gestion hors bande, ou out-of-band management.
Le réseau d’une entreprise doit pouvoir atteindre un ordinateur même lorsque Windows ou Linux ne fonctionne plus.
De manière simplifiée :
Réseau
│
↓
Contrôleur réseau
/ \
/ \
↓ ↓
ME / AMT Système hôte
│ │
Administration Linux
│
Pare-feu
Pour les grandes entreprises, cette fonction peut être extrêmement utile.
Mais elle entraîne également une conséquence remarquable :
Toutes les formes de communication réseau disponibles sur une telle plateforme ne doivent pas nécessairement passer par la pile réseau du système d’exploitation hôte.
Un pare-feu Linux contrôle ce que Linux contrôle.
Il ne peut pas automatiquement garantir qu’un autre composant situé en dehors de son propre domaine de confiance ne communique pas.
Intel ME est-elle donc une porte dérobée ?
Non.
Du moins, aucune preuve publique concluante n’établit qu’Intel ME ait été développée comme une porte dérobée secrète destinée à un service de renseignement.
Une analyse sérieuse doit donc clairement distinguer :
les capacités démontrées
et
les conclusions que l’on pourrait en tirer.
Le fait qu’une technologie puisse théoriquement servir à la surveillance ou au sabotage ne prouve pas qu’elle ait été conçue ou qu’elle soit effectivement utilisée à cette fin.
Mais cela ne fait pas disparaître le problème fondamental.
Du point de vue de la sécurité informatique, une question plus profonde se pose :
Pourquoi devrais-je être obligé de faire confiance à Intel ?
La boîte noire dans votre propre ordinateur
Linux peut être examiné.
Le code source du noyau Linux est publiquement disponible.
Il en va de même pour GCC, Clang et d’innombrables autres composants d’un système d’exploitation libre.
En principe, leur code source peut être étudié, modifié et compilé indépendamment.
Avec un composant de plateforme propriétaire, la situation est différente.
Le propriétaire ne dispose pas automatiquement d’une chaîne entièrement vérifiable :
Code source
↓
Audit
↓
Compilation reproductible
↓
Binaire
↓
Firmware exécuté
Une boîte noire existe donc à l’intérieur de la base informatique de confiance, ou Trusted Computing Base.
Cela ne signifie expressément pas que quelque chose de malveillant s’y trouve nécessairement.
Cela signifie quelque chose de plus fondamental :
Le propriétaire ne peut pas vérifier indépendamment et complètement son absence.
L’ombre de Ken Thompson
Ce problème rappelle l’une des réflexions les plus célèbres de l’histoire de l’informatique.
Ken Thompson, l’un des créateurs d’Unix, décrivit en 1984 dans sa conférence « Reflections on Trusting Trust » une attaque d’une élégance inquiétante.
Imaginons un compilateur C manipulé.
Il reconnaît lorsqu’il compile un programme de connexion :
if compiling(login.c)
insert_backdoor();
Évidemment, un auditeur pourrait découvrir cette manipulation dans le code source du compilateur.
Thompson va donc plus loin.
Le compilateur manipulé reconnaît également lorsqu’il compile son propre code :
if compiling(compiler.c)
insert_compiler_backdoor();
Les deux manipulations peuvent alors être supprimées du code source visible.
Le compilateur reste pourtant infecté.
Lorsque le code source apparemment propre est recompilé, le compilateur déjà manipulé recrée un nouveau compilateur manipulé.
code source propre du compilateur
│
↓
ancien compilateur manipulé
│
↓
nouveau compilateur manipulé
│
↓
code source propre
│
↓
compilateur à nouveau manipulé
La porte dérobée finit par n’apparaître nulle part dans le code source visible.
Le message de Thompson dépassait largement cette attaque particulière :
Quelque part, la confiance doit commencer.
Et aujourd’hui, nous retrouvons ce problème au niveau du matériel.
L’Open Source ne suffit pas à lui seul
Même un système d’exploitation entièrement libre ne résout donc pas complètement le problème de confiance.
On peut avoir :
Firefox
↓
Open Source
Linux
↓
Open Source
GCC
↓
Open Source
coreboot
↓
largement Open Source
Mais sous ces couches peuvent toujours se trouver :
microcode du CPU
firmware du contrôleur SSD
firmware du contrôleur réseau
composants UEFI
TPM
processeurs de gestion
matériel lui-même
La question essentielle n’est donc pas seulement :
« Mon système d’exploitation est-il open source ? »
Mais plutôt :
Jusqu’où s’étend réellement ma chaîne de confiance vérifiable de manière indépendante ?
Pourquoi ME a-t-elle été développée ?
Intel dispose de cas d’utilisation techniquement compréhensibles pour une telle technologie.
Une entreprise possédant 30 000 postes de travail peut souhaiter administrer à distance une machine défaillante.
Un administrateur peut avoir besoin de l’allumer à distance.
Il peut devoir effectuer un diagnostic même lorsque Windows ne démarre plus.
La gestion hors bande est extrêmement utile dans ce type de situation.
Mais cela conduit à une nouvelle question :
Pourquoi une telle fonction doit-elle rester en grande partie une boîte noire propriétaire pour le propriétaire de la machine ?
L’administration à distance et l’Open Source ne sont pas techniquement incompatibles.
Une possibilité de désactivation contrôlée par le propriétaire serait également envisageable.
On pourrait par exemple imaginer :
Management Engine
[✓] Initialisation nécessaire de la plateforme
[ ] Administration à distance
[ ] Accès réseau
[ ] KVM
[ ] Redirection du stockage
[ ] Services de gestion supplémentaires
avec un interrupteur matériel ou une configuration du firmware contrôlée par le propriétaire.
À la place, une architecture a été créée dans laquelle certaines fonctions de la plateforme sont étroitement liées à un environnement firmware propriétaire.
Dans un modèle de sécurité où le propriétaire devrait constituer l’autorité de confiance suprême de son propre ordinateur, cette architecture mérite d’être examinée.
L’intéressant mode HAP
La discussion devient particulièrement intéressante avec un mécanisme connu sous le nom de HAP ou AltMeDisable.
HAP est associé à High Assurance Platform, c’est-à-dire à des systèmes particulièrement renforcés destinés à des environnements gouvernementaux.
Des chercheurs en sécurité ont découvert que certaines versions de ME possèdent un mécanisme permettant de désactiver une partie importante de ses fonctionnalités après l’initialisation nécessaire de la plateforme.
C’est remarquable.
Une question évidente se pose alors :
Si une ME réduite est utile pour des systèmes particulièrement sensibles, pourquoi le propriétaire ordinaire ne bénéficie-t-il pas du même niveau de contrôle officiellement pris en charge ?
Encore une fois, cela ne constitue pas une preuve de l’existence d’une porte dérobée.
Mais cela montre que la nécessité d’une Management Engine constamment active avec de nombreuses fonctionnalités est plus complexe que la simple affirmation :
« Techniquement, l’ordinateur ne peut pas fonctionner sans elle. »
Une hypothèse dérangeante
À ce stade, nous pouvons formuler une hypothèse plus large.
Elle doit explicitement être comprise comme une hypothèse, et non comme un fait établi.
Durant les premières décennies de l’industrie informatique, les systèmes d’exploitation et les principaux composants logiciels étaient très largement propriétaires.
Toute personne capable d’influencer un fabricant pouvait théoriquement influencer un logiciel installé sur des millions d’ordinateurs.
Le logiciel libre a changé ce modèle.
Linux peut être examiné par des milliers de développeurs.
Les manipulations peuvent être découvertes.
Les distributions peuvent compiler leurs logiciels indépendamment.
Les compilations reproductibles permettent de comparer les binaires.
Qu’est-ce qui pourrait alors devenir plus intéressant du point de vue d’un service de renseignement ?
Le système d’exploitation ?
Ou la couche située en dessous ?
Applications
↓
Open Source
↓
Linux
↓
Open Source
↓
────────────────────────────────
Frontière de confiance
────────────────────────────────
↓
Firmware propriétaire
↓
Management Engine
↓
Matériel
L’hypothèse serait la suivante :
Avec la généralisation des logiciels libres et vérifiables indépendamment, il pourrait être devenu de plus en plus intéressant pour des acteurs étatiques de chercher à exercer une influence sur les couches situées sous le système d’exploitation.
Une telle position serait extraordinairement puissante.
Mais existe-t-il des preuves ?
Pour Intel ME spécifiquement, aucune preuve publique concluante ne permet d’établir une telle affirmation.
En revanche, l’intérêt des États et des services de renseignement pour l’influence sur les infrastructures techniques est historiquement documenté.
Clipper Chip : lorsque la porte dérobée était officielle
Dans les années 1990, le gouvernement américain proposa le Clipper Chip.
Le concept prévoyait des communications chiffrées tout en permettant aux autorités, sous certaines conditions, d’accéder à des clés conservées auprès de tiers.
Aujourd’hui, on parlerait généralement de key escrow.
Le point essentiel est que la possibilité d’accès gouvernemental n’était pas une rumeur.
Elle faisait partie du concept.
Les « Crypto Wars » démontrent donc clairement une chose :
Les gouvernements et les services de renseignement ont un intérêt stratégique réel à disposer de mécanismes d’accès dans des technologies de communication largement utilisées.
Dual_EC_DRBG : lorsqu’un standard devient suspect
Des années plus tard, la question devint encore plus intéressante.
Le générateur cryptographique de nombres aléatoires Dual_EC_DRBG fut standardisé avec la participation de la NSA.
Les cryptographes remarquèrent rapidement une caractéristique étrange.
Certaines constantes utilisées par l’algorithme n’avaient pas d’explication transparente.
Si quelqu’un connaissait une relation mathématique particulière entre ces constantes, celle-ci pouvait potentiellement permettre une porte dérobée extrêmement puissante.
Après les révélations Snowden, les soupçons devinrent considérablement plus sérieux.
Cet exemple est important, car une attaque ne doit pas nécessairement ressembler à ceci :
NSA_BACKDOOR = true;
Elle peut se présenter sous la forme d’une décision technique, d’un choix de paramètres ou même d’un standard industriel.
Puis vint Stuxnet
L’importance stratégique des systèmes informatiques devint encore plus évidente avec Stuxnet.
Ce logiciel malveillant fut spécifiquement utilisé contre des installations iraniennes d’enrichissement d’uranium.
Il manipulait des systèmes de contrôle industriels et influençait ainsi des machines physiques.
Il démontra que :
Logiciel
↓
Système de contrôle
↓
Installation industrielle
↓
Effet physique
Les cyberattaques ne servent pas uniquement à voler des informations.
Elles peuvent manipuler et endommager des infrastructures physiques.
Stuxnet n’avait pas besoin d’une porte dérobée universelle Intel démontrée pour y parvenir.
Il ne doit donc pas être interprété comme une preuve concernant Intel.
Il démontre quelque chose de plus général :
Les États possèdent à la fois l’intérêt et les ressources nécessaires pour attaquer des chaînes techniques complexes à des fins stratégiques.
Que savons-nous — et que supposons-nous ?
À ce stade, une distinction claire est nécessaire.
Éléments bien établis
- Intel ME/CSME est un environnement firmware privilégié.
- Des parties importantes sont propriétaires.
- Certaines générations ont utilisé MINIX 3.
- Intel AMT permet une gestion hors bande sur les plateformes compatibles et correctement configurées.
- Cette gestion peut fonctionner indépendamment du système d’exploitation hôte normal.
- Des vulnérabilités de sécurité importantes ont été découvertes dans ME/CSME.
- Certaines plateformes disposent de mécanismes permettant de réduire ou de désactiver une partie importante des fonctions de ME.
- Les services de renseignement ont historiquement tenté d’influencer la cryptographie et des standards techniques.
- Les États mènent des opérations cyber offensives.
- La manipulation des logiciels et des chaînes d’approvisionnement techniques constitue un scénario d’attaque réel.
Éléments non établis
Il n’existe pas de preuve publique concluante démontrant :
- qu’Intel ME ait été développée à la demande de la NSA ;
- qu’Intel ME contienne une porte dérobée secrète universelle destinée aux services de renseignement ;
- que les services de renseignement puissent contrôler arbitrairement des ordinateurs Intel par l’intermédiaire de ME ;
- qu’Intel ME ait été développée pour saboter des États étrangers.
Cette distinction est importante.
Car une critique sérieuse de la sécurité n’a besoin d’aucune de ces affirmations.
Le véritable problème est la confiance
Supposons un instant qu’Intel soit parfaitement digne de confiance.
Supposons également qu’aucun service de renseignement n’ait jamais influencé la Management Engine.
Le problème fondamental demeure.
Le propriétaire ne peut pas vérifier indépendamment tout ce que font tous les composants privilégiés présents dans sa machine.
La question change donc.
Ce n’est plus :
« Intel ME est-elle une porte dérobée de la NSA ? »
Mais :
« Pourquoi un ordinateur sécurisé devrait-il nécessiter une boîte noire privilégiée que son propriétaire ne peut pas entièrement contrôler ? »
C’est la question la plus forte.
Elle ne nécessite aucune théorie du complot.
Elle nécessite simplement une certaine conception de la propriété et de la sécurité informatique.
À qui appartient la racine de confiance ?
Notre conception habituelle de la propriété est simple :
Si j’achète un ordinateur, il m’appartient.
Techniquement, la situation est plus complexe.
Je peux contrôler :
mes fichiers
mes applications
mon système Linux
mon noyau
mon pare-feu
Mais peut-être pas entièrement :
le microcode du CPU
le firmware de gestion
le firmware du SSD
le firmware réseau
les clés Secure Boot
la racine de confiance matérielle
Une question fondamentale se pose alors pour l’avenir de l’informatique :
La racine de confiance doit-elle appartenir au fabricant — ou au propriétaire de l’appareil ?
Les fabricants invoquent l’intégrité, la protection contre les logiciels malveillants, les DRM, l’administration d’entreprise et la stabilité de la plateforme.
Du point de vue du propriétaire, on peut cependant défendre une autre position :
Un mécanisme de sécurité que je ne peux pas contrôler protège peut-être le système — mais il ne fait pas entièrement partie de mon modèle de confiance.
L’attaque parfaite pourrait ne jamais être découverte
Et nous revenons ainsi à Ken Thompson.
La porte dérobée la plus dangereuse ne serait pas nécessairement celle que des chercheurs finiraient par découvrir.
La porte dérobée parfaite serait celle dont l’existence ne pourrait pas être déduite de manière fiable à partir du système visible.
C’est précisément pour cette raison que l’expérience de pensée de Thompson a eu une telle influence.
Elle montrait :
Le code source seul ne prouve pas ce qu’un ordinateur fait réellement.
Quatre décennies plus tard, cette idée est peut-être plus pertinente que jamais.
Les ordinateurs modernes ne sont plus simplement constitués d’un CPU, de mémoire vive et d’un système d’exploitation.
Ils sont constitués d’un écosystème de processeurs et de composants firmware interdépendants.
Utilisateur
│
▼
Applications
│
▼
Linux
│
▼
Noyau
│
▼
Firmware
/ | \
/ | \
CSME SSD NIC
\ | /
\ | /
▼
Microcode
│
▼
CPU
│
▼
Matériel physique
Chaque couche étend la chaîne de confiance.
Et chaque couche impossible à vérifier indépendamment exige de la confiance.
La sécurité commence par le contrôle
La question la plus importante n’est donc peut-être pas :
« Mon ordinateur possède-t-il une porte dérobée ? »
Avec une porte dérobée suffisamment bien dissimulée, cette question pourrait ne jamais recevoir de réponse définitive.
Une meilleure question serait :
« Quels composants de mon ordinateur suis-je obligé de croire aveuglément ? »
Plus cette liste s’allonge, moins le propriétaire peut établir indépendamment la sécurité de son propre système.
Indépendamment de toute hypothèse concernant les services de renseignement, Intel ME constitue donc un exemple fascinant d’un problème fondamental de l’architecture informatique moderne.
Nous avons accompli d’énormes progrès grâce au logiciel libre.
Nous pouvons examiner les systèmes d’exploitation.
Nous pouvons comparer les compilateurs.
Nous pouvons produire des compilations reproductibles.
Nous pouvons analyser le trafic réseau.
Mais cette transparence finit par atteindre une frontière.
Au-delà de cette frontière commence un firmware que nous n’avons pas écrit, que nous ne pouvons pas entièrement vérifier et que, dans certains cas, nous ne pouvons pas supprimer.
La question décisive concernant la sécurité d’un ordinateur moderne n’est donc peut-être pas de savoir à quel système d’exploitation nous faisons confiance.
Elle est plutôt :
Qui contrôle la couche la plus profonde de la machine ?
Car celui qui contrôle cette couche détermine en fin de compte à qui l’ordinateur obéit réellement.