Le double-XOR dont parlait Pierre il y a quelques temps? :) OK, je sors. Ou alors le rot-52
Le AND. Impossible à casser (surtout avec une clé de 2048 bits constituée de 0).
Pn frenvg har vqér à fhttéere cbhe PQC - znvf w'nv crhe dhr yn fvzcyr éibpngvba qr pr abz ar snffr erirave y'nhger znhinvf téavr fnaf obhvyyve.
Eric Razny
"Xavier Roche"
Le AND. Impossible à casser (surtout avec une clé de 2048 bits constituée de 0).
Pn frenvg har vqér à fhttéere cbhe PQC - znvf w'nv crhe dhr yn fvzcyr éibpngvba qr pr abz ar snffr erirave y'nhger znhinvf téavr fnaf obhvyyve.
La tu fais prendre à tous un maximum de risques! Et tu oublie l'empreinte que laisse l'orientation des spins des composants du transistor avec à la fin le AND réversible :-)
"Xavier Roche" <xroche@free.fr.NOSPAM.invalid>
Le AND. Impossible à casser (surtout avec une clé de 2048 bits
constituée de 0).
Pn frenvg har vqér à fhttéere cbhe PQC - znvf w'nv crhe dhr yn fvzcyr
éibpngvba qr pr abz ar snffr erirave y'nhger znhinvf téavr fnaf obhvyyve.
La tu fais prendre à tous un maximum de risques!
Et tu oublie l'empreinte que laisse l'orientation des spins des composants
du transistor avec à la fin le AND réversible :-)
Le AND. Impossible à casser (surtout avec une clé de 2048 bits constituée de 0).
Pn frenvg har vqér à fhttéere cbhe PQC - znvf w'nv crhe dhr yn fvzcyr éibpngvba qr pr abz ar snffr erirave y'nhger znhinvf téavr fnaf obhvyyve.
La tu fais prendre à tous un maximum de risques! Et tu oublie l'empreinte que laisse l'orientation des spins des composants du transistor avec à la fin le AND réversible :-)
pornin
According to g2r6 :
mais dans ce cas, si GnuPG n'est pas sûr, quel outil l'est plus ?
"Être sûr", ça veut dire que : 1. la fonction de sécurité réalisée par le logiciel résistera aux attaques ; 2. vous pouvez savoir _a priori_ que la fonction de sécurité réalisée par le logiciel résistera aux attaques.
Est-ce qu'un avis d'un semi-anonyme sur Internet vous fournira le niveau de confiance nécessaire pour rendre un produit "sûr" ? Bof bof bof...
Par ailleurs, un outil comme GnuPG fournit une fonctionnalité de sécurité bien précise dans un cadre précis ; en dehors de ce cadre, rien ne dit qu'il apporte quoi que ce soit en termes de sécurité. Comparer deux produits sur leurs "sécurités" respectives n'a de sens que si les deux produits proposent rigoureusement les mêmes fonctionnalités. Que signifierait, par exemple, comparer la sécurité de GnuPG avec celle de SSH ?
Avant de se demander "quel est le produit qu'il me faut ?", il faut commencer par bien définir ses propres besoins. La sécurité est un processus dont la base fondamentale est de bien comprendre ce qu'on veut au fond(*).
--Thomas Pornin
(*) La plupart des problèmes de sécurité arrivent parce qu'en la matière, on a tendance à avoir exactement ce qu'on a demandé, et pas ce qu'on aurait voulu avoir.
According to g2r6 <sluchoukku7@jetable.com>:
mais dans ce cas, si GnuPG n'est pas sûr, quel outil l'est plus ?
"Être sûr", ça veut dire que :
1. la fonction de sécurité réalisée par le logiciel résistera aux
attaques ;
2. vous pouvez savoir _a priori_ que la fonction de sécurité réalisée par
le logiciel résistera aux attaques.
Est-ce qu'un avis d'un semi-anonyme sur Internet vous fournira le niveau
de confiance nécessaire pour rendre un produit "sûr" ? Bof bof bof...
Par ailleurs, un outil comme GnuPG fournit une fonctionnalité de
sécurité bien précise dans un cadre précis ; en dehors de ce cadre, rien
ne dit qu'il apporte quoi que ce soit en termes de sécurité. Comparer
deux produits sur leurs "sécurités" respectives n'a de sens que si les
deux produits proposent rigoureusement les mêmes fonctionnalités. Que
signifierait, par exemple, comparer la sécurité de GnuPG avec celle de
SSH ?
Avant de se demander "quel est le produit qu'il me faut ?", il faut
commencer par bien définir ses propres besoins. La sécurité est un
processus dont la base fondamentale est de bien comprendre ce qu'on veut
au fond(*).
--Thomas Pornin
(*) La plupart des problèmes de sécurité arrivent parce qu'en la
matière, on a tendance à avoir exactement ce qu'on a demandé, et pas ce
qu'on aurait voulu avoir.
mais dans ce cas, si GnuPG n'est pas sûr, quel outil l'est plus ?
"Être sûr", ça veut dire que : 1. la fonction de sécurité réalisée par le logiciel résistera aux attaques ; 2. vous pouvez savoir _a priori_ que la fonction de sécurité réalisée par le logiciel résistera aux attaques.
Est-ce qu'un avis d'un semi-anonyme sur Internet vous fournira le niveau de confiance nécessaire pour rendre un produit "sûr" ? Bof bof bof...
Par ailleurs, un outil comme GnuPG fournit une fonctionnalité de sécurité bien précise dans un cadre précis ; en dehors de ce cadre, rien ne dit qu'il apporte quoi que ce soit en termes de sécurité. Comparer deux produits sur leurs "sécurités" respectives n'a de sens que si les deux produits proposent rigoureusement les mêmes fonctionnalités. Que signifierait, par exemple, comparer la sécurité de GnuPG avec celle de SSH ?
Avant de se demander "quel est le produit qu'il me faut ?", il faut commencer par bien définir ses propres besoins. La sécurité est un processus dont la base fondamentale est de bien comprendre ce qu'on veut au fond(*).
--Thomas Pornin
(*) La plupart des problèmes de sécurité arrivent parce qu'en la matière, on a tendance à avoir exactement ce qu'on a demandé, et pas ce qu'on aurait voulu avoir.
Jean-Marc Desperrier
Thomas Pornin wrote:
(*) La plupart des problèmes de sécurité arrivent parce qu'en la matière, on a tendance à avoir exactement ce qu'on a demandé, et pas ce qu'on aurait voulu avoir.
Je pense aussi qu'un autre élément majeur de faille est qu'on essaie de créer de la sécurité. On a un truc pas sûr, et les gens pensent qu'ajouter quelquechose a une chance de le rendre sûr.
C'est impossible.
On peut seulement propager de la sécurité, s'appuyer comme un point de levier sur un élément qui *est* sûr, et rendre grâce à ce premier élément rendre un autre élément sûr.
Mais si rien n'est sûr au départ, rien ne sera sûr à l'arrivée.
Résultat, on exige des développeurs de créer un logiciel sûr à partir de base qui ne peuvent pas l'être, et ils vont noyer le poisson. Dans la description, les mécanismes ajoutés paraitront rendre le système solide, mais en fait la faille sera seulement déplacée, et bien cachée dans la description, mais il suffira toujours d'attaquer le bon élément pour casser le système.
Un exemple absolument *typique* est les systèmes où l'on demande de garantir que le code n'a pas été modifié avant de l'exécuter. En général, cela finit par être fait en rajoutant une signature à coté que le logiciel va charger pour se vérifier. Pour l'attaquant, il suffit de penser à mettre à jour la signature après avoir patché le code. Ou bien en patchant le code, penser à supprimer aussi la routine qui vérifie la signature.
Bref, ça sert strictement à rien, non pas parceque les developpeurs sont idiots, mais parcequ'on a exigé d'eux quelquechose qui ne peut pas marcher par principe.
Par contraste, il y a un système de ce type qui lui est solide, c'est le palladium de Microsoft *parceque* il s'appuit sur un élément externe solide, un puce avec une clé secrête, et qu'il propage la sécurité de cet élément jusqu'à garantir la sécurité des applications lancées. La puce vérifie le bios, et je ne peux toucher à la puce sans détruire physiquement le système, le bios vérifie l'OS, l'OS vérifie les applis, ... Il peut y avoir quand même une défaillance, si la puce n'est pas intégrée au chipset, je peux peut-être quand même tricher physiquement, ou bien il peut y avoir un bug, un buffer overflow dans un des éléments du BIOS, de l'OS, d'un appli, mais conceptuellement, rien à dire, c'est parfaitement bien pensé. Moralement, on peut aussi ne pas apprécier, mais ça c'est un problème à un autre niveau.
Thomas Pornin wrote:
(*) La plupart des problèmes de sécurité arrivent parce qu'en la
matière, on a tendance à avoir exactement ce qu'on a demandé, et pas ce
qu'on aurait voulu avoir.
Je pense aussi qu'un autre élément majeur de faille est qu'on essaie de
créer de la sécurité.
On a un truc pas sûr, et les gens pensent qu'ajouter quelquechose a une
chance de le rendre sûr.
C'est impossible.
On peut seulement propager de la sécurité, s'appuyer comme un point de
levier sur un élément qui *est* sûr, et rendre grâce à ce premier
élément rendre un autre élément sûr.
Mais si rien n'est sûr au départ, rien ne sera sûr à l'arrivée.
Résultat, on exige des développeurs de créer un logiciel sûr à partir de
base qui ne peuvent pas l'être, et ils vont noyer le poisson.
Dans la description, les mécanismes ajoutés paraitront rendre le système
solide, mais en fait la faille sera seulement déplacée, et bien cachée
dans la description, mais il suffira toujours d'attaquer le bon élément
pour casser le système.
Un exemple absolument *typique* est les systèmes où l'on demande de
garantir que le code n'a pas été modifié avant de l'exécuter.
En général, cela finit par être fait en rajoutant une signature à coté
que le logiciel va charger pour se vérifier.
Pour l'attaquant, il suffit de penser à mettre à jour la signature après
avoir patché le code. Ou bien en patchant le code, penser à supprimer
aussi la routine qui vérifie la signature.
Bref, ça sert strictement à rien, non pas parceque les developpeurs sont
idiots, mais parcequ'on a exigé d'eux quelquechose qui ne peut pas
marcher par principe.
Par contraste, il y a un système de ce type qui lui est solide, c'est le
palladium de Microsoft *parceque* il s'appuit sur un élément externe
solide, un puce avec une clé secrête, et qu'il propage la sécurité de
cet élément jusqu'à garantir la sécurité des applications lancées.
La puce vérifie le bios, et je ne peux toucher à la puce sans détruire
physiquement le système, le bios vérifie l'OS, l'OS vérifie les applis, ...
Il peut y avoir quand même une défaillance, si la puce n'est pas
intégrée au chipset, je peux peut-être quand même tricher physiquement,
ou bien il peut y avoir un bug, un buffer overflow dans un des éléments
du BIOS, de l'OS, d'un appli, mais conceptuellement, rien à dire, c'est
parfaitement bien pensé.
Moralement, on peut aussi ne pas apprécier, mais ça c'est un problème à
un autre niveau.
(*) La plupart des problèmes de sécurité arrivent parce qu'en la matière, on a tendance à avoir exactement ce qu'on a demandé, et pas ce qu'on aurait voulu avoir.
Je pense aussi qu'un autre élément majeur de faille est qu'on essaie de créer de la sécurité. On a un truc pas sûr, et les gens pensent qu'ajouter quelquechose a une chance de le rendre sûr.
C'est impossible.
On peut seulement propager de la sécurité, s'appuyer comme un point de levier sur un élément qui *est* sûr, et rendre grâce à ce premier élément rendre un autre élément sûr.
Mais si rien n'est sûr au départ, rien ne sera sûr à l'arrivée.
Résultat, on exige des développeurs de créer un logiciel sûr à partir de base qui ne peuvent pas l'être, et ils vont noyer le poisson. Dans la description, les mécanismes ajoutés paraitront rendre le système solide, mais en fait la faille sera seulement déplacée, et bien cachée dans la description, mais il suffira toujours d'attaquer le bon élément pour casser le système.
Un exemple absolument *typique* est les systèmes où l'on demande de garantir que le code n'a pas été modifié avant de l'exécuter. En général, cela finit par être fait en rajoutant une signature à coté que le logiciel va charger pour se vérifier. Pour l'attaquant, il suffit de penser à mettre à jour la signature après avoir patché le code. Ou bien en patchant le code, penser à supprimer aussi la routine qui vérifie la signature.
Bref, ça sert strictement à rien, non pas parceque les developpeurs sont idiots, mais parcequ'on a exigé d'eux quelquechose qui ne peut pas marcher par principe.
Par contraste, il y a un système de ce type qui lui est solide, c'est le palladium de Microsoft *parceque* il s'appuit sur un élément externe solide, un puce avec une clé secrête, et qu'il propage la sécurité de cet élément jusqu'à garantir la sécurité des applications lancées. La puce vérifie le bios, et je ne peux toucher à la puce sans détruire physiquement le système, le bios vérifie l'OS, l'OS vérifie les applis, ... Il peut y avoir quand même une défaillance, si la puce n'est pas intégrée au chipset, je peux peut-être quand même tricher physiquement, ou bien il peut y avoir un bug, un buffer overflow dans un des éléments du BIOS, de l'OS, d'un appli, mais conceptuellement, rien à dire, c'est parfaitement bien pensé. Moralement, on peut aussi ne pas apprécier, mais ça c'est un problème à un autre niveau.
Erwann ABALEA
On Fri, 6 Feb 2004, Jean-Marc Desperrier wrote:
[...]
Par contraste, il y a un système de ce type qui lui est solide, c'est le palladium de Microsoft *parceque* il s'appuit sur un élément externe
Ou tout autre OS qui saurait gérer la puce TCPA, qui semble être un machin amusant.
[...]
Moralement, on peut aussi ne pas apprécier, mais ça c'est un problème à un autre niveau.
Ceux qui pensent ça sont manipulés par de mauvais arguments, mais cette fois par des pseudo-défenseurs du Logiciel Libre (tm) qui n'ont rien compris au machin.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Alors, remettons les pendules à l'heure: C'est toi qui te gourres complètement pour les raisons suivantes: J'admet tout à fait que j'ai tort. -+- TL in <http://neuneu.mine.nu> : Totor, t'as tort -+-
On Fri, 6 Feb 2004, Jean-Marc Desperrier wrote:
[...]
Par contraste, il y a un système de ce type qui lui est solide, c'est le
palladium de Microsoft *parceque* il s'appuit sur un élément externe
Ou tout autre OS qui saurait gérer la puce TCPA, qui semble être un machin
amusant.
[...]
Moralement, on peut aussi ne pas apprécier, mais ça c'est un problème à
un autre niveau.
Ceux qui pensent ça sont manipulés par de mauvais arguments, mais cette
fois par des pseudo-défenseurs du Logiciel Libre (tm) qui n'ont rien
compris au machin.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Alors, remettons les pendules à l'heure:
C'est toi qui te gourres complètement pour les raisons suivantes:
J'admet tout à fait que j'ai tort.
-+- TL in <http://neuneu.mine.nu> : Totor, t'as tort -+-
Par contraste, il y a un système de ce type qui lui est solide, c'est le palladium de Microsoft *parceque* il s'appuit sur un élément externe
Ou tout autre OS qui saurait gérer la puce TCPA, qui semble être un machin amusant.
[...]
Moralement, on peut aussi ne pas apprécier, mais ça c'est un problème à un autre niveau.
Ceux qui pensent ça sont manipulés par de mauvais arguments, mais cette fois par des pseudo-défenseurs du Logiciel Libre (tm) qui n'ont rien compris au machin.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Alors, remettons les pendules à l'heure: C'est toi qui te gourres complètement pour les raisons suivantes: J'admet tout à fait que j'ai tort. -+- TL in <http://neuneu.mine.nu> : Totor, t'as tort -+-
Erwan David
Erwann ABALEA écrivait :
On Fri, 6 Feb 2004, Jean-Marc Desperrier wrote:
[...]
Par contraste, il y a un système de ce type qui lui est solide, c'est le palladium de Microsoft *parceque* il s'appuit sur un élément externe
Ou tout autre OS qui saurait gérer la puce TCPA, qui semble être un machin amusant.
[...]
Moralement, on peut aussi ne pas apprécier, mais ça c'est un problème à un autre niveau.
Ceux qui pensent ça sont manipulés par de mauvais arguments, mais cette fois par des pseudo-défenseurs du Logiciel Libre (tm) qui n'ont rien compris au machin.
Euh il faut voir aussi que MS fait des mélanges entre TCPA OS signé, DRM etc...
Parceque la puce TCPA permet tout à fait d'interdire de booter un OS non signé. Et que ce n'est *pas* le propriétaire de la machine qui a le contrôle de ce que le hard accepte ou pas. Là est le vrai danger. On a déjà la connerie des browsers web contenant une palanquée d'autorités de certification préinstallées et parfois inamovibles, qui retirent une partie du contrôle à l'utilisateur, le danger est *pire* si c'est le hard qui est dans le même schéma.
Erwann ABALEA <erwann@abalea.com> écrivait :
On Fri, 6 Feb 2004, Jean-Marc Desperrier wrote:
[...]
Par contraste, il y a un système de ce type qui lui est solide, c'est le
palladium de Microsoft *parceque* il s'appuit sur un élément externe
Ou tout autre OS qui saurait gérer la puce TCPA, qui semble être un machin
amusant.
[...]
Moralement, on peut aussi ne pas apprécier, mais ça c'est un problème à
un autre niveau.
Ceux qui pensent ça sont manipulés par de mauvais arguments, mais cette
fois par des pseudo-défenseurs du Logiciel Libre (tm) qui n'ont rien
compris au machin.
Euh il faut voir aussi que MS fait des mélanges entre TCPA OS signé,
DRM etc...
Parceque la puce TCPA permet tout à fait d'interdire de booter un OS
non signé. Et que ce n'est *pas* le propriétaire de la machine qui a
le contrôle de ce que le hard accepte ou pas. Là est le vrai
danger. On a déjà la connerie des browsers web contenant une
palanquée d'autorités de certification préinstallées et parfois
inamovibles, qui retirent une partie du contrôle à l'utilisateur, le
danger est *pire* si c'est le hard qui est dans le même schéma.
Par contraste, il y a un système de ce type qui lui est solide, c'est le palladium de Microsoft *parceque* il s'appuit sur un élément externe
Ou tout autre OS qui saurait gérer la puce TCPA, qui semble être un machin amusant.
[...]
Moralement, on peut aussi ne pas apprécier, mais ça c'est un problème à un autre niveau.
Ceux qui pensent ça sont manipulés par de mauvais arguments, mais cette fois par des pseudo-défenseurs du Logiciel Libre (tm) qui n'ont rien compris au machin.
Euh il faut voir aussi que MS fait des mélanges entre TCPA OS signé, DRM etc...
Parceque la puce TCPA permet tout à fait d'interdire de booter un OS non signé. Et que ce n'est *pas* le propriétaire de la machine qui a le contrôle de ce que le hard accepte ou pas. Là est le vrai danger. On a déjà la connerie des browsers web contenant une palanquée d'autorités de certification préinstallées et parfois inamovibles, qui retirent une partie du contrôle à l'utilisateur, le danger est *pire* si c'est le hard qui est dans le même schéma.
Fabrice..Bacchella
On Fri, 13 Feb 2004 09:05:27 +0100, Erwan David wrote:
Parceque la puce TCPA permet tout à fait d'interdire de booter un OS non signé. Et que ce n'est *pas* le propriétaire de la machine qui a ^^^^^^^^^^
Par qui ? --- http://fba.homeip.net
On Fri, 13 Feb 2004 09:05:27 +0100, Erwan David <erwan@rail.eu.org>
wrote:
Parceque la puce TCPA permet tout à fait d'interdire de booter un OS
non signé. Et que ce n'est *pas* le propriétaire de la machine qui a
^^^^^^^^^^
On Fri, 13 Feb 2004 09:05:27 +0100, Erwan David wrote:
Parceque la puce TCPA permet tout à fait d'interdire de booter un OS non signé. Et que ce n'est *pas* le propriétaire de la machine qui a ^^^^^^^^^^
Par qui ? --- http://fba.homeip.net
Erwan David
Fabrice..Bacchella écrivait :
On Fri, 13 Feb 2004 09:05:27 +0100, Erwan David wrote:
Parceque la puce TCPA permet tout à fait d'interdire de booter un OS non signé. Et que ce n'est *pas* le propriétaire de la machine qui a ^^^^^^^^^^
Par qui ?
Par une clé contenue dans le BIOS ou le hard. Et je ne fait *aucune* confiance aux fabricants pour me laisser ma liberté de choix. Je n'ai qu'à voir que ce sont les même qui font des lecteurs de DVD zonés.
On Fri, 13 Feb 2004 09:05:27 +0100, Erwan David <erwan@rail.eu.org>
wrote:
Parceque la puce TCPA permet tout à fait d'interdire de booter un OS
non signé. Et que ce n'est *pas* le propriétaire de la machine qui a
^^^^^^^^^^
Par qui ?
Par une clé contenue dans le BIOS ou le hard. Et je ne fait *aucune*
confiance aux fabricants pour me laisser ma liberté de choix. Je n'ai
qu'à voir que ce sont les même qui font des lecteurs de DVD zonés.
On Fri, 13 Feb 2004 09:05:27 +0100, Erwan David wrote:
Parceque la puce TCPA permet tout à fait d'interdire de booter un OS non signé. Et que ce n'est *pas* le propriétaire de la machine qui a ^^^^^^^^^^
Par qui ?
Par une clé contenue dans le BIOS ou le hard. Et je ne fait *aucune* confiance aux fabricants pour me laisser ma liberté de choix. Je n'ai qu'à voir que ce sont les même qui font des lecteurs de DVD zonés.
Fabrice..Bacchella
On Fri, 13 Feb 2004 12:58:48 +0100, Erwan David wrote:
Fabrice..Bacchella écrivait :
On Fri, 13 Feb 2004 09:05:27 +0100, Erwan David wrote:
Parceque la puce TCPA permet tout à fait d'interdire de booter un OS non signé. Et que ce n'est *pas* le propriétaire de la machine qui a ^^^^^^^^^^
Par qui ?
Par une clé contenue dans le BIOS ou le hard. Et je ne fait *aucune* confiance aux fabricants pour me laisser ma liberté de choix. Je n'ai qu'à voir que ce sont les même qui font des lecteurs de DVD zonés.
Vous voulez dire ces gens qui fabrique des DVD dont le dezonnages est prévu pour être le plus simple possible ?
Et vous ne répondez pas à ma question. Vous parlez de l'endroit où est stocké la clé publique & vérifié la signature. Je vous parle de l'émetteur. Qui signe un OS ? Microsoft ? Le fabriquant de la carte-mère, du BIOS, l'assembleur ? Si ça ce passe comme pour les DVD, en une semaine, la majorité des clés privées de BIOS seront disponible sur le web.
--- http://fba.homeip.net
On Fri, 13 Feb 2004 12:58:48 +0100, Erwan David <erwan@rail.eu.org>
wrote:
On Fri, 13 Feb 2004 09:05:27 +0100, Erwan David <erwan@rail.eu.org>
wrote:
Parceque la puce TCPA permet tout à fait d'interdire de booter un OS
non signé. Et que ce n'est *pas* le propriétaire de la machine qui a
^^^^^^^^^^
Par qui ?
Par une clé contenue dans le BIOS ou le hard. Et je ne fait *aucune*
confiance aux fabricants pour me laisser ma liberté de choix. Je n'ai
qu'à voir que ce sont les même qui font des lecteurs de DVD zonés.
Vous voulez dire ces gens qui fabrique des DVD dont le dezonnages est
prévu pour être le plus simple possible ?
Et vous ne répondez pas à ma question. Vous parlez de l'endroit où est
stocké la clé publique & vérifié la signature. Je vous parle de
l'émetteur. Qui signe un OS ? Microsoft ? Le fabriquant de la
carte-mère, du BIOS, l'assembleur ? Si ça ce passe comme pour les DVD,
en une semaine, la majorité des clés privées de BIOS seront disponible
sur le web.
On Fri, 13 Feb 2004 12:58:48 +0100, Erwan David wrote:
Fabrice..Bacchella écrivait :
On Fri, 13 Feb 2004 09:05:27 +0100, Erwan David wrote:
Parceque la puce TCPA permet tout à fait d'interdire de booter un OS non signé. Et que ce n'est *pas* le propriétaire de la machine qui a ^^^^^^^^^^
Par qui ?
Par une clé contenue dans le BIOS ou le hard. Et je ne fait *aucune* confiance aux fabricants pour me laisser ma liberté de choix. Je n'ai qu'à voir que ce sont les même qui font des lecteurs de DVD zonés.
Vous voulez dire ces gens qui fabrique des DVD dont le dezonnages est prévu pour être le plus simple possible ?
Et vous ne répondez pas à ma question. Vous parlez de l'endroit où est stocké la clé publique & vérifié la signature. Je vous parle de l'émetteur. Qui signe un OS ? Microsoft ? Le fabriquant de la carte-mère, du BIOS, l'assembleur ? Si ça ce passe comme pour les DVD, en une semaine, la majorité des clés privées de BIOS seront disponible sur le web.
--- http://fba.homeip.net
Eric Razny
"Fabrice..Bacchella" a écrit
Parceque la puce TCPA permet tout à fait d'interdire de booter un OS non signé. Et que ce n'est *pas* le propriétaire de la machine qui a ^^^^^^^^^^
Par qui ?
Par une clé contenue dans le BIOS ou le hard. Et je ne fait *aucune* confiance aux fabricants pour me laisser ma liberté de choix. Je n'ai qu'à voir que ce sont les même qui font des lecteurs de DVD zonés.
Vous voulez dire ces gens qui fabrique des DVD dont le dezonnages est prévu pour être le plus simple possible ?
Tous les lecteurs de DVD du marché ne sont pas dézonnables si facilement et flasher le firmware n'est pas faisable par tout le monde (dans le sens "peur de détruire le matériel" par l'utilisateur lambda, pas de fw "pirate" dispo -je ne vais pas me frapper du reverse engineering avec apprentissage de l'assembleur correspondant-).
Et vous ne répondez pas à ma question. Vous parlez de l'endroit où est stocké la clé publique & vérifié la signature. Je vous parle de l'émetteur. Qui signe un OS ? Microsoft ? Le fabriquant de la carte-mère, du BIOS, l'assembleur ? Si ça ce passe comme pour les DVD, en une semaine, la majorité des clés privées de BIOS seront disponible sur le web.
Et *SI* ça ne se passe pas comme ça? Je ne fais pas devin (ce n'est plus puni par la loi mais bon...), avez vous des dons en ce sens?
Je ne peux qu'être d'accord avec Erwan David sur ce point. Le processus engagé est dangereux dans le sens ou la fabricant peut, in fine, décider à ma place de ce qui peut tourner ou pas sur MA machine. Plus amusant (enfin, façon de parler) : le jour ou MS -simple exemple et pur spéculation bien sur- se fait pirater on va avoir une jolie révocation de certifs ou équivalent avec un arrêt de fonctionnement immédiat (enfin dès chargement des infos) de toutes les machines contrôlées de cette manière. Et même avec des contres-mesures rapides les dégât seront considérables (au moins financièrement, il n'y a pas qu'unix dans les banques, et eventuellement physiquement suivant les processus contrôlés par l'OS et les softs qui vont avec).
Cette forme de signature électronique[1] est liée de façon, je trouve, assez évidente à des conséquences commerciales : celui qui gère les signatures et celui qui les distribue a un pouvoir énorme, qu'il va vendre au prix fort. Et le plus puissant financièrement ne vas pas se gêner pour provoquer des concentrations par acquisition. Le cas verisign ne suffit pas comme alerte? (et encore, ici on peut encore contourner un peu le problème).
Le modèle de sécurité est, amha, interressant, à condition que ce soit l'utilisateur qui choississe de l'appliquer ou pas (allez, on va même accepter une activation par défaut :) ). Ensuite rien n'empêche un éditeur de refuser que son soft ne marche si le bidule n'est pas activé ou que ça produise un avertissement de limitation de responsabilité par exemple ; après c'est le end-user qui choisi d'acquérir ou pas.
Eric.
[1] même si ce n'est qu'une partie de la solution
"Fabrice..Bacchella" <nobody@worldonline.france> a écrit
Parceque la puce TCPA permet tout à fait d'interdire de booter un OS
non signé. Et que ce n'est *pas* le propriétaire de la machine qui a
^^^^^^^^^^
Par qui ?
Par une clé contenue dans le BIOS ou le hard. Et je ne fait *aucune*
confiance aux fabricants pour me laisser ma liberté de choix. Je n'ai
qu'à voir que ce sont les même qui font des lecteurs de DVD zonés.
Vous voulez dire ces gens qui fabrique des DVD dont le dezonnages est
prévu pour être le plus simple possible ?
Tous les lecteurs de DVD du marché ne sont pas dézonnables si facilement et
flasher le firmware n'est pas faisable par tout le monde (dans le sens "peur
de détruire le matériel" par l'utilisateur lambda, pas de fw "pirate"
dispo -je ne vais pas me frapper du reverse engineering avec apprentissage
de l'assembleur correspondant-).
Et vous ne répondez pas à ma question. Vous parlez de l'endroit où est
stocké la clé publique & vérifié la signature. Je vous parle de
l'émetteur. Qui signe un OS ? Microsoft ? Le fabriquant de la
carte-mère, du BIOS, l'assembleur ? Si ça ce passe comme pour les DVD,
en une semaine, la majorité des clés privées de BIOS seront disponible
sur le web.
Et *SI* ça ne se passe pas comme ça? Je ne fais pas devin (ce n'est plus
puni par la loi mais bon...), avez vous des dons en ce sens?
Je ne peux qu'être d'accord avec Erwan David sur ce point. Le processus
engagé est dangereux dans le sens ou la fabricant peut, in fine, décider à
ma place de ce qui peut tourner ou pas sur MA machine. Plus amusant (enfin,
façon de parler) : le jour ou MS -simple exemple et pur spéculation bien
sur- se fait pirater on va avoir une jolie révocation de certifs ou
équivalent avec un arrêt de fonctionnement immédiat (enfin dès chargement
des infos) de toutes les machines contrôlées de cette manière. Et même avec
des contres-mesures rapides les dégât seront considérables (au moins
financièrement, il n'y a pas qu'unix dans les banques, et eventuellement
physiquement suivant les processus contrôlés par l'OS et les softs qui vont
avec).
Cette forme de signature électronique[1] est liée de façon, je trouve, assez
évidente à des conséquences commerciales : celui qui gère les signatures et
celui qui les distribue a un pouvoir énorme, qu'il va vendre au prix fort.
Et le plus puissant financièrement ne vas pas se gêner pour provoquer des
concentrations par acquisition. Le cas verisign ne suffit pas comme alerte?
(et encore, ici on peut encore contourner un peu le problème).
Le modèle de sécurité est, amha, interressant, à condition que ce soit
l'utilisateur qui choississe de l'appliquer ou pas (allez, on va même
accepter une activation par défaut :) ).
Ensuite rien n'empêche un éditeur de refuser que son soft ne marche si le
bidule n'est pas activé ou que ça produise un avertissement de limitation de
responsabilité par exemple ; après c'est le end-user qui choisi d'acquérir
ou pas.
Parceque la puce TCPA permet tout à fait d'interdire de booter un OS non signé. Et que ce n'est *pas* le propriétaire de la machine qui a ^^^^^^^^^^
Par qui ?
Par une clé contenue dans le BIOS ou le hard. Et je ne fait *aucune* confiance aux fabricants pour me laisser ma liberté de choix. Je n'ai qu'à voir que ce sont les même qui font des lecteurs de DVD zonés.
Vous voulez dire ces gens qui fabrique des DVD dont le dezonnages est prévu pour être le plus simple possible ?
Tous les lecteurs de DVD du marché ne sont pas dézonnables si facilement et flasher le firmware n'est pas faisable par tout le monde (dans le sens "peur de détruire le matériel" par l'utilisateur lambda, pas de fw "pirate" dispo -je ne vais pas me frapper du reverse engineering avec apprentissage de l'assembleur correspondant-).
Et vous ne répondez pas à ma question. Vous parlez de l'endroit où est stocké la clé publique & vérifié la signature. Je vous parle de l'émetteur. Qui signe un OS ? Microsoft ? Le fabriquant de la carte-mère, du BIOS, l'assembleur ? Si ça ce passe comme pour les DVD, en une semaine, la majorité des clés privées de BIOS seront disponible sur le web.
Et *SI* ça ne se passe pas comme ça? Je ne fais pas devin (ce n'est plus puni par la loi mais bon...), avez vous des dons en ce sens?
Je ne peux qu'être d'accord avec Erwan David sur ce point. Le processus engagé est dangereux dans le sens ou la fabricant peut, in fine, décider à ma place de ce qui peut tourner ou pas sur MA machine. Plus amusant (enfin, façon de parler) : le jour ou MS -simple exemple et pur spéculation bien sur- se fait pirater on va avoir une jolie révocation de certifs ou équivalent avec un arrêt de fonctionnement immédiat (enfin dès chargement des infos) de toutes les machines contrôlées de cette manière. Et même avec des contres-mesures rapides les dégât seront considérables (au moins financièrement, il n'y a pas qu'unix dans les banques, et eventuellement physiquement suivant les processus contrôlés par l'OS et les softs qui vont avec).
Cette forme de signature électronique[1] est liée de façon, je trouve, assez évidente à des conséquences commerciales : celui qui gère les signatures et celui qui les distribue a un pouvoir énorme, qu'il va vendre au prix fort. Et le plus puissant financièrement ne vas pas se gêner pour provoquer des concentrations par acquisition. Le cas verisign ne suffit pas comme alerte? (et encore, ici on peut encore contourner un peu le problème).
Le modèle de sécurité est, amha, interressant, à condition que ce soit l'utilisateur qui choississe de l'appliquer ou pas (allez, on va même accepter une activation par défaut :) ). Ensuite rien n'empêche un éditeur de refuser que son soft ne marche si le bidule n'est pas activé ou que ça produise un avertissement de limitation de responsabilité par exemple ; après c'est le end-user qui choisi d'acquérir ou pas.
