• L'agent GPG stocke le mot de passe de la clé en mémoire vive.
• Ce mot de passe est lui-même chiffré : un dump de l mémoire vive ne permet pas de le retrouver en clair.
• Néanmoins, la clé de chiffrement de ce mot de passe étant aussi en mémoire, on peut la retrouver et déchiffrer le mot de passe à partir d'un tel dump : en l'état, la protection apportée par le chiffrement est illusoire (la fonctionnalité est présentée comme pouvant servir à terme avec un TPM)
• La clé privée protégée par le mot de passe est-elle aussi stockée en mémoire vive?
  • Si oui, il est inutile stocker aussi le mot de passe, c'est absurde. J'en déduis que non
  • Si non, ça fait une petite protection contre attaquant peu probable qui aurait accès à la mémoire vive (accès très difficile à obtenir) mais pas au système de fichiers (accès a priori moins difficile).

Seald fournit :

• un SDK fournissant le chiffrement de bout en bout aux applications avec gestion des équipements (sous-identités associées à une identité principale) et des groupes pour partager l'information
• un séquestre stockant les clés de déchiffrement de chaque couple (information, utilisateur OU groupe), clés elles-mêmes chiffrées par le mot de passe utilisateur (le déchiffrement s'opère donc côté client)

Une interview du fondateur présente de manière claire ce dispositif et ses limites. La principale : la "racine de confiance" se résume au code exécuté. S'agissant d'applications web le plus souvent, la principale faille est donc la prise de contrôle du serveur web qui distribue l'application javascript aux clients.

Les TPM sont des composants stockant des clés, des "mesures" (hachés) et réalisant des opérations cryptographiques (chiffrement, signature, génération d'aléa ou de clés). L'espace de stockage est minimal : on y stocke des clés "maître" qui (dé)chiffrent d'autres clés, stockées sur le disque dur ou ailleurs. Les TPM peuvent prendre la forme de puces matérielles dédiées (HSM simples), d'un firmware intégré à la carte mère (Trustes Execution Environment) ou d'implémentations logicielles.

On peut s'en servir pour enregistrer une séquence de démarrage, où chaque composant de la chaîne, du bios à l'OS, mesure le suivant avant de lui passer la main. On peut ensuite témoigner de la séquence auprès d'un tiers (comparaison avec des valeurs de références), utiliser ces valeurs de référence pour autoriser ou bloquer le démarrage (authenticated boot) ou conditionner l'usage d'une clé à ces valeurs, typiquement pour déchiffrer un disque dur.

Le niveau de sécurité que ça permet d'atteindre est intéressant, mais :

• la complexité de mise en place semble assez grande (au moins sur Linux)
• ça apporte une sécurité contre un attaquant qui aurait accès au matériel mais en attaquant uniquement le logiciel (bios, bootloader, OS...). Un attaquant sophistiqué saura ajouter une puce matérielle et contourner ces protections. Le scénario d'attaque auquel ces mesures répondent est donc assez improbable.

Résultat : les cas d'usage me semblent limités pour le moment.

La machinerie k8s répartit des pods (groupe de conteneurs) sur des machines formant un cluster de façon à garantir la haute disponibilité. Les pods se composent en services pour mettre en œuvre une application complète. Tous ces objets et leurs droits d'accès sont gérés par k8s. Les failles peuvent permettre à un conteneur compromis de prendre le contrôle d'un pod, d'un node (machine physique ou virtuelle qui héberge les pods) ou d'objets k8s, voire du cluster complet). Xavier Mehrenberger présente tout ça puis 2 vecteurs d'attaque : helm (gestionnaire de paquets pour k8s), dans sa version 2, avait les droits d'administration du cluster mais n'effectuait par défaut aucune authentification, et la compromission d'images docker via le respository (parfois accessible en écriture) ou la liaison entre k8s et le repository (non chiffrée par défaut !)

Le filtrage du réseau entre les conteneurs doit être pris en charge par un network plugin (il en existe plusieurs, avec des fonctionnalités différentes). Guillaume Fournier examine la possibilité d'affiner les règles en contrôlant les processus de départ et/ou d'arrivée, et pas seulement les conteneurs, comme on le ferait à l'échelle d'un système avec un pare-feu classique.

Frédéric Raynal et Damien Aumaitre remarquent que kubernetes fonctionne comme un système d'exploitation, dont les processus seraient les pods (les threads les conteneurs), où le noyai est en charge de la bonne exécution de chacun et d'une juste répartition des ressources. Les modalités d'attaque classiques (compromission de processus, élévation de privilèges...) sont tout à fait transposable à cet environnement.

Les auteurs ont aussi donné une interview à nolimitsecu fin mars.

En France, la censure d'internet est ordonnée par la police (terrorisme), l'Arjel (jeux en ligne) et la justice (partage de la culture et des connaissances). Elle est faite au niveau du DNS par les 4 principaux fournisseurs d'accès à internet (FAI).
La montée en puissance du DNS over HTTPS compromet ce fonctionnement, les FAI ne jouant plus mécaniquement ce rôle de résolveur DNS.

Le Conseil d'État se prononçait sur la possibilité ou non d'héberger des données de santé sur le cloud Microsoft : il constate que Microsoft pourra être soumis à des requêtes des autorités américaines sans que les personnes ciblées n'aient aucun recours. Mais serait-il possible d'héberger les données chez Microsoft sans que Microsoft y ait accès, par exemple avec du chiffrement ? Non.

17. Toutefois, la Commission nationale de l'informatique et des libertés, dans les observations qu'elle a produites à la suite de la communication de la requête, estime, en l'état des informations dont elle dispose, que le risque d'une demande telle que celles mentionnées au point 15 ne peut être totalement écarté. En outre, il résulte de l'instruction que les mesures techniques mises en oeuvre par Microsoft ou susceptibles de l'être à brève échéance n'écartent pas toute possibilité pour cette entreprise d'accéder aux données traitées sous la responsabilité de la Plateforme des données de santé, en dépit des précautions, limitant ce risque, qui entourent le chiffrement dont elles font l'objet et le stockage des clés de chiffrement utilisées. Il ne peut ainsi être totalement exclu, sur le plan technique, que Microsoft soit amenée à faire droit à une demande des autorités américaines fondée sur l'article 702 du FISA, ce qui méconnaîtrait alors les articles 28 et 48 du règlement général sur la protection des données, cités au point 5, qui interdisent qu'un sous-traitant transfère des données à caractère personnel vers un pays tiers si ce n'est sur instruction du responsable du traitement ou en vertu d'une obligation prévue par le droit de l'Union européenne ou d'un Etat membre, et que puisse être reconnue ou rendue exécutoire une décision d'une autorité administrative d'un pays tiers exigeant d'un responsable du traitement ou d'un sous-traitant qu'il transfère ou divulgue des données à caractère personnel, sauf sous certaines conditions qui ne seraient en l'espèce pas remplies.

Le Conseil d'État prend acte de la décision du ministère de la Santé de mettre fin à l'hébergement des données de santé sur la plate-forme Microsoft d'ici 2 ans et décide donc de ne pas condamner ledit ministère à une action plus rapide.

Par défaut docker n'écoute pas sur le réseau. Mais quand l'API réseau est activée (par exemple pour un orchestrateur), par défaut il n'y pas d'authentification et les communications se font en clair (port 2375).

Si on est root dans un conteneur et que celui-ci a les capacités DAC_OVERRIDE (présente par défaut) et CAP_READ_SEARCH (absente par défaut), on peut modifier des fichiers arbitraires sur l'hôte, donc en prendre le contrôle (shocker).