Une petite question me turlupine sur les certificats machines.
Imaginons un certificat machine pour faire une authentification 802.1x
par exemple
Cela s'applique aussi à un téléphone cisco qui ferait du skinny tls.
Comment diable arrivent ils à protéger la clé privée ?
Pour un certificat utilisateur, la clé privée est protégée par un
chiffrement lié au login/mot de passe
Mais dans ce cas le certificat n'est pas lié à un compte alors comment
le protège t'on ? QU'est ce qui empèche un dump du disque dur et
récupération de la clé privée ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Cedric Blancher
Le Thu, 30 Jun 2005 19:43:41 +0000, Sylvain Eche a écrit :
Comment diable arrivent ils à protéger la clé privée ?
Ils croient que la case "rendre la clé non exportable" suffit ;)
-- j viens de griller mon 8 Go ( pfiou lé enkore sous garantie ) j ai un exposé a faire sur 95/98/NT/2000 si vs zavez des sites bien detaillés la dessus ( chuis en ekole d info ) Ze vs serai tte ma vie reconnaissant -+- Zul in Guide du Neuneu d'Usenet-Epita loupé l'ENS. Té, l'est con-+-
Le Thu, 30 Jun 2005 19:43:41 +0000, Sylvain Eche a écrit :
Comment diable arrivent ils à protéger la clé privée ?
Ils croient que la case "rendre la clé non exportable" suffit ;)
--
j viens de griller mon 8 Go ( pfiou lé enkore sous garantie ) j ai un
exposé a faire sur 95/98/NT/2000 si vs zavez des sites bien detaillés
la dessus ( chuis en ekole d info ) Ze vs serai tte ma vie reconnaissant
-+- Zul in Guide du Neuneu d'Usenet-Epita loupé l'ENS. Té, l'est con-+-
Le Thu, 30 Jun 2005 19:43:41 +0000, Sylvain Eche a écrit :
Comment diable arrivent ils à protéger la clé privée ?
Ils croient que la case "rendre la clé non exportable" suffit ;)
-- j viens de griller mon 8 Go ( pfiou lé enkore sous garantie ) j ai un exposé a faire sur 95/98/NT/2000 si vs zavez des sites bien detaillés la dessus ( chuis en ekole d info ) Ze vs serai tte ma vie reconnaissant -+- Zul in Guide du Neuneu d'Usenet-Epita loupé l'ENS. Té, l'est con-+-
Dominique Blas
Comment diable arrivent ils à protéger la clé privée ?
En pratique la clé privée est protégée par une phrase de passe liée à un outil de chiffrement. On peut ensuite discuter du sérieux de cet outil.
Il faut donc taper la phrase avant de pouvoir se servir de la clé privée afin d'authentifier voire de chiffrer les messages sortant ou authentifier voir déchiffrer les messages entrants..
Par la suite afin d'éviter d'être pénalisé en temps ce mot de passe peut rester en mémoire (très mauvaise politique) ou, plutôt, c'est la clé qui reste en mémoire. C'est dès lors qu'elle est vulnérable (par tampering par exemple).
db
--
Courriel : usenet blas net
Comment diable arrivent ils à protéger la clé privée ?
En pratique la clé privée est protégée par une phrase de passe liée à un
outil de chiffrement. On peut ensuite discuter du sérieux de cet outil.
Il faut donc taper la phrase avant de pouvoir se servir de la clé privée
afin d'authentifier voire de chiffrer les messages sortant ou
authentifier voir déchiffrer les messages entrants..
Par la suite afin d'éviter d'être pénalisé en temps ce mot de passe peut
rester en mémoire (très mauvaise politique) ou, plutôt, c'est la clé qui
reste en mémoire.
C'est dès lors qu'elle est vulnérable (par tampering par exemple).
Comment diable arrivent ils à protéger la clé privée ?
En pratique la clé privée est protégée par une phrase de passe liée à un outil de chiffrement. On peut ensuite discuter du sérieux de cet outil.
Il faut donc taper la phrase avant de pouvoir se servir de la clé privée afin d'authentifier voire de chiffrer les messages sortant ou authentifier voir déchiffrer les messages entrants..
Par la suite afin d'éviter d'être pénalisé en temps ce mot de passe peut rester en mémoire (très mauvaise politique) ou, plutôt, c'est la clé qui reste en mémoire. C'est dès lors qu'elle est vulnérable (par tampering par exemple).
db
--
Courriel : usenet blas net
Cedric Blancher
Le Thu, 30 Jun 2005 21:49:48 +0000, Dominique Blas a écrit :
Comment diable arrivent ils à protéger la clé privée ? En pratique la clé privée est protégée par une phrase de passe liée à un
outil de chiffrement. On peut ensuite discuter du sérieux de cet outil.
En pratique, les clés privées des certificats machine Windows ne sont pas protégées par une passphrase parce qu'au moment où on en a besoin, à savoir au boot de le machine, l'administrateur n'est pas forcément là pour la fournir...
Ceci dit, je n'ai pas joué avec longtemps, je suis probablement à la bourre...
-- «je copie le fichier rpm dans un répertoire et l'installe, maintenant je ne sais pas lancer l'appli car elle ne s'est pas mise dans le menu "Démarrer-Programmes".» -+- Stéph in Guide du linuxien pervers : "install.exe il est ou?" -+-
Le Thu, 30 Jun 2005 21:49:48 +0000, Dominique Blas a écrit :
Comment diable arrivent ils à protéger la clé privée ?
En pratique la clé privée est protégée par une phrase de passe liée à un
outil de chiffrement. On peut ensuite discuter du sérieux de cet outil.
En pratique, les clés privées des certificats machine Windows ne sont
pas protégées par une passphrase parce qu'au moment où on en a besoin,
à savoir au boot de le machine, l'administrateur n'est pas forcément là
pour la fournir...
Ceci dit, je n'ai pas joué avec longtemps, je suis probablement à la
bourre...
--
«je copie le fichier rpm dans un répertoire et l'installe, maintenant
je ne sais pas lancer l'appli car elle ne s'est pas mise dans le menu
"Démarrer-Programmes".»
-+- Stéph in Guide du linuxien pervers : "install.exe il est ou?" -+-
Le Thu, 30 Jun 2005 21:49:48 +0000, Dominique Blas a écrit :
Comment diable arrivent ils à protéger la clé privée ? En pratique la clé privée est protégée par une phrase de passe liée à un
outil de chiffrement. On peut ensuite discuter du sérieux de cet outil.
En pratique, les clés privées des certificats machine Windows ne sont pas protégées par une passphrase parce qu'au moment où on en a besoin, à savoir au boot de le machine, l'administrateur n'est pas forcément là pour la fournir...
Ceci dit, je n'ai pas joué avec longtemps, je suis probablement à la bourre...
-- «je copie le fichier rpm dans un répertoire et l'installe, maintenant je ne sais pas lancer l'appli car elle ne s'est pas mise dans le menu "Démarrer-Programmes".» -+- Stéph in Guide du linuxien pervers : "install.exe il est ou?" -+-
Dominique Blas
[...]
En pratique, les clés privées des certificats machine Windows ne sont pas protégées par une passphrase parce qu'au moment où on en a besoin, à savoir au boot de le machine, l'administrateur n'est pas forcément là pour la fournir...
Arrête, c'est super de rire un bon coup mais trop c'est trop ! L'expression << mourir de rire >> a un sens propre si, si !
Je ne doute pas un seul instant que µsoft désirant préserver son sérieux dans le domaine de la sécu des SI n'ait pas prévu une solution en accord avec ses principes. Voyons !
Cela dit je parlais dans le cadre général et non dans celui d'un environnement particulier. Par exemple avec OpenSSL.
Mais si tu as d'autres histoires comme celles-là n'hésite pas !
On se les raconte autour d'un bon p'tit feu sur une plage avec des grattes ou en écoutant du Jefferson Airplane. Ou à moins que tu préfères une soirée exorciste avec le portrait de Bilou au mur. :-)
db
--
Courriel : usenet blas net
[...]
En pratique, les clés privées des certificats machine Windows ne sont
pas protégées par une passphrase parce qu'au moment où on en a besoin,
à savoir au boot de le machine, l'administrateur n'est pas forcément là
pour la fournir...
Arrête, c'est super de rire un bon coup mais trop c'est trop !
L'expression << mourir de rire >> a un sens propre si, si !
Je ne doute pas un seul instant que µsoft désirant préserver son sérieux
dans le domaine de la sécu des SI n'ait pas prévu une solution en
accord avec ses principes. Voyons !
Cela dit je parlais dans le cadre général et non dans celui d'un
environnement particulier. Par exemple avec OpenSSL.
Mais si tu as d'autres histoires comme celles-là n'hésite pas !
On se les raconte autour d'un bon p'tit feu sur une plage avec des
grattes ou en écoutant du Jefferson Airplane.
Ou à moins que tu préfères une soirée exorciste avec le portrait de
Bilou au mur. :-)
En pratique, les clés privées des certificats machine Windows ne sont pas protégées par une passphrase parce qu'au moment où on en a besoin, à savoir au boot de le machine, l'administrateur n'est pas forcément là pour la fournir...
Arrête, c'est super de rire un bon coup mais trop c'est trop ! L'expression << mourir de rire >> a un sens propre si, si !
Je ne doute pas un seul instant que µsoft désirant préserver son sérieux dans le domaine de la sécu des SI n'ait pas prévu une solution en accord avec ses principes. Voyons !
Cela dit je parlais dans le cadre général et non dans celui d'un environnement particulier. Par exemple avec OpenSSL.
Mais si tu as d'autres histoires comme celles-là n'hésite pas !
On se les raconte autour d'un bon p'tit feu sur une plage avec des grattes ou en écoutant du Jefferson Airplane. Ou à moins que tu préfères une soirée exorciste avec le portrait de Bilou au mur. :-)
db
--
Courriel : usenet blas net
Francois Cartegnie
Sylvain Eche wrote:
Bonjour
Mais dans ce cas le certificat n'est pas lié à un compte alors comment le protège t'on ? QU'est ce qui empèche un dump du disque dur et récupération de la clé privée ?
Il n'y a que le mot de passe :( .De mémoire, le certificat SSL pour apache peut être protégé avec mdp. Le serveur le demande au lancement: pas génial.
Maitenant l'application peut elle même chiffrer la clef sotckée, ca évite qu'on puisse la lire en clair (encore mieux si on ne peur détecter qu'elle est chiffrée). Mais après , faudra protèger le code de l'application......
Sylvain Eche wrote:
Bonjour
Mais dans ce cas le certificat n'est pas lié à un compte alors comment
le protège t'on ? QU'est ce qui empèche un dump du disque dur et
récupération de la clé privée ?
Il n'y a que le mot de passe :( .De mémoire, le certificat SSL pour
apache peut être protégé avec mdp. Le serveur le demande au lancement:
pas génial.
Maitenant l'application peut elle même chiffrer la clef sotckée, ca
évite qu'on puisse la lire en clair (encore mieux si on ne peur détecter
qu'elle est chiffrée). Mais après , faudra protèger le code de
l'application......
Mais dans ce cas le certificat n'est pas lié à un compte alors comment le protège t'on ? QU'est ce qui empèche un dump du disque dur et récupération de la clé privée ?
Il n'y a que le mot de passe :( .De mémoire, le certificat SSL pour apache peut être protégé avec mdp. Le serveur le demande au lancement: pas génial.
Maitenant l'application peut elle même chiffrer la clef sotckée, ca évite qu'on puisse la lire en clair (encore mieux si on ne peur détecter qu'elle est chiffrée). Mais après , faudra protèger le code de l'application......
Cedric Blancher
Le Fri, 01 Jul 2005 12:21:40 +0000, Dominique Blas a écrit :
Je ne doute pas un seul instant que µsoft désirant préserver son sérieux dans le domaine de la sécu des SI n'ait pas prévu une solution en accord avec ses principes. Voyons !
Ben oui, ça s'appelle NTFS et les droits sur le système de fichiers. On a eu une excellente rump sur le sujet au SSTIC, très enrichissante (le slide 10 en ce qui nous concerne) :
Ainsi qu'un talk à la dernière JSSI avec une démo d'extraction de clé privée "non-exportable" par Nicolas Ruff...
Cela dit je parlais dans le cadre général et non dans celui d'un environnement particulier. Par exemple avec OpenSSL.
Tu peux déjà aller chercher le p'tit bois.
Parce que la plupart des gens qui installent un service avec support SSL laissent la clé privée de leur certificat serveur, générée avec OpenSSL ou autre, sans passphrase. On a même des documents qui disent explicitement de ne pas en mettre, comme ici par exemple :
"You want your postfix system to start up at boot time without trouble? Then your server private key must not be encrypted."
Qu'est-ce qu'on se marre alors :)
-- Le robot (version 5.69 pl56-a) gérant le vote ne respecte pas l'alinéa 53bis de l'article 85 du livre 12 révision 2. MON CHAT DOIT POUVOIR COMPRENDRE ! -+- LW in: Guide du Cabaliste Usenet - Bien configurer son chat -+-
Le Fri, 01 Jul 2005 12:21:40 +0000, Dominique Blas a écrit :
Je ne doute pas un seul instant que µsoft désirant préserver son sérieux
dans le domaine de la sécu des SI n'ait pas prévu une solution en
accord avec ses principes. Voyons !
Ben oui, ça s'appelle NTFS et les droits sur le système de fichiers. On
a eu une excellente rump sur le sujet au SSTIC, très enrichissante (le
slide 10 en ce qui nous concerne) :
Ainsi qu'un talk à la dernière JSSI avec une démo d'extraction de clé
privée "non-exportable" par Nicolas Ruff...
Cela dit je parlais dans le cadre général et non dans celui d'un
environnement particulier. Par exemple avec OpenSSL.
Tu peux déjà aller chercher le p'tit bois.
Parce que la plupart des gens qui installent un service avec support SSL
laissent la clé privée de leur certificat serveur, générée avec
OpenSSL ou autre, sans passphrase. On a même des documents qui disent
explicitement de ne pas en mettre, comme ici par exemple :
"You want your postfix system to start up at boot time without trouble?
Then your server private key must not be encrypted."
Qu'est-ce qu'on se marre alors :)
--
Le robot (version 5.69 pl56-a) gérant le vote ne respecte pas l'alinéa
53bis de l'article 85 du livre 12 révision 2.
MON CHAT DOIT POUVOIR COMPRENDRE !
-+- LW in: Guide du Cabaliste Usenet - Bien configurer son chat -+-
Le Fri, 01 Jul 2005 12:21:40 +0000, Dominique Blas a écrit :
Je ne doute pas un seul instant que µsoft désirant préserver son sérieux dans le domaine de la sécu des SI n'ait pas prévu une solution en accord avec ses principes. Voyons !
Ben oui, ça s'appelle NTFS et les droits sur le système de fichiers. On a eu une excellente rump sur le sujet au SSTIC, très enrichissante (le slide 10 en ce qui nous concerne) :
Ainsi qu'un talk à la dernière JSSI avec une démo d'extraction de clé privée "non-exportable" par Nicolas Ruff...
Cela dit je parlais dans le cadre général et non dans celui d'un environnement particulier. Par exemple avec OpenSSL.
Tu peux déjà aller chercher le p'tit bois.
Parce que la plupart des gens qui installent un service avec support SSL laissent la clé privée de leur certificat serveur, générée avec OpenSSL ou autre, sans passphrase. On a même des documents qui disent explicitement de ne pas en mettre, comme ici par exemple :
"You want your postfix system to start up at boot time without trouble? Then your server private key must not be encrypted."
Qu'est-ce qu'on se marre alors :)
-- Le robot (version 5.69 pl56-a) gérant le vote ne respecte pas l'alinéa 53bis de l'article 85 du livre 12 révision 2. MON CHAT DOIT POUVOIR COMPRENDRE ! -+- LW in: Guide du Cabaliste Usenet - Bien configurer son chat -+-
Super cette présentation ! Tiens slide 16 on dirait qu'il y a la réponse : c'est seulement protégé par des droits NTFS si on veut pas se payer de code pin a entrer à chaque boot de machine !. AUtrement dit la protection est nulle si on dumpe le disque sous un autre système d'exploitation. Je me doutais bien qu'il ne pouvait y avoir de miracle ...
Super cette présentation !
Tiens slide 16 on dirait qu'il y a la réponse : c'est seulement protégé
par des droits NTFS si on veut pas se payer de code pin a entrer à
chaque boot de machine !.
AUtrement dit la protection est nulle si on dumpe le disque sous un
autre système d'exploitation.
Je me doutais bien qu'il ne pouvait y avoir de miracle ...
Super cette présentation ! Tiens slide 16 on dirait qu'il y a la réponse : c'est seulement protégé par des droits NTFS si on veut pas se payer de code pin a entrer à chaque boot de machine !. AUtrement dit la protection est nulle si on dumpe le disque sous un autre système d'exploitation. Je me doutais bien qu'il ne pouvait y avoir de miracle ...
Cedric Blancher
Le Fri, 01 Jul 2005 22:51:56 +0000, Sylvain Eche a écrit :
Tiens slide 16 on dirait qu'il y a la réponse : c'est seulement protégé par des droits NTFS si on veut pas se payer de code pin a entrer à chaque boot de machine !.
D'après le slide 10, la protection par passphrase des certificats machine n'est tout simplement pas possible...
AUtrement dit la protection est nulle si on dumpe le disque sous un autre système d'exploitation. Je me doutais bien qu'il ne pouvait y avoir de miracle ...
Ça, c'est évident, quelque soit le système. D'où l'intérêt de pouvoir mettre une passphrase (ou pas).
-- BOFH excuse #66:
bit bucket overflow
Le Fri, 01 Jul 2005 22:51:56 +0000, Sylvain Eche a écrit :
Tiens slide 16 on dirait qu'il y a la réponse : c'est seulement protégé
par des droits NTFS si on veut pas se payer de code pin a entrer à
chaque boot de machine !.
D'après le slide 10, la protection par passphrase des certificats machine
n'est tout simplement pas possible...
AUtrement dit la protection est nulle si on dumpe le disque sous un
autre système d'exploitation.
Je me doutais bien qu'il ne pouvait y avoir de miracle ...
Ça, c'est évident, quelque soit le système. D'où l'intérêt de
pouvoir mettre une passphrase (ou pas).
Le Fri, 01 Jul 2005 22:51:56 +0000, Sylvain Eche a écrit :
Tiens slide 16 on dirait qu'il y a la réponse : c'est seulement protégé par des droits NTFS si on veut pas se payer de code pin a entrer à chaque boot de machine !.
D'après le slide 10, la protection par passphrase des certificats machine n'est tout simplement pas possible...
AUtrement dit la protection est nulle si on dumpe le disque sous un autre système d'exploitation. Je me doutais bien qu'il ne pouvait y avoir de miracle ...
Ça, c'est évident, quelque soit le système. D'où l'intérêt de pouvoir mettre une passphrase (ou pas).
-- BOFH excuse #66:
bit bucket overflow
Sylvain Eche
Ça, c'est évident, quelque soit le système. D'où l'intérêt de pouvoir mettre une passphrase (ou pas).
Ok ca me parait cohérent ! pas de protection software magique sans passphrase. Par contre il me semble avoir entendu parler de processeur crypto dans les nouveaux processeurs pentium ou autre. Dans ce cas on peut imaginer une clée privée protégée dans le processeur d'ou on ne peut pas exporter la clé privée. Le seul moyen revenant à voler le processeur pour pouvoir utiliser la clé privée.
QUelqu'un a de l'info la dessus ? ce qu'il se fait sur les crypto processeurs hardware ? je crois que Cisco utilise ce genre de chose aussi.
Ça, c'est évident, quelque soit le système. D'où l'intérêt de
pouvoir mettre une passphrase (ou pas).
Ok ca me parait cohérent ! pas de protection software magique sans
passphrase.
Par contre il me semble avoir entendu parler de processeur crypto dans
les nouveaux processeurs pentium ou autre.
Dans ce cas on peut imaginer une clée privée protégée dans le processeur
d'ou on ne peut pas exporter la clé privée. Le seul moyen revenant à
voler le processeur pour pouvoir utiliser la clé privée.
QUelqu'un a de l'info la dessus ? ce qu'il se fait sur les crypto
processeurs hardware ? je crois que Cisco utilise ce genre de chose aussi.
Ça, c'est évident, quelque soit le système. D'où l'intérêt de pouvoir mettre une passphrase (ou pas).
Ok ca me parait cohérent ! pas de protection software magique sans passphrase. Par contre il me semble avoir entendu parler de processeur crypto dans les nouveaux processeurs pentium ou autre. Dans ce cas on peut imaginer une clée privée protégée dans le processeur d'ou on ne peut pas exporter la clé privée. Le seul moyen revenant à voler le processeur pour pouvoir utiliser la clé privée.
QUelqu'un a de l'info la dessus ? ce qu'il se fait sur les crypto processeurs hardware ? je crois que Cisco utilise ce genre de chose aussi.
