HADOPI Spécifications fonctionnelles des moyens de sécurisation
17 réponses
Guy Ratajczak
Bonjour à tous,
Loin de moi de vouloir provoquer une cission profonde du groupe, et
d'amener à l'émergence de fr.misc.cryptologie.debats.
Pourtant, suite à ce que je viens de lire, je m'interroge et vous invite
à en débattre.
Dans le brouillon des spécifications du logiciel de sécurisation de
l'HADOPI ( http://www.scribd.com/doc/35088715/docprojet-SFH ) un point
en particulier me gêne :
"Il sera utilisé un ensemble de primitives cryptographiques afin de
garantir la confidentialité, l'authenticité, l'intégrité et la justesse
des journaux, et leur disponibilité lorsqu'un utilisateur les demandera,
et de garantir la conformité et la disponibilité de l'application qui
aura engendré ces journaux."
Pour l'expliquer rapidement le journal recensera toutes les actions
importantes de l'utilisateur sur la machine et sera généré par le
logiciel de sécurisation installé sur le poste de travail.
En dehors des aspects éthiques, et en tenant compte des limites imposées
par la vie privée, je ne comprends pas comment il est techniquement
possible d'assurer que ce journal soit "authentique" et donc bien généré
par l'application de sécurisation.
Si vous avez des idées permettant de m'éclairer ou de me confirmer ce
que je présume être une impossibilité technique, je vous en serai
reconnaissant.
Et ceci n'est pas un AAT (Appel au Troll).
Merci
--
Guy
AAD création de fmc.debats, fmc.bavardages et fmc.technique ;-)
Guy Ratajczak wrote in message <4c607f78$0$23887$:
En dehors des aspects éthiques, et en tenant compte des limites imposées par la vie privée, je ne comprends pas comment il est techniquement possible d'assurer que ce journal soit "authentique" et donc bien généré par l'application de sécurisation.
L'application de sécurisation peut en principe signer les entrées de journal, ou les authentifier par un MAC avec une clef connue du vendeur et de l'autorité mais pas de l'utilisateur.
Maintenant, si on suppose qu'elle doit tourner sur la machine de l'utilisateur lui-même et y calculer ses signatures ou ses MAC, on ne voit en effet pas trop comment la clef pourrait rester secrète, sauf à imposer qu'elle se trouve sur une puce TPM ou quelque chose de ce genre (ce qui n'est pas très réaliste!).
La même remarque vaut d'ailleurs pour la confidentialité. Quant à la « justesse », c'est encore plus surprenant; même dans le cas où les secrets restent secrets, je ne vois pas comment Alice peut prouver cryptographiquement à Bob qu'un énoncé qu'elle fait sur le monde physique est vrai.
Si vous avez des idées permettant de m'éclairer ou de me confirmer ce que je présume être une impossibilité technique, je vous en serai reconnaissant.
L'ensemble du dispositif fait probablement l'hypothèse que l'utilisateur n'a aucune compétence technique (ce qui est probablement le cas général), et en déduit qu'il ne saurait contourner les barrières en carton qu'il instaure. Mais la déduction est déraisonnable : la minorité de gens compétents techniquement aura vite fait de fournir à la majorité des moyens simples de passer outre.
Guy Ratajczak wrote in message
<4c607f78$0$23887$426a74cc@news.free.fr>:
En dehors des aspects éthiques, et en tenant compte des limites imposées
par la vie privée, je ne comprends pas comment il est techniquement
possible d'assurer que ce journal soit "authentique" et donc bien généré
par l'application de sécurisation.
L'application de sécurisation peut en principe signer les entrées de
journal, ou les authentifier par un MAC avec une clef connue du vendeur
et de l'autorité mais pas de l'utilisateur.
Maintenant, si on suppose qu'elle doit tourner sur la machine de
l'utilisateur lui-même et y calculer ses signatures ou ses MAC, on ne
voit en effet pas trop comment la clef pourrait rester secrète, sauf à
imposer qu'elle se trouve sur une puce TPM ou quelque chose de ce genre
(ce qui n'est pas très réaliste!).
La même remarque vaut d'ailleurs pour la confidentialité. Quant à la
« justesse », c'est encore plus surprenant; même dans le cas où les
secrets restent secrets, je ne vois pas comment Alice peut prouver
cryptographiquement à Bob qu'un énoncé qu'elle fait sur le monde physique
est vrai.
Si vous avez des idées permettant de m'éclairer ou de me confirmer ce
que je présume être une impossibilité technique, je vous en serai
reconnaissant.
L'ensemble du dispositif fait probablement l'hypothèse que l'utilisateur
n'a aucune compétence technique (ce qui est probablement le cas général),
et en déduit qu'il ne saurait contourner les barrières en carton qu'il
instaure. Mais la déduction est déraisonnable : la minorité de gens
compétents techniquement aura vite fait de fournir à la majorité des
moyens simples de passer outre.
Guy Ratajczak wrote in message <4c607f78$0$23887$:
En dehors des aspects éthiques, et en tenant compte des limites imposées par la vie privée, je ne comprends pas comment il est techniquement possible d'assurer que ce journal soit "authentique" et donc bien généré par l'application de sécurisation.
L'application de sécurisation peut en principe signer les entrées de journal, ou les authentifier par un MAC avec une clef connue du vendeur et de l'autorité mais pas de l'utilisateur.
Maintenant, si on suppose qu'elle doit tourner sur la machine de l'utilisateur lui-même et y calculer ses signatures ou ses MAC, on ne voit en effet pas trop comment la clef pourrait rester secrète, sauf à imposer qu'elle se trouve sur une puce TPM ou quelque chose de ce genre (ce qui n'est pas très réaliste!).
La même remarque vaut d'ailleurs pour la confidentialité. Quant à la « justesse », c'est encore plus surprenant; même dans le cas où les secrets restent secrets, je ne vois pas comment Alice peut prouver cryptographiquement à Bob qu'un énoncé qu'elle fait sur le monde physique est vrai.
Si vous avez des idées permettant de m'éclairer ou de me confirmer ce que je présume être une impossibilité technique, je vous en serai reconnaissant.
L'ensemble du dispositif fait probablement l'hypothèse que l'utilisateur n'a aucune compétence technique (ce qui est probablement le cas général), et en déduit qu'il ne saurait contourner les barrières en carton qu'il instaure. Mais la déduction est déraisonnable : la minorité de gens compétents techniquement aura vite fait de fournir à la majorité des moyens simples de passer outre.
Baton Rouge
On Tue, 10 Aug 2010 15:02:40 +0200, Mehdi Tibouchi wrote:
Guy Ratajczak wrote in message <4c607f78$0$23887$:
En dehors des aspects éthiques, et en tenant compte des limites imposées par la vie privée, je ne comprends pas comment il est techniquement possible d'assurer que ce journal soit "authentique" et donc bien généré par l'application de sécurisation.
L'application de sécurisation peut en principe signer les entrées de journal, ou les authentifier par un MAC avec une clef connue du vendeur et de l'autorité mais pas de l'utilisateur.
Pourquoi se poser cette question dans ce sens ? Qu'est ce qui va certifier que les données envoyé à l'application de securisation sont authentique ? Rien n'interdit d'enfermer l'application de securisation dans un monde virtuel et de filtrer ce qui y entre (N°CPU/CG/BIOS/MAC, word, excel, wlm, navigateur,...). Le but etant que ces données soient reele pour le matos.
-- Travailler plus pour gagner plus pour quoi faire ? Pour finir par divorcer parce qu'on est pas souvent à la maison ou faire un malaise vagal et creuser le trou de la sécu ?
On Tue, 10 Aug 2010 15:02:40 +0200, Mehdi Tibouchi
<medtib@alussinan.org> wrote:
Guy Ratajczak wrote in message
<4c607f78$0$23887$426a74cc@news.free.fr>:
En dehors des aspects éthiques, et en tenant compte des limites imposées
par la vie privée, je ne comprends pas comment il est techniquement
possible d'assurer que ce journal soit "authentique" et donc bien généré
par l'application de sécurisation.
L'application de sécurisation peut en principe signer les entrées de
journal, ou les authentifier par un MAC avec une clef connue du vendeur
et de l'autorité mais pas de l'utilisateur.
Pourquoi se poser cette question dans ce sens ?
Qu'est ce qui va certifier que les données envoyé à l'application de
securisation sont authentique ?
Rien n'interdit d'enfermer l'application de securisation dans un monde
virtuel et de filtrer ce qui y entre (N°CPU/CG/BIOS/MAC, word, excel,
wlm, navigateur,...). Le but etant que ces données soient reele pour
le matos.
--
Travailler plus pour gagner plus pour quoi faire ?
Pour finir par divorcer parce qu'on est pas souvent à la maison ou faire un malaise vagal et creuser le trou de la sécu ?
On Tue, 10 Aug 2010 15:02:40 +0200, Mehdi Tibouchi wrote:
Guy Ratajczak wrote in message <4c607f78$0$23887$:
En dehors des aspects éthiques, et en tenant compte des limites imposées par la vie privée, je ne comprends pas comment il est techniquement possible d'assurer que ce journal soit "authentique" et donc bien généré par l'application de sécurisation.
L'application de sécurisation peut en principe signer les entrées de journal, ou les authentifier par un MAC avec une clef connue du vendeur et de l'autorité mais pas de l'utilisateur.
Pourquoi se poser cette question dans ce sens ? Qu'est ce qui va certifier que les données envoyé à l'application de securisation sont authentique ? Rien n'interdit d'enfermer l'application de securisation dans un monde virtuel et de filtrer ce qui y entre (N°CPU/CG/BIOS/MAC, word, excel, wlm, navigateur,...). Le but etant que ces données soient reele pour le matos.
-- Travailler plus pour gagner plus pour quoi faire ? Pour finir par divorcer parce qu'on est pas souvent à la maison ou faire un malaise vagal et creuser le trou de la sécu ?
Guy Ratajczak
Le 10/08/2010 15:02, Mehdi Tibouchi a tapoté :
L'application de sécurisation peut en principe signer les entrées de journal, ou les authentifier par un MAC avec une clef connue du vendeur et de l'autorité mais pas de l'utilisateur.
Maintenant, si on suppose qu'elle doit tourner sur la machine de l'utilisateur lui-même et y calculer ses signatures ou ses MAC, on ne voit en effet pas trop comment la clef pourrait rester secrète, sauf à imposer qu'elle se trouve sur une puce TPM ou quelque chose de ce genre (ce qui n'est pas très réaliste!).
D'accord, on en revient bien au point où l'on considère que l'utilisateur et la clé ne font qu'un, et qu'il peut donc falsifier les données.
L'ensemble du dispositif fait probablement l'hypothèse que l'utilisateur n'a aucune compétence technique (ce qui est probablement le cas général), et en déduit qu'il ne saurait contourner les barrières en carton qu'il instaure. [...]
C'est bien ce qu'il m'avait semblé. On part sur des "barrières en carton" en disant que ça repoussera la majorité, mais les vrais "vilains" pourront toujours contourner.
Merci de l'analyse.
-- Guy
Le 10/08/2010 15:02, Mehdi Tibouchi a tapoté :
L'application de sécurisation peut en principe signer les entrées de
journal, ou les authentifier par un MAC avec une clef connue du vendeur
et de l'autorité mais pas de l'utilisateur.
Maintenant, si on suppose qu'elle doit tourner sur la machine de
l'utilisateur lui-même et y calculer ses signatures ou ses MAC, on ne
voit en effet pas trop comment la clef pourrait rester secrète, sauf à
imposer qu'elle se trouve sur une puce TPM ou quelque chose de ce genre
(ce qui n'est pas très réaliste!).
D'accord, on en revient bien au point où l'on considère que
l'utilisateur et la clé ne font qu'un, et qu'il peut donc falsifier les
données.
L'ensemble du dispositif fait probablement l'hypothèse que l'utilisateur
n'a aucune compétence technique (ce qui est probablement le cas général),
et en déduit qu'il ne saurait contourner les barrières en carton qu'il
instaure. [...]
C'est bien ce qu'il m'avait semblé. On part sur des "barrières en
carton" en disant que ça repoussera la majorité, mais les vrais
"vilains" pourront toujours contourner.
L'application de sécurisation peut en principe signer les entrées de journal, ou les authentifier par un MAC avec une clef connue du vendeur et de l'autorité mais pas de l'utilisateur.
Maintenant, si on suppose qu'elle doit tourner sur la machine de l'utilisateur lui-même et y calculer ses signatures ou ses MAC, on ne voit en effet pas trop comment la clef pourrait rester secrète, sauf à imposer qu'elle se trouve sur une puce TPM ou quelque chose de ce genre (ce qui n'est pas très réaliste!).
D'accord, on en revient bien au point où l'on considère que l'utilisateur et la clé ne font qu'un, et qu'il peut donc falsifier les données.
L'ensemble du dispositif fait probablement l'hypothèse que l'utilisateur n'a aucune compétence technique (ce qui est probablement le cas général), et en déduit qu'il ne saurait contourner les barrières en carton qu'il instaure. [...]
C'est bien ce qu'il m'avait semblé. On part sur des "barrières en carton" en disant que ça repoussera la majorité, mais les vrais "vilains" pourront toujours contourner.
Merci de l'analyse.
-- Guy
Guy Ratajczak
Le 10/08/2010 18:45, Baton Rouge a réflexionné :
Qu'est ce qui va certifier que les données envoyé à l'application de securisation sont authentique ? Rien n'interdit d'enfermer l'application de securisation dans un monde virtuel et de filtrer ce qui y entre (N°CPU/CG/BIOS/MAC, word, excel, wlm, navigateur,...). Le but etant que ces données soient reele pour le matos.
C'est pas con du tout comme réflexion. Un peu comme les bacs à sable. On contrôle les entrées/sorties donc on contrôle le monde (virtuel) ;-)
J'aime bien ce point de vue. Merci.
-- Guy
Le 10/08/2010 18:45, Baton Rouge a réflexionné :
Qu'est ce qui va certifier que les données envoyé à l'application de
securisation sont authentique ?
Rien n'interdit d'enfermer l'application de securisation dans un monde
virtuel et de filtrer ce qui y entre (N°CPU/CG/BIOS/MAC, word, excel,
wlm, navigateur,...). Le but etant que ces données soient reele pour
le matos.
C'est pas con du tout comme réflexion. Un peu comme les bacs à sable. On
contrôle les entrées/sorties donc on contrôle le monde (virtuel) ;-)
Qu'est ce qui va certifier que les données envoyé à l'application de securisation sont authentique ? Rien n'interdit d'enfermer l'application de securisation dans un monde virtuel et de filtrer ce qui y entre (N°CPU/CG/BIOS/MAC, word, excel, wlm, navigateur,...). Le but etant que ces données soient reele pour le matos.
C'est pas con du tout comme réflexion. Un peu comme les bacs à sable. On contrôle les entrées/sorties donc on contrôle le monde (virtuel) ;-)
J'aime bien ce point de vue. Merci.
-- Guy
Erwan David
Guy Ratajczak écrivait :
C'est bien ce qu'il m'avait semblé. On part sur des "barrières en carton" en disant que ça repoussera la majorité, mais les vrais "vilains" pourront toujours contourner.
Comme l'a dit la présidente de l'hadopi, le but n'est pas d'attraper les pirates, mais ceux qui ont une connexion mal sécurisée...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Guy Ratajczak <newsgroups@mjcie.net> écrivait :
C'est bien ce qu'il m'avait semblé. On part sur des "barrières en
carton" en disant que ça repoussera la majorité, mais les vrais
"vilains" pourront toujours contourner.
Comme l'a dit la présidente de l'hadopi, le but n'est pas d'attraper les
pirates, mais ceux qui ont une connexion mal sécurisée...
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
C'est bien ce qu'il m'avait semblé. On part sur des "barrières en carton" en disant que ça repoussera la majorité, mais les vrais "vilains" pourront toujours contourner.
Comme l'a dit la présidente de l'hadopi, le but n'est pas d'attraper les pirates, mais ceux qui ont une connexion mal sécurisée...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
DeVice
Guy Ratajczak a écrit :
Bonjour à tous,
Loin de moi de vouloir provoquer une cission profonde du groupe, et d'amener à l'émergence de fr.misc.cryptologie.debats. Pourtant, suite à ce que je viens de lire, je m'interroge et vous invite à en débattre.
Dans le brouillon des spécifications du logiciel de sécurisation de l'HADOPI ( http://www.scribd.com/doc/35088715/docprojet-SFH ) un point en particulier me gêne :
Intéressante discussion.
Je me demande où seront stockés les journaux indiqués dans ce document. Parce que si c'est sur le poste de l'utilisateur, garder un an d'évènements réseaux "suspects" ça ouvre la voie a de jolis dénis de services par bourrage de disque...
-- /dev/full
Guy Ratajczak a écrit :
Bonjour à tous,
Loin de moi de vouloir provoquer une cission profonde du groupe, et
d'amener à l'émergence de fr.misc.cryptologie.debats.
Pourtant, suite à ce que je viens de lire, je m'interroge et vous invite
à en débattre.
Dans le brouillon des spécifications du logiciel de sécurisation de
l'HADOPI ( http://www.scribd.com/doc/35088715/docprojet-SFH ) un point
en particulier me gêne :
Intéressante discussion.
Je me demande où seront stockés les journaux indiqués dans ce document.
Parce que si c'est sur le poste de l'utilisateur, garder un an
d'évènements réseaux "suspects" ça ouvre la voie a de jolis dénis de
services par bourrage de disque...
Loin de moi de vouloir provoquer une cission profonde du groupe, et d'amener à l'émergence de fr.misc.cryptologie.debats. Pourtant, suite à ce que je viens de lire, je m'interroge et vous invite à en débattre.
Dans le brouillon des spécifications du logiciel de sécurisation de l'HADOPI ( http://www.scribd.com/doc/35088715/docprojet-SFH ) un point en particulier me gêne :
Intéressante discussion.
Je me demande où seront stockés les journaux indiqués dans ce document. Parce que si c'est sur le poste de l'utilisateur, garder un an d'évènements réseaux "suspects" ça ouvre la voie a de jolis dénis de services par bourrage de disque...
-- /dev/full
Guy Ratajczak
Le 11/08/2010 13:45, DeVice a écrit :
Je me demande où seront stockés les journaux indiqués dans ce document. Parce que si c'est sur le poste de l'utilisateur, garder un an d'évènements réseaux "suspects" ça ouvre la voie a de jolis dénis de services par bourrage de disque...
Bonne remarque.
D'après ces semblants de specs, ça doit être le cas. Autrement, comment comptent-ils garantir le respect de la vie privée, si ces données doivent être envoyées on ne sait où ?
En particulier : "à aucun moment le titulaire n’est dessaisi de ses enregistrements des données d’historique d’utilisation du moyen de sécurisation [...]"
Un point intéressant : "Ce journal [...] permettra de vérifier, après déchiffrement avec la clé privée correspondant au logiciel, laquelle est détenue par le tiers de confiance, la mise en œuvre du logiciel de sécurisation à une date et heure donnée, et l’activité informatique de l’internaute concerné."
Si l'on chiffre avec une clé publique... alors quid de la falsification ? Surtout si tout est stocké sur le disque de l'utilisateur. A moins que la sécurité soit par l'obscurité. Sans savoir comment est construit le journal, c'est plus dur... mais pas impossible.
-- Guy
Le 11/08/2010 13:45, DeVice a écrit :
Je me demande où seront stockés les journaux indiqués dans ce document.
Parce que si c'est sur le poste de l'utilisateur, garder un an
d'évènements réseaux "suspects" ça ouvre la voie a de jolis dénis de
services par bourrage de disque...
Bonne remarque.
D'après ces semblants de specs, ça doit être le cas. Autrement, comment
comptent-ils garantir le respect de la vie privée, si ces données
doivent être envoyées on ne sait où ?
En particulier :
"à aucun moment le titulaire n’est dessaisi de ses enregistrements
des données d’historique d’utilisation du moyen de sécurisation [...]"
Un point intéressant :
"Ce journal [...] permettra de vérifier, après déchiffrement avec la clé
privée correspondant au logiciel, laquelle est détenue par le tiers de
confiance, la mise en œuvre du logiciel de sécurisation à une date et
heure donnée, et l’activité informatique de l’internaute concerné."
Si l'on chiffre avec une clé publique... alors quid de la falsification
? Surtout si tout est stocké sur le disque de l'utilisateur.
A moins que la sécurité soit par l'obscurité. Sans savoir comment est
construit le journal, c'est plus dur... mais pas impossible.
Je me demande où seront stockés les journaux indiqués dans ce document. Parce que si c'est sur le poste de l'utilisateur, garder un an d'évènements réseaux "suspects" ça ouvre la voie a de jolis dénis de services par bourrage de disque...
Bonne remarque.
D'après ces semblants de specs, ça doit être le cas. Autrement, comment comptent-ils garantir le respect de la vie privée, si ces données doivent être envoyées on ne sait où ?
En particulier : "à aucun moment le titulaire n’est dessaisi de ses enregistrements des données d’historique d’utilisation du moyen de sécurisation [...]"
Un point intéressant : "Ce journal [...] permettra de vérifier, après déchiffrement avec la clé privée correspondant au logiciel, laquelle est détenue par le tiers de confiance, la mise en œuvre du logiciel de sécurisation à une date et heure donnée, et l’activité informatique de l’internaute concerné."
Si l'on chiffre avec une clé publique... alors quid de la falsification ? Surtout si tout est stocké sur le disque de l'utilisateur. A moins que la sécurité soit par l'obscurité. Sans savoir comment est construit le journal, c'est plus dur... mais pas impossible.
Moi qui croyais que le but était de créer une industrie franchouillarde de logiciels de pseudo-sécurité Internet! On m'au rait menti?
J'en ai bien l'impression :
http://seclists.org/fulldisclosure/2010/Jun/346
Je ne sais pas trop ce qui est vrai dans cet article, mais : - c'est un site sérieux, j'ai plutôt un a priori très positif sur le contenu des articles, - le logiciel a été téléchargeable, le fait qu'il ne le soit pl us montre que orange n'est pas spécialement fier de ce logiciel.
Vengeur Masqué a écrit:
Moi qui croyais que le but était de créer une industrie
franchouillarde de logiciels de pseudo-sécurité Internet! On m'au rait
menti?
J'en ai bien l'impression :
http://seclists.org/fulldisclosure/2010/Jun/346
Je ne sais pas trop ce qui est vrai dans cet article, mais :
- c'est un site sérieux, j'ai plutôt un a priori très positif sur le contenu
des articles,
- le logiciel a été téléchargeable, le fait qu'il ne le soit pl us montre que
orange n'est pas spécialement fier de ce logiciel.
Moi qui croyais que le but était de créer une industrie franchouillarde de logiciels de pseudo-sécurité Internet! On m'au rait menti?
J'en ai bien l'impression :
http://seclists.org/fulldisclosure/2010/Jun/346
Je ne sais pas trop ce qui est vrai dans cet article, mais : - c'est un site sérieux, j'ai plutôt un a priori très positif sur le contenu des articles, - le logiciel a été téléchargeable, le fait qu'il ne le soit pl us montre que orange n'est pas spécialement fier de ce logiciel.
Kevin Denis
Le 12-08-2010, Vengeur Masqué a écrit :
Comme l'a dit la présidente de l'hadopi, le but n'est pas d'attraper les pirates, mais ceux qui ont une connexion mal sécurisée...
Moi qui croyais que le but était de créer une industrie franchouillarde de logiciels de pseudo-sécurité Internet! On m'aurait menti?
Non, c'est bien de la pseudo-sécurité en carton.
Suite aux décisions du CC[1] la conclusion est qu'aujourd'hui, la loi parle donc toujours de la sécurisation de l'accès à internet. Sauf que:
* En cas de litige avec la Hadopi, aucun logiciel de sécurisation ne peut servir à s'exonérer de la sanction. * La Hadopi n'est habilitée à homologuer aucun logiciel[2]. * La Hadopi ne peut pas obliger à employer un logiciel de sécurisation.
Mais on s'éloigne un peu de la crypto, là..
[1] http://www.conseil-constitutionnel.fr/conseil-constitutionnel/root/bank/download/2009-580DC-ccc_580dc.pdf [2] aucun logiciel servant à s'exonérer d'une sanction, s'entend. Elle peut toujours coller des étiquettes "hadopi" sur n'importe quel soft, sachant que ça n'a aucune protection juridique. On peut parler des protections techniques, ceci dit.
-- Kevin
Le 12-08-2010, Vengeur Masqué <vm666@alussinan.org> a écrit :
Comme l'a dit la présidente de l'hadopi, le but n'est pas d'attraper les
pirates, mais ceux qui ont une connexion mal sécurisée...
Moi qui croyais que le but était de créer une industrie
franchouillarde de logiciels de pseudo-sécurité Internet! On m'aurait
menti?
Non, c'est bien de la pseudo-sécurité en carton.
Suite aux décisions du CC[1] la conclusion est qu'aujourd'hui, la loi
parle donc toujours de la sécurisation de l'accès à internet. Sauf que:
* En cas de litige avec la Hadopi, aucun logiciel de sécurisation
ne peut servir à s'exonérer de la sanction.
* La Hadopi n'est habilitée à homologuer aucun logiciel[2].
* La Hadopi ne peut pas obliger à employer un logiciel de sécurisation.
Mais on s'éloigne un peu de la crypto, là..
[1] http://www.conseil-constitutionnel.fr/conseil-constitutionnel/root/bank/download/2009-580DC-ccc_580dc.pdf
[2] aucun logiciel servant à s'exonérer d'une sanction, s'entend. Elle
peut toujours coller des étiquettes "hadopi" sur n'importe quel soft,
sachant que ça n'a aucune protection juridique. On peut parler des
protections techniques, ceci dit.
Comme l'a dit la présidente de l'hadopi, le but n'est pas d'attraper les pirates, mais ceux qui ont une connexion mal sécurisée...
Moi qui croyais que le but était de créer une industrie franchouillarde de logiciels de pseudo-sécurité Internet! On m'aurait menti?
Non, c'est bien de la pseudo-sécurité en carton.
Suite aux décisions du CC[1] la conclusion est qu'aujourd'hui, la loi parle donc toujours de la sécurisation de l'accès à internet. Sauf que:
* En cas de litige avec la Hadopi, aucun logiciel de sécurisation ne peut servir à s'exonérer de la sanction. * La Hadopi n'est habilitée à homologuer aucun logiciel[2]. * La Hadopi ne peut pas obliger à employer un logiciel de sécurisation.
Mais on s'éloigne un peu de la crypto, là..
[1] http://www.conseil-constitutionnel.fr/conseil-constitutionnel/root/bank/download/2009-580DC-ccc_580dc.pdf [2] aucun logiciel servant à s'exonérer d'une sanction, s'entend. Elle peut toujours coller des étiquettes "hadopi" sur n'importe quel soft, sachant que ça n'a aucune protection juridique. On peut parler des protections techniques, ceci dit.
