Chiffrement des sauvegardes
6 views
Skip to first unread message
Laurent Caillette
Jan 26, 2015, 3:44:03 AM1/26/15
to tec...@googlegroups.com
En application de la règle bien connue qu'il n'y a que les centres de
données des autres qui brûlent, on prendra soin de conserver toutes
ses sauvegardes sur le même site afin de bien montrer que la loi de
Murphy c'est que pour les flippés du bulbe. Non c'était une blague.
Une politique de sauvegarde sérieuse implique une réplication des
données à plus de 200 km de leur lieu d'origine, ça correspond au
diamètre du plus grand cercle où s'inscrivent la plupart des
sinistres. Pour éviter que n'importe qui puisse altérer ou simplement
relire les sauvegardes, on prendra soin de les chiffrer, surtout avant
une conservation quelque part dans le nuage.
Comment chiffrer ? Si on utilise toujours la même clé, un attaquant
qui casse le chiffrement d'une sauvegarde pourra lire toutes les
sauvegardes futures. Si on génère une clé par sauvegarde, il faut
ensuite conserver ces clés quelque part, de préférence sous forme
chiffrée, et tant qu'on y est sur un site différent, ce qui nous
ramène au problème initial. Zut.
D'un côté on voudrait une **clé maître** pour chiffrer, mais de
l'autre on voudrait réduire la surface d'attaque avec une clé
différente pour chaque sauvegarde. Il faudrait aussi que la clé maître
puisse changer de temps en temps si on pense qu'elle est compromise,
mais qu'on puisse quand même relire les sauvegardes précédentes. Le
beurre et l'argent du beurre, quoi.
Oh et puis tant qu'on y est, on voudrait se garder la possibilité
d'utiliser une clé maître pour le chiffrement qui soit différente de
celle pour le déchiffrement. Ça permet par exemple un dépôt chez un
tiers de confiance. Ou, dans le cas d'un prestataire un peu curieux
qui vient effectuer une opération ponctuelle sur le serveur, ça limite
l'exposition des données à celles qui n'ont pas encore été
sauvegardées (dans l'hypothèse réaliste où on efface ces données après
leur sauvegarde, et où le serveur dispose de l'accès en lecture au
site de sauvegardes). Après le beurre et l'argent du beurre, nous
voilà en train d'exiger l'accès exclusif à la crémière. Est-ce bien
raisonnable ?
=== Principe de chiffrement et déchiffrement
Considérons un **portefeuille de clés maîtres** qui contient toutes
les clés déjà utilisées. Si on veut séparer la capacité de chiffrement
de celle de déchiffrement, il suffit d'avoir deux portefeuilles. À
chaque clé maître on associe un **identifiant de clé maître** ; s'il y
a deux portefeuilles, cet identifiant permet d'effectuer la
correspondance.
Pour effectuer une sauvegarde, nous générons aléatoirement une clé
symétrique. Nous l'appellerons **clé d'enveloppe**. À cette clé
d'enveloppe nous associons l'identifiant de clé maître. La sauvegarde
est chiffrée avec la clé d'enveloppe, et la clé d'enveloppe est
chiffrée avec la clé maître publique en vigueur. Puis aux données
chiffrées nous associons les métadonnées suivantes : l'identifiant de
clé maître, et la clé d'enveloppe chiffrée avec la clé maître. La
sauvegarde (données chiffrées accompagnées de leurs métadonnées) peut
maintenant voyager dans son enveloppe cryptographique sans risque
d'être lue ou altérée. Pour cette étape, on aurait peut-être un
résultat cryptographiquement équivalent sans passer par la clé
symétrique, mais le chiffrement symétrique va beaucoup plus vite. Les
protocoles comme TLS ou SSH font pareil, ils échangent une clé
symétrique aléatoire chiffrée asymétriquement.
Comment se passe le déchiffrement ? L'identifiant de clé maître dans
les métadonnées permet de retrouver la clé maître de déchiffrement.
Celle-ci permet de déchiffrer la clé d'enveloppe, et c'est avec la clé
d'enveloppe déchiffrée qu'on déchiffre les données d'origine.
On a bien toutes les propriétés souhaitées. Si une attaque sur la clé
d'enveloppe permet de déchiffrer une sauvegarde, l'attaquant devra
refaire le boulot pour les autres sauvegardes. Si l'attaquant essaye
de casser la clé maître, il dispose d'une surface d'attaque très
réduite car la clé d'enveloppe est complètement aléatoire, très courte
et de taille fixe. Et même s'il parvient à casser une clé maître, un
changement périodique limitera le gain de l'attaquant à la période de
validité de la clé maître. Le changement de clé maître sur
intervention manuelle, à une période raisonnable (disons tous les six
mois) réduit suffisamment le problème de la sauvegarde automatique des
clés.
=== Mise en œuvre avec Amazon S3
Comme dit Linus Torvalds : "Parler ne coûte pas cher, montrez-moi le
code !" Cette mécanique de chiffrement est intégralement disponible
dans l'API Java d'Amazon S3. Le code source est disponible sur github,
il s'appuie sur les API de cryptographie standard. Gardons à l'esprit
que :
- La bibliothèque en question est complètement liée à l'API d'AWS
(Amazon Web Services), notamment pour la manipulation de métadonnées.
- Il faut activer les JCE (Java Cryptographic Extensions).
La documentation d'AWS reprend tous ces mécanismes en détail, on
commencera par l'article "Client-Side Data Encryption with the AWS SDK
for Java and Amazon S3"
http://aws.amazon.com/articles/2850096021478074
Cela dit, un vrai dispositif de sauvegarde automatisé nécessite
beaucoup de boulot. Par exemple il faut supporter divers scénarios de
reprise sur panne, récupérer la bonne clé maître dans le keystore de
l'application, calculer des sommes de contrôle, configurer des droits
sur AWS... Ce dernier point n'est d'ailleurs pas de tout repos. Après
faut savoir si on veut des sauvegardes automatisées, ou si on laisse
les pessimistes se faire du mal avec.
(Merci à Jacques T. d'avoir mentionné un jour cette fonctionnalité
d'Amazon S3, que ce billet se contente de décrire.)
=== Mise en œuvre avec des outils Unix
Grâce à des outils comme bzip2, gpg et dd, il y a moyen de graver des
DVD avec toutes les fonctionnalités cryptographiques décrites
précédemment. Ça peut être sympa pour des sauvegardes de code source
par exemple.
Hélas je n'ai rien trouvé de tout prêt qui fasse ça. Si quelqu'un
connaît une solution ça m'intéresse.
données des autres qui brûlent, on prendra soin de conserver toutes
ses sauvegardes sur le même site afin de bien montrer que la loi de
Murphy c'est que pour les flippés du bulbe. Non c'était une blague.
Une politique de sauvegarde sérieuse implique une réplication des
données à plus de 200 km de leur lieu d'origine, ça correspond au
diamètre du plus grand cercle où s'inscrivent la plupart des
sinistres. Pour éviter que n'importe qui puisse altérer ou simplement
relire les sauvegardes, on prendra soin de les chiffrer, surtout avant
une conservation quelque part dans le nuage.
Comment chiffrer ? Si on utilise toujours la même clé, un attaquant
qui casse le chiffrement d'une sauvegarde pourra lire toutes les
sauvegardes futures. Si on génère une clé par sauvegarde, il faut
ensuite conserver ces clés quelque part, de préférence sous forme
chiffrée, et tant qu'on y est sur un site différent, ce qui nous
ramène au problème initial. Zut.
D'un côté on voudrait une **clé maître** pour chiffrer, mais de
l'autre on voudrait réduire la surface d'attaque avec une clé
différente pour chaque sauvegarde. Il faudrait aussi que la clé maître
puisse changer de temps en temps si on pense qu'elle est compromise,
mais qu'on puisse quand même relire les sauvegardes précédentes. Le
beurre et l'argent du beurre, quoi.
Oh et puis tant qu'on y est, on voudrait se garder la possibilité
d'utiliser une clé maître pour le chiffrement qui soit différente de
celle pour le déchiffrement. Ça permet par exemple un dépôt chez un
tiers de confiance. Ou, dans le cas d'un prestataire un peu curieux
qui vient effectuer une opération ponctuelle sur le serveur, ça limite
l'exposition des données à celles qui n'ont pas encore été
sauvegardées (dans l'hypothèse réaliste où on efface ces données après
leur sauvegarde, et où le serveur dispose de l'accès en lecture au
site de sauvegardes). Après le beurre et l'argent du beurre, nous
voilà en train d'exiger l'accès exclusif à la crémière. Est-ce bien
raisonnable ?
=== Principe de chiffrement et déchiffrement
Considérons un **portefeuille de clés maîtres** qui contient toutes
les clés déjà utilisées. Si on veut séparer la capacité de chiffrement
de celle de déchiffrement, il suffit d'avoir deux portefeuilles. À
chaque clé maître on associe un **identifiant de clé maître** ; s'il y
a deux portefeuilles, cet identifiant permet d'effectuer la
correspondance.
Pour effectuer une sauvegarde, nous générons aléatoirement une clé
symétrique. Nous l'appellerons **clé d'enveloppe**. À cette clé
d'enveloppe nous associons l'identifiant de clé maître. La sauvegarde
est chiffrée avec la clé d'enveloppe, et la clé d'enveloppe est
chiffrée avec la clé maître publique en vigueur. Puis aux données
chiffrées nous associons les métadonnées suivantes : l'identifiant de
clé maître, et la clé d'enveloppe chiffrée avec la clé maître. La
sauvegarde (données chiffrées accompagnées de leurs métadonnées) peut
maintenant voyager dans son enveloppe cryptographique sans risque
d'être lue ou altérée. Pour cette étape, on aurait peut-être un
résultat cryptographiquement équivalent sans passer par la clé
symétrique, mais le chiffrement symétrique va beaucoup plus vite. Les
protocoles comme TLS ou SSH font pareil, ils échangent une clé
symétrique aléatoire chiffrée asymétriquement.
Comment se passe le déchiffrement ? L'identifiant de clé maître dans
les métadonnées permet de retrouver la clé maître de déchiffrement.
Celle-ci permet de déchiffrer la clé d'enveloppe, et c'est avec la clé
d'enveloppe déchiffrée qu'on déchiffre les données d'origine.
On a bien toutes les propriétés souhaitées. Si une attaque sur la clé
d'enveloppe permet de déchiffrer une sauvegarde, l'attaquant devra
refaire le boulot pour les autres sauvegardes. Si l'attaquant essaye
de casser la clé maître, il dispose d'une surface d'attaque très
réduite car la clé d'enveloppe est complètement aléatoire, très courte
et de taille fixe. Et même s'il parvient à casser une clé maître, un
changement périodique limitera le gain de l'attaquant à la période de
validité de la clé maître. Le changement de clé maître sur
intervention manuelle, à une période raisonnable (disons tous les six
mois) réduit suffisamment le problème de la sauvegarde automatique des
clés.
=== Mise en œuvre avec Amazon S3
Comme dit Linus Torvalds : "Parler ne coûte pas cher, montrez-moi le
code !" Cette mécanique de chiffrement est intégralement disponible
dans l'API Java d'Amazon S3. Le code source est disponible sur github,
il s'appuie sur les API de cryptographie standard. Gardons à l'esprit
que :
- La bibliothèque en question est complètement liée à l'API d'AWS
(Amazon Web Services), notamment pour la manipulation de métadonnées.
- Il faut activer les JCE (Java Cryptographic Extensions).
La documentation d'AWS reprend tous ces mécanismes en détail, on
commencera par l'article "Client-Side Data Encryption with the AWS SDK
for Java and Amazon S3"
http://aws.amazon.com/articles/2850096021478074
Cela dit, un vrai dispositif de sauvegarde automatisé nécessite
beaucoup de boulot. Par exemple il faut supporter divers scénarios de
reprise sur panne, récupérer la bonne clé maître dans le keystore de
l'application, calculer des sommes de contrôle, configurer des droits
sur AWS... Ce dernier point n'est d'ailleurs pas de tout repos. Après
faut savoir si on veut des sauvegardes automatisées, ou si on laisse
les pessimistes se faire du mal avec.
(Merci à Jacques T. d'avoir mentionné un jour cette fonctionnalité
d'Amazon S3, que ce billet se contente de décrire.)
=== Mise en œuvre avec des outils Unix
Grâce à des outils comme bzip2, gpg et dd, il y a moyen de graver des
DVD avec toutes les fonctionnalités cryptographiques décrites
précédemment. Ça peut être sympa pour des sauvegardes de code source
par exemple.
Hélas je n'ai rien trouvé de tout prêt qui fasse ça. Si quelqu'un
connaît une solution ça m'intéresse.
Nicolas Meier
Jan 26, 2015, 5:38:39 AM1/26/15
to tec...@googlegroups.com
Pour ce qui est de l'encryption côté client et de la configuration des
droits AWS, il y a Arq sur Mac qui est vraiment pas mal.
Je l'utilise depuis un an pour des sauvegardes sur S3.
http://www.haystacksoftware.com/arq/
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes
> techos.
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le
> concernant, envoyez un e-mail à l'adresse
> techos+un...@googlegroups.com.
> Pour envoyer un message à ce groupe, adressez un e-mail à
> tec...@googlegroups.com.
> Visitez ce groupe à l'adresse http://groups.google.com/group/techos .
> Pour plus d'options, visitez le site https://groups.google.com/d/optout .
droits AWS, il y a Arq sur Mac qui est vraiment pas mal.
Je l'utilise depuis un an pour des sauvegardes sur S3.
http://www.haystacksoftware.com/arq/
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes
> techos.
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le
> concernant, envoyez un e-mail à l'adresse
> techos+un...@googlegroups.com.
> Pour envoyer un message à ce groupe, adressez un e-mail à
> tec...@googlegroups.com.
> Visitez ce groupe à l'adresse http://groups.google.com/group/techos .
> Pour plus d'options, visitez le site https://groups.google.com/d/optout .
Reply all
Reply to author
Forward
0 new messages