Sans compter que le CPU ne peut pas savoir si une suite de donnée c'est de l'aléas ou pas.
Les CPU modernes possèdent leurs propres générateurs aléatoires. Si ceux-ci sont plombés, il y a moyen de faire des trucs rigolos.
Euh pas vraiment besoin, vu que la norme dis "il faut que des clés non-migrables soit migrables".
Les psecs insistent aussi lourdement sur le fait qu'avant de lancer uen procédure de migration ou de maintenance le TPM doit s'assurer de la présence physique de l'opérateur.
Ensuite les specs insistent aussi lourdement sur le fait que les clefs non migrables sont à usage strictement interne (en d'autres termes ce sont des clefs qui sont utilisés par le TPM pour le chiffrement en interne et elles ne doivent en aucun cas interagir avec des demandes de chiffrement ou du déchiffrement venant de l'extérieur)
Toutes les clefs utilisables par les profils TPM sont migrables.
Donc déjà on migre pas les clés "pour une sauvegarde", mais pour une maintenance.
C'est normal, il s'agit ici de réinitialiser un TPM et de le remettre en état de marche. C'est le seul cas ou l'on peut avoir besoin de toucher aux clefs non migrables.
on doit avoir une entière confiance dans le constructeur.
Ou alors on casse l'init du TPM en enregistrant un endorsement key bidon (possible depuis TPM 1.2) et là même le constructeur ne peut plus rien pour nous d'après les specs. Il suffit ensuite de s'arranger pour ne jamais avoir à migrer des clefs non migrables. Pour cela il suffit de ne jamais utiliser les mécanismes d'authentification par tiers de confiance du TPM. A noter qu'à l'heure actuelle aucun fabriquant de TPM n'a mis en place de système d'authentification par tiers, s'en passer ne devrait donc pas poser de problèmes.
Si la puce TPM "n'est pas si inviolables que ça", alors elle sert A RIEN.
La puce TPM est un coffre à données. En tant que paranoïaque de première plutôt que de sauvegarder la clef privée chiffrée, protégée par mot de passe des liaisons SSL de mon serveur apache sur le disque dur, je décide de la rentrer dans un block TPM. A noter qu'il faut TOUJOURS que je tape mon mot de passe, simplement je n'ai accès au contenu de la clef que si je suis dans un environnement certifié. Si le TPM fonctionne bien : personne n'a accès a ma clef car elle n'est pas sur disque dur et qu'elle n'est disponible que si la séquence de boot convient au TPM. Si le TPM a des back-doors je me retrouve alors dans la même situation que si j'avais sauvegardé ma clef sur disque dur. En cas d'accès à mon disque dur, je n'ai plus qu'à prier que mon mot de passe résiste aux attaques.
On peut imaginer que le nombre de gens ayant accès à la back door TPM est infiniment plus réduit que le nombre de gens ayant accès à la lecture du système de fichier EXT3 ou UFS. De fait je me sens plus en sécurité derrière un TPM. Maintenant je suis d'accord qu'il ne faut pas lui faire une confiance aveugle non plus.
[^] # Re: Il y a bien une solution...
Posté par Jerome Herman . En réponse au journal Comment voler facilement des données chiffrées. Évalué à 2.
Les CPU modernes possèdent leurs propres générateurs aléatoires. Si ceux-ci sont plombés, il y a moyen de faire des trucs rigolos.
Euh pas vraiment besoin, vu que la norme dis "il faut que des clés non-migrables soit migrables".
Les psecs insistent aussi lourdement sur le fait qu'avant de lancer uen procédure de migration ou de maintenance le TPM doit s'assurer de la présence physique de l'opérateur.
Ensuite les specs insistent aussi lourdement sur le fait que les clefs non migrables sont à usage strictement interne (en d'autres termes ce sont des clefs qui sont utilisés par le TPM pour le chiffrement en interne et elles ne doivent en aucun cas interagir avec des demandes de chiffrement ou du déchiffrement venant de l'extérieur)
Toutes les clefs utilisables par les profils TPM sont migrables.
Donc déjà on migre pas les clés "pour une sauvegarde", mais pour une maintenance.
C'est normal, il s'agit ici de réinitialiser un TPM et de le remettre en état de marche. C'est le seul cas ou l'on peut avoir besoin de toucher aux clefs non migrables.
on doit avoir une entière confiance dans le constructeur.
Ou alors on casse l'init du TPM en enregistrant un endorsement key bidon (possible depuis TPM 1.2) et là même le constructeur ne peut plus rien pour nous d'après les specs. Il suffit ensuite de s'arranger pour ne jamais avoir à migrer des clefs non migrables. Pour cela il suffit de ne jamais utiliser les mécanismes d'authentification par tiers de confiance du TPM. A noter qu'à l'heure actuelle aucun fabriquant de TPM n'a mis en place de système d'authentification par tiers, s'en passer ne devrait donc pas poser de problèmes.
Si la puce TPM "n'est pas si inviolables que ça", alors elle sert A RIEN.
La puce TPM est un coffre à données. En tant que paranoïaque de première plutôt que de sauvegarder la clef privée chiffrée, protégée par mot de passe des liaisons SSL de mon serveur apache sur le disque dur, je décide de la rentrer dans un block TPM. A noter qu'il faut TOUJOURS que je tape mon mot de passe, simplement je n'ai accès au contenu de la clef que si je suis dans un environnement certifié. Si le TPM fonctionne bien : personne n'a accès a ma clef car elle n'est pas sur disque dur et qu'elle n'est disponible que si la séquence de boot convient au TPM. Si le TPM a des back-doors je me retrouve alors dans la même situation que si j'avais sauvegardé ma clef sur disque dur. En cas d'accès à mon disque dur, je n'ai plus qu'à prier que mon mot de passe résiste aux attaques.
On peut imaginer que le nombre de gens ayant accès à la back door TPM est infiniment plus réduit que le nombre de gens ayant accès à la lecture du système de fichier EXT3 ou UFS. De fait je me sens plus en sécurité derrière un TPM. Maintenant je suis d'accord qu'il ne faut pas lui faire une confiance aveugle non plus.