après avoir lu l'interview d'Octave Klaba ici :
http://minilien.fr/a0ppef je retiens que :
-1- les FAI seront sûrement écoutés de manière non discriminée ;
-2- les centres d'hébergements resteront sur une technique "normale", à
savoir des écoutes ciblées et pas permanentes.
Donc me vient une question : j'ai un serveur dédiés chez OVH, si je tire
un VPN de chez moi à ce serveur, puis-je éviter les écoutes massives ?
Même si AES est fiable, certaines attaques sont possibles. Dans certains cas dmcrypt offline est vulnérable à une attaque par malléabilité: http://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/
j'ai XTS, donc ça va ;)
Ensuite, lorsque tu allumes ta machine, tu ne bootes pas sur du chiffré, tu bootes sur /boot qui contient un noyau et un initrd en clair. Si on a modifié ce noyau et cet initrd pour keylogger ton mot de passe luks, c'est perdu.
oui tout à fait.
https://citp.princeton.edu/research/memory/ La RAM peut être lue, même après un arrêt brutal. Donc lorsque ta machine est allumée, tes containers sont ouverts et les clés sont en mémoire. OVH peut donc faire un arrêt brutal du serveur, lire les clés et déchiffrer tes containers.
je connaissais cette histoire aussi, mais là, il n'y a pas grand chose à faire.
Après, je ne connais pas l'infra OVH et la manière dont tu connectes, mais il peut y avoir encore pleins de failles: sniffer sur un KVM si tu en utilises un par exemple.
aussi.
Ceci étant dit, ça me conforte dans l'idée que certes, c'est faillible, mais il faut y mettre un minimum de moyen ou avoir compromis l'infrastructure en amont (keylogger dans l'initrd, machine compromise dès le départ, réseau compromis avant premier connexion chiffrée, ...).
Une idée de comment était architecturé la solution de lavabit ?
Merci de ces réponses ainsi qu'à Yannix (mail précédent).
Laurent
On 11/05/2015 16:39, Kevin Denis wrote:
Même si AES est fiable, certaines attaques sont possibles. Dans
certains cas dmcrypt offline est vulnérable à une attaque par malléabilité:
http://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/
j'ai XTS, donc ça va ;)
Ensuite, lorsque tu allumes ta machine, tu ne bootes pas sur du chiffré,
tu bootes sur /boot qui contient un noyau et un initrd en clair. Si on
a modifié ce noyau et cet initrd pour keylogger ton mot de passe luks,
c'est perdu.
oui tout à fait.
https://citp.princeton.edu/research/memory/
La RAM peut être lue, même après un arrêt brutal. Donc lorsque ta machine
est allumée, tes containers sont ouverts et les clés sont en mémoire.
OVH peut donc faire un arrêt brutal du serveur, lire les clés et déchiffrer
tes containers.
je connaissais cette histoire aussi, mais là, il n'y a pas grand chose à
faire.
Après, je ne connais pas l'infra OVH et la manière dont tu connectes, mais
il peut y avoir encore pleins de failles: sniffer sur un KVM si tu en
utilises un par exemple.
aussi.
Ceci étant dit, ça me conforte dans l'idée que certes, c'est faillible,
mais il faut y mettre un minimum de moyen ou avoir compromis
l'infrastructure en amont (keylogger dans l'initrd, machine compromise
dès le départ, réseau compromis avant premier connexion chiffrée, ...).
Une idée de comment était architecturé la solution de lavabit ?
Merci de ces réponses ainsi qu'à Yannix (mail précédent).
Même si AES est fiable, certaines attaques sont possibles. Dans certains cas dmcrypt offline est vulnérable à une attaque par malléabilité: http://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/
j'ai XTS, donc ça va ;)
Ensuite, lorsque tu allumes ta machine, tu ne bootes pas sur du chiffré, tu bootes sur /boot qui contient un noyau et un initrd en clair. Si on a modifié ce noyau et cet initrd pour keylogger ton mot de passe luks, c'est perdu.
oui tout à fait.
https://citp.princeton.edu/research/memory/ La RAM peut être lue, même après un arrêt brutal. Donc lorsque ta machine est allumée, tes containers sont ouverts et les clés sont en mémoire. OVH peut donc faire un arrêt brutal du serveur, lire les clés et déchiffrer tes containers.
je connaissais cette histoire aussi, mais là, il n'y a pas grand chose à faire.
Après, je ne connais pas l'infra OVH et la manière dont tu connectes, mais il peut y avoir encore pleins de failles: sniffer sur un KVM si tu en utilises un par exemple.
aussi.
Ceci étant dit, ça me conforte dans l'idée que certes, c'est faillible, mais il faut y mettre un minimum de moyen ou avoir compromis l'infrastructure en amont (keylogger dans l'initrd, machine compromise dès le départ, réseau compromis avant premier connexion chiffrée, ...).
Une idée de comment était architecturé la solution de lavabit ?
Merci de ces réponses ainsi qu'à Yannix (mail précédent).
