Catégorie : standardisation

En visitant le blog de Bruce Schneier, je suis tombé sur un long et intéressant article : How to Remain Secure Against the NSA
Je vais me concentrer sur les 5 points, traduits ici :

1. Caché dans le réseau. Implémentez des services cachés. Utilisez TOR pour protéger votre anonymat. Oui, la NSA cible les utilisateurs de TOR, mais cela est efficace sur eux. Moins vous serez à découvert, plus vous serez en sécurité.
2. Chiffrez vous communications. Utilisez TLS. Utilisez IPsec. Encore une fois, bien qu’il soit vrai que la NSA cible les communications chiffrées (et ils connaissent peut-être des failles spécifiques contre ces protocoles), vous serez bien mieux protégés que si vous communiquez en clair.
3. Prenez pour acquis que, bien que votre ordinateur puisse être compromis, cela nécessite du travail et représente un risque pour la NSA (donc il ne l’est probablement pas). Si vous avez quelque chose de vraiment important, utilisez un transfert par un moyen déconnecté. Depuis que j’ai commencé à travailler avec les documents de Mr Snowden, j’ai acheté un nouvel ordinateur qui n’a jamais été connecté à internet. Si je veux transférer un fichier, je chiffre le fichier sur l’ordinateur sécurisé puis l’emmène à pied jusqu’à mon ordinateur sur internet, sur une clé USB. Pour déchiffre quelque chose, j’inverse le processus. Cela ne doit pas être infaillible, mais suffisamment bon.
4. Soyez méfiants envers les logiciels de chiffrement commerciaux, spécialement des grands éditeurs. Mon avis, c’est que la plupart des produits de chiffrement des grandes entreprises US ont des portes dérobées pour la NSA, et il est probable que les entreprises étrangères fassent de même. Il est prudent de considérer que les équipements étrangers aient aussi des portes dérobées pour une puissance étrangère. Il est plus facile pour la NSA de placer une porte dérobée dans un logiciel à sources fermées que dans un autre aux sources ouvertes. Les systèmes reposants sur un important secret sont vulnérables à la NSA, que ce soit pour leurs activités légales ou plus clandestines.
5. Essayez d’utiliser des algorithmes de chiffrements dans le domaine public qui nécessitent d’être compatibles avec d’autres implémentations. Par exemple, il est plus difficile pour la NSA de placer une porte dérobée dans TLS que dans BitLocker. Parce que tous les implémentations de TLS doivent être compatibles entre elles alors que BitLocker ne doit être compatible qu’avec lui-même, donnant à la NSA plus de libertés pour apporter des changements. Et parce que BitLocker est propriétaire, il est beaucoup moins probable que ces changements soient découverts. Préférez la cryptographie symétrique plutôt que la cryptographie à clé publique. Préférez les systèmes conventionnels à logarithmes discrets plutôt que les systèmes à courbes elliptiques. Ces derniers ont des constantes que la NSA influence dès qu’elle le peut.

Petite remarque sur ce qui semble une incohérence. Il cite au point 4 d’essayer d’utiliser des logiciels à sources ouvertes. Et il dit utiliser plus bas un ordinateur sous M$ Windows : « And I’m still primarily on Windows, unfortunately. Linux would be safer. »
L’aveu est franc. Je pense que l’explication est simple, il se sent plus à même de sécuriser un système qu’il connaît bien plutôt qu’un système inconnu. Ça se défend.

Confrontons donc maintenant le projet nebule et ces cinq points :

1. Le projet nebule, une fois diffusé, peut être hébergé partout sur le réseau. Par défaut, les entités ont des emplacements connus. Mais rien n’empêche une entité d’avoir un emplacement dont l’objet contenant est chiffré, et l’URL d’une forme difficile à deviner même si on connaît le serveur. Par contre, si les objets et liens d’une entité sont échangés avec une autre entité, elle se retrouve à découvert sur d’autres emplacements. Ceci ne devrait cependant arrivé que si des liens relient ces objets aux deux entités. Le chiffrement des objets la seule parade définitive, ce qui est logique. L’anonymisation tel que proposé par TOR n’a pas de sens dans nebule.
2. Dans nebule, on a le choix. Rien n’empêche de chiffrer toutes les informations vitales et de placer les liens suspects dans des objets chiffrés. Ce dernier point n’est pas encore implémenté mais est prévu et est techniquement réalisable. Utiliser TLS est recommandé au risque de révéler les liens et objets échangés, et donc d’affaiblir l’anonymisation.
3. Le risque de l’ordinateur compromis est assez actuel malheureusement. Tant qu’un système ne sera pas intégralement nébulisé, le projet nebule n’apportera pas grand chose à ce niveau. On peut cependant profiter de la signature native des objets contre la modification malveillante. Par contre, nebule permet assez facilement de faire des échanges à sens unique, via des relais d’isolation, et via des supports amovibles. Et le chiffrement peut être entièrement réalisé sur un ordinateur isolé, même à destination d’une autre entité.
4. Pour résumer, il faut utiliser des logiciels open sources et qui ne sont pas restreints à un seul éditeur dans leur utilisation. Le projet nebule par dès le début avec un choix d’utilisation par défaut de logiciels libres (et open sources). Ceux retenus sont très utilisés, et donc très régulièrement vérifiés. L’inter-opérabilité avec d’autres systèmes et implémentations est aussi à ce prix.
5. Le début a les mêmes réponses que pour le point 4. Il est impossible de gérer des entités avec la cryptographie symétrique. La cryptographie asymétrique est irremplaçable. Mais il ne faut pas utiliser ces algorithmes pour faire des choses pour lesquels ils ne sont pas prévus. Par contre, si l’algorithme à logarithmes discrets est principalement utilisé aujourd’hui, tout algorithme peut être utilisé en parallèle ou en remplacement. Cela n’a pas d’importance structurelle forte. Le projet nebule s’appuie sur la cryptographie asymétrique pour les signatures et chiffrements (pour les clés de sessions).

Liens :
– https://www.schneier.com/blog/archives/2013/09/how_to_remain_s.html